Scrum and Kanban at Salesforce

Learn About Scrum

• Two different workflows are used at Salesforce: Scrum and Kanban
  • These are two project management processes
• Scrum, the Salesforce Way
  • Scrum is one of the more popular agile frameworks in use at Salesforce
  • Implemented at Salesforce in 2006 and still the go-to framework for 70% of Salesforce teams
  • Scrum is a workflow where roles, meetings, and deliverables are well-defined, and the process allows teams to continuously test and improve their products and process
  • Key Traits:
    • Framework to deliver high-quality value to customers faster
    • Everyone is organized into small, cross-functional teams
    • Teams work in short iterations (called “sprints”)
• Scrum Values
  1. Focus - work is complex with many unknowns, so essential to stay focused to deliver outcomes on time
     • Collaborate on everything - teams complete a task, then move on to the next task
     • Clear priorities for the team
     • Team agrees to a sprint plan, resulting in shared accountability
     • Team creates a clear vision of the product that informs the team’s daily agenda
  2. Courage - taking risks is key to innovation, and being risky takes courage
     • Be transparent about progress and speak up when help is needed
     • Report back when assumptions were wrong or if mistakes have been made
  3. Openness - transparency is key to promote collaboration and success
     • As one team, consistently verbalize how we’re doing, flag obstacles, voice concerns
     • Teams can provide each other with help
     • Team members are honest and clear about timing, planning, obstacles
     • Teams are open, admit when they were wrong, and correct their mistakes with intent to improve
  4. Commitment - teams that commit to a process are more in control of outcomes. Commitment is not defined as a set scope by a specific milestone. Instead, it is defined as:
     • Trust - each team member is invested in team success not their individual success
     • Choosing Scrum as the process is itself a commitment - since its a team decision, everyone is more likely to stick to that process
     • Since continuous improvement is the goal, teams are willing to try new things based on new information or data
     • Team decides together on work items, working agreements, definition of “done,” and roles
  5. Respect
     • Respect diverse backgrounds and experiences
     • Assume everyone has the best intentions
     • Embracing all opinions and perspectives results in more robust products and teams
• Scrum Process at Salesforce…
  • Is intended to help the team learn in real time to correct any potential damage from our risk-taking, making the innovation process continuous
  • In a nutshell, Scrum drives us to:
    1. Deliver or demo every sprint so the team can gather feedback
    2. Continuously improve ourselves, the team, and the outcome
    3. Assemble a competent team and make decisions as a team
    4. Appoint one person to remove barriers
    5. Appoint one person to set work agendas and prioritize projects for teams
• Scrum Roles - not a job title, but a list of responsibilities
  • ScrumMaster - like the “team mirror,” keeps everyone accountable. Work to build community on the team.
    • Historically, ScrumMasters were engineering managers. Now, many are individual contributors. They:
      • Remove blockers
      • Don’t micromanage
      • Steer the team from bad habits/inefficient processes
      • Enable the team to become collaborative/high-performing
  • Product Owner - responsible for the what and why of the process. Works closely with customers to ensure they’re getting a good return on Salesforce investment. Responsible for communicating the vision to internal teams by providing a prioritized list of work, a “product backlog.” Communicates the highest-value work. They:
    • Facilitate communication among stakeholders, team members, ScrumMaster
    • Defines, prioritizes, approves work for the team
    • Works with customers to define features
  • The Team - teams should be small and nimble (hence agile)-between 3 and 9 people. Make sure teams consist of diverse expertise to deliver projects at the end of every sprint. Teams should have all the right players and don’t have to look to other teams for help. Teams are:
    • Self-organizing and empowered
    • Consistently adjusting and updating their process and products based on lessons learned
    • Autonomous
    • Accountable individually
    • Always collaborating
• Shared Service Subject Matter Expert (SME)
  • Examples: technical writers or designers
  • Work for many delivery teams and provide up-to-date information and data to inform projects
• Technical Program Manager (TPM)
  • Work at the leadership level of each cloud, dealing with high-level cloud dependency tracking.
  • Work spans programs across all clouds
• Functional Manager
  • Salesforce is a matrixed organization, so engineering managers can work on Scrum teams, often as ScrumMaster or product owner
    
    
• Scrum at Salesforce is a framework to organize delivery to customers
• Main Scrum team roles have following traits: team does the work, ScrumMaster facilitates the process, product owner defines direction for the team

Learn the Elements of the Scrum Workflow

• Product Backlog - ordered list of work that can possibly be needed. Single source of truth that describes all the changes, updates, and requirements that we think are necessary to do.
  • Constantly refined as team learns new info about the product
  • Higher-priority items have more detail so they’re work ready
  • Includes project-related work, but also support or maintenance work, nonfunctional requirements, research
  • Product owner owns it, and it’s their job to prioritize the work items
• Sprint Backlog - highest priority work items chosen right before every sprint. Chosen from the product backlog with assumption they can be tacked in two weeks.
• Potentially Shippable Work - teams should deliver something of value very sprint.
  • Scrum focuses on outcome, not the output, quality work, not quantity of work
  • Push to complete work before starting something new
  • Every four months Salesforce releases updates to the platform, but it doesn’t finish deliverables every four months. Instead its on two week increments.
• Why Emphasize finishing?
  • Projects that are works in progress are a form of waste - you are not learning and adapting to create better deliverables and solutions
  • Work that is not completed (checked-in, tested, deployed) delays the entire workflow
  • Salesforce promotes a culture where teams work to bring projects over the finish line - called “swarming” or “dog piling” - people help each other finish the last 20%
    
    
• Product Backlog - list of everything we think needs to be done
• Finishing work in a sprint is important to Salesforce because Salesforce values eliminating waste, and unfinished work is a form of waste
• A sprint backlog is different from a product backlog in that the product backlog is everything that can possibly be needed, and the sprint backlog is the work committed to do by the team for the next two weeks

Implement Scrum

• Implementing Scrum is all about managing meetings intended to provide action items. Two main types:
  1. Planning Meetings - happen at all stages of the project, teams meet regularly to ensure they’re aligned on final outcome
  2. Inspect and Adapt Meetings - this is when teams learn new things and apply them to the next sprint. These meetings are geared toward improving process and products.
• Planning Meetings
  • At Salesforce, yearly planning is ultimate alignment tool
  • Release Planning - every 4 months
    • Release new versions of core platform every four months
    • At beginning of every major release cycle, Salesforce has a high-level planning meeting to create a roadmap
    • Key purposes:
      • Align on business/customer priorities
      • Provide high-level understanding of new features/functionality
      • Negotiate schedules
  • Backlog Refinement Planning - every 2 weeks
    • Prepare for the upcoming sprint
    • Teams plan a couple sprints ahead
    • Key purposes:
      • Team provides input and gets clarity on what is coming down the pipe
      • Work is broken into smaller chunks
      • Conditions of satisfaction are drafted
      • Identify work that’s not ready for release
  • Sprint Planning - every 2 weeks
    • Teams get together to create a roadmap for the next two weeks
    • Team agrees and commits to a work plan
    • At these meetings, teams start with the product backlog and prioritize
  • Daily Stand-Up - every day
    • Scrums calls for daily stand-ups, but most teams at Salesforce have no-interruption Thursday (no meetings on Thursday)
    • Key purposes:
      • Brief sync where team members make sure they are focused on the right objectives
      • Frequency is meant to prevent team members from spinning their wheels
      • Provides visibility on daily progress
• Inspect and Adapt Meetings
  • Fewer meetings in general as we move from planning stage to doing stage
  • Retrospective - look back at end of each sprint
    • Team takes responsibility for progress or failures
    • Focus on two things: Process and Team
    • Team inspects how they worked during the sprint, decides what to change and adapt for next sprint - goal is to improve process and deliverable every sprint
    • Salesforce’s expectation is that each team have “actionable experiments” after every sprint - something they can try next time
      • These new action items are added to their sprint or Kanban boards
  • Sprint Demo - happens each sprint
    • This is the second of the two inspect and adapt meetings
    • Team presents finished work to product owners and stakeholders for feedback and input
      
      
• Two main types of Scrum meetings at Salesforce are Inspect and Adapt meetings, and Planning meetings
• Meetings that are important for planning: Release planning, Backlog Refinement planning, daily standups
• Difference between a demo and a retrospective: former focuses on product or service, latter inspects how the team works

Learn About Kanban

• Salesforce takes parts of Scrum and applies it to another framework, Kanban
  • Kanban is a method for more infrastructure or operations-focused teams that support production or customer issues use
  • Kanban is less prescriptive than Scrum, so it is easier to implement
  • Teams that adopt Kanban can still use the same roles and meetings as Scrum
    • This hybrid approach is called scrumban
  • Four key traits of Kanban:
    1. Visualize workflow - work is divided into pieces, and each is written on a card that is placed on a wall - Salesforce uses a virtual wall called Agile Accelerator - Workflow is mapped into columns
    2. Limit Work in Progress - teams should limit how many work items are in progress at one time in each workflow stage
    3. Incremental and Evolutionary Change - Scrum is a process that calls for far-reaching shifts in work process - Kanban lets teams embrace smaller, more iterative changes along the way
    4. Kanban includes metrics - “Lead time,” or “cycle time,” is the average time to complete one item. Teams should optimize the process to make lead time as small and predictable as possible. “Throughput” is defined as the amount of work completed in a single period of time.
• Visualize Workflow - Process is shown on a Kanban card. Kanban is visible sign in Japanese.
  • Cards are moved from one stage to the next, indicating completion

• Limit Work in Progress (WIP) - whereas Scrum works by limiting the amount of work per sprint (every 2 weeks), Kanban limits the amount of work per workflow state
  • “WIP limits” are in place to help the team set realistic goals based on capacity and bandwidth
  • “WIP limits” can be adjusted dynamically and experimented with
• Kanban Embraces Last-Minute Change
  • In a scenario where a stakeholder wants your team to deliver a high-priority item right now, a Scrum team will say “No, put it on the product backlog to be prioritized” - Scrum protects the team from taking on new work while in a Sprint
  • With Kanban, the team can say “OK, we have a WIP limit of two, we will start on this urgent item next”
  • Kanban is therefore more flexible to taking on last-minute requests
• Measure Success
  • Kanban metrics rely on average lead times to determine output
  • If lead time starts to increase, may need to check on the process
• Since all work is transparent in a Kanban system, easy for teams to know when delays occur and they can react quickly
  
  
• Kanban teams deliver fast by visualizing flow, limiting work in progress with visual indicators, managing flow, and adapting with evolutionary changes
• Kanban teams respond to unplanned work and changes by assessing the priority of the new request and starting the work when it’s at the top of the backlog
• Kanban teams use the following practices to manage flow: cycle time, lead time, small batch size, and throughput

Choose the Best Workflow

• At Salesforce 70% of teams use Scrum and 20% use Kanban. The remaining teams use a mixture of both.
  • Best method to use depends on the type of work and how volatile or interruption-driven the work is
  • Questions to ask to determine which to use include:
    • How important is predictability and productivity for large projects?
    • How far in advance can your team plan?
    • Is the new work truly an emergency?
    • How quickly are you required to deliver the new work?
      
      
• Is your team focused on predictability and productivity for large projects? Consider two work projects:
  • Scrum case study - team needs to build a website, and the team can break down the work into smaller projects. As smaller work items are completed, team can review progress on each sprint and adjust to ensure the project is delivered successfully.
    • If a project needs a predictable delivery schedule, Scrum is the preferred workflow
  • Kanban case study - teams that deals with service outages, this would be an example of interruption-driven work. You can’t know about or plan for outages 2 weeks in advance.
    • If teams work on items that just pop up and create shifting priorities, Kanban is the better process
• How far in advance can the team plan?
  • Teams use Scrum when its backlog is filled with small chunks of larger projects that are easy to plan in advance
  • If it is difficult to commit to a scope of work for two weeks at a time, team priorities often change, and 25% of your work changes mid-sprint, then Kanban can work better for you - this is called interruption-driven work
• Is the new work truly an emergency?
  • Ideally, we want to limit changes for the team - here’s some questions to consider before classifying new work as an urgent priority:
    • Can this project cause disruptions that are time-consuming and demoralizing?
    • Do the disruptions prevent the team from finishing more valuable work?
    • Do the interruptions prevent the team from completing the most important things first?
  • Kanban does not help a team if the work isn’t actually interruption-driven - here’s some questions to consider if your work is interruption-driven:
    • Is the needed work business-stopping or can we lose business if it’s not done now? If no, the work items may be urgently needed due to poor planning
    • What is the root cause of the needed work, and why wasn’t it identified in the planning phase?
      • Because we didn’t plan ahead?
      • New stakeholder or customer request?
      • Is the product not working?
    • If the urgent work is just a result of poor planning, moving to Kanban is not justified
• How quickly do new priority work items have to be delivered?
  • High-priority interruptions are a fact of life at competitive, successful companies
  • When these fire drills arise, consider how long the stakeholder can wait for an urgent work item to be completed
    • If work is required as soon as possible, Kanban is the less disruptive workflow
      
      
• Scrum
  • Product backlog is reordered for next sprint
  • Scrum focuses the team to deliver on sprint commitments, and interruptions mid-sprint are discouraged
  • Takes 2 weeks or more to deliver
• Kanban
  • Product backlog is continuously reordered for the next person with capacity
  • Work starts as soon as there is capacity to work on it
  • Work is delivered as soon as it is completed
• Generally:
  • Use Kanban if it’s necessary to change directions often, minimize disruptions to a plan, and start urgent work quickly
  • Use Scrum if you’re managing a large planned project, your team can commit to a 2-week chunk of work, and the stakeholder can wait until the end of the sprint for the team to start the work
• Some teams at Salesforce use parts of both Scrum and Kanban to manage their workload: Scrumban
  • Scrum provides the structure of the regular planning and review cadence
  • Kanban helps them respond to urgent work while minimizing disruptions
    
    
• A team chooses Kanban to manage its work when the team’s work is difficult to predict
• Interruption-driven work is work that is difficult to predict in advance but needs a team in place to handle it when it comes up
• Some teams combine Scrum and Kanban processes because the team likes the Scrum structure, with the Kanban WIP limits.