Getting started with Scrumban

This is an excerpt from The Scrumban [R]Evolution – Getting the Most Out of Agile, Scrum and Lean Kanban by Ajay Reddy, one of the co-founders of ScrumDo

For more information, Chapter 5 of the book provides a detailed overview of one approach for introducing Scrumban to an organization or group of teams. The purpose of this quick reference is to provide a high-level summary of the practical steps to getting started.

Step 1: Visualize Your System

Having teams create a visual model of the systems in which they work (and ultimately a model of their workflow) is the first and most important step. Initial visualizations aren’t intended to be perfect. Rather, their primary objective is to help teams gain a common understanding of how they are currently working. The entire team should be involved in this process. The key elements to identify are as follows:

  • Inputs: The kind of work coming in to the team and where it comes from
  • Process steps: The stages of discovery or refinement work passes through from the time the team first accepts it to the time it delivers completed work to others
  • Work performed by others outside the immediate team: Shared resources, required approvals from other departments or business units, and so on
  • Outputs: The team’s completed work and to whom it is delivered

A visual representation of these elements is presented in Figure A.1.

Figure A.1

Exercise 1: One way to get started is to have each team member identify two or three items he or she currently has in progress. As a group, discuss how each person received that work, what the team member is expected to accomplish based on its current state, and what happens to it once the individual’s part is done. After walking through several existing work items in this fashion, you should begin to recognize patterns that can be translated into a visual mapping similar to the diagram in Figure A.1.

Remember, the objective here is simply to visualize the different kinds of work your team undertakes (e.g., user stories, bug fixes, work estimation requests, ad hoc customer requests). Resist any urges to redesign how you work. These decisions will be made by the team over time as your understanding of the system improves.

Exercise 2: Engage your team members in some form of interactive training or exercise that will orient them to the core Scrumban practices that will be introduced through your initial efforts. The two chief practices are workflow visualization and the evolutionary change process. You may elect to include additional concepts such as limiting work in progress (WIP) and pull versus push. Ideally, you want new practitioners to recognize that these practices are minimally disruptive, and to experience the way they’ll be carried out within the working context with which they’re already familiar.

I specifically designed the GetScrumban game (Figure A.2) for this purpose, and certainly encourage its use as part of any kickstart process.

Figure A.2

Exercise 3: With the initial understanding in place, have your teams expand upon their initial systems/workflow visualizations and create their first working kanban board (either a physical board, a virtual board, or both). At the end of Chapter 6 and also later in this appendix are several examples of board designs that teams can draw upon for inspiration. Don’t neglect to consider “ticket” (work item) design at this point, assessing factors such as the following:

  • Information necessary for a team member to make a good decision as to which of multiple work items should be worked on first
  • Information needed to better understand how long it takes for work to move through the system or even each phase of the system Simplicity of design should be paramount—especially when teams are getting started. That said, the phases of work reflected in an initial board design should expand beyond just “To Do,” “Doing,” and “Done.” Nevertheless, such a coarse workflow mapping may be the most appropriate starting point for some contexts.

When teams complete their initial designs, be sure to congratulate them on achieving their first concrete step toward not only becoming more effective, but also gaining more control over their own way of working! Each of the following “steps” to launching Scrumban in your environment primarily takes place in the context of dayto- day activities and interactions.

Step 2: Start Measuring Performance

Once teams populate their kanban boards with actual work items, they’ll see how work “moves” from left to right across the board as progress occurs (Figure A.3). Revealing how work actually flows through your process is informative, but using new tools to measure and evaluate flow is even more valuable. To facilitate shared understanding and collective responsibility, the board should always be treated as belonging to the entire team, and not just the manager or Scrum master. Similarly, conversations around information gleaned from the board should always be steered in directions that reinforce assessing the board as a reflection of the entire system, and not as a collection of separate conversations focused on individual items or the work undertaken by individual members. After allowing a day or two for teams to become accustomed to any new logistics associated with working with visual boards, coaches and Scrum masters should begin guiding teams on capturing and understanding some basic metrics. Among the most important to start with are these measures:

  • Amount of work in progress (WIP): Work that’s been started but not yet finished.
  • Blockers: Blocked items are just that, and can’t move to the next stage of your process until the issue blocking them has been resolved.
  • Lead time: The amount of time it takes for work to travel across the board.
  • Throughput: The number of work items completed per a given time period.

Figure A.3

Exercise 1: In daily stand-ups, coaches and Scrum masters can begin nurturing conversations in which these metrics can be used to help the team better understand its system:

  • Amount of work in progress: Have the team divide its total WIP by the number of members on the team to get an average amount of WIP per person. Does the result show that each person is managing two things at a time? Five things at a time? Ten things at a time? Does the number seem like too much? Or too little?
  • Blockers: Guide the team in asking pertinent questions about blockers. How often is work getting blocked? How long does it stay blocked? Do blockers tend to show up in just one or two parts of the process? The answers to these questions will help the team understand why work is being delayed (because of a lack of skill sets on the team, defects, or other reasons).
  • Lead time: Does the team understand how long it’s taking for work to move through the system? Capturing this information for each work item and plotting it in a histogram or other visual chart can lead to many insights. Encourage the team to explore such issues as whether some work types take longer than others and why. Evaluate which understandings can be developed from monitoring the relationship among these four basic metrics over time.
  • Throughput: Marginally informative in isolation, tracking this number over time will help the team understand whether changes they make to their system affect the total amount of work completed.

Step 3: Stabilize Your System and Improve Focus with WIP Limits

At the end of Chapter 5, we discussed how Scrumban can be used to stabilize a system by establishing initial WIP limits within the system’s workflow. Remember, it’s necessary to stabilize a system before undertaking any effort to improve it, so attaining stability should be one of every team’s first objectives.

Although we ultimately want to apply WIP limits based on the system’s actual capacity, imposing totally random limits when working with a system for the first time allows the process of discovery to begin. Let’s see how.

Exercise 1: Coaches and Scrum masters will need to guide team members toward understanding the true nature of their system, particularly how to tell whether it’s stable or unstable. If it is an unstable system, which measures can be taken to stabilize it?

  • Is any team member working on things that are not reflected on the board? Capturing all incoming and outgoing work is vital to assessing the system. If this goal isn’t being achieved, determine which changes are needed to begin capturing this work.
  • Are system lead times relatively stable or widely distributed?
  • Does the cumulative flow diagram (CFD) reflect a balance between incoming requests and outgoing work?
  • Encourage using WIP limits as an initial mechanic for stabilizing incoming and outgoing work. Measure and adapt as warranted.

Exercise 2: In parallel with their efforts on metrics, coaches and Scrum masters should further help team members seek out visual patterns exposed by their boards and metrics. The daily stand-ups should almost immediately move away from discussions of status. Team members no longer have to recite what they did yesterday, what they’re planning to do today, and which potential impediments are obstructing them—all of this information appears on the board right in front of them! Instead, members are encouraged to explore issues relevant to flow and performance:

  • Where is work backing up? Why is this happening? Which experiments can be conducted to expand our understanding?
  • Are any parts of the system starved for work during the day? Why is this happening? Which mechanisms can we experiment with to avoid it?

Step 4: Improve Your Understanding and Management of Risk

Chapter 6 and later chapters explored how Scrumban can be used to improve our understanding and management of risk. Though ultimately one of the most important areas for a Scrumban team to attack, attempting to address risk too early can needlessly complicate your kickstart efforts. Consequently, we always encourage initiative leaders to proceed with caution here.

Don Reinertsen said, “If you quantify only one thing, quantify the cost of delay.” Thus, when the time is right for your team to begin thinking about risk, I recommend starting with concepts associated with cost of delay.

Exercise 1: In release planning and backlog grooming sessions with product owners, coaches and Scrum masters can begin helping product owners incorporate more consistent concepts of value into work descriptions. Have them attempt to quantify:

  • The extent to which proposed work will increase revenue
  • The extent to which proposed work will protect existing revenue (improvements or innovation that sustain market share)
  • The extent to which proposed work will reduce costs
  • The extent to which proposed work will avoid anticipated costs

With these preliminary valuations in place, guide product owners to new processes that will help them (and the team) make better business decisions as to which work should be prioritized based on anticipated impact to the business (Chapter 6 introduced a “weighted shortest job first” approach called CD3).

As familiarity with these approaches grows, guide the team in exploring how to integrate this new information into their visual management framework.

Step 5: Continuously Improve

As reflected throughout the book, Scrumban is usually a journey of evolution, not revolution. Teams should continuously seek process improvements, and continuously improve their ability to identify and prioritize the efforts most relevant to the capabilities they want to improve.

Concepts alone don’t change how we act and think. If we want to achieve meaningful and sustainable change, then we must make a deliberate and conscious choice to practice new behaviors—especially at the beginning. We want to identify and adopt routines that will help us take the concepts discussed in the book and turn them into new mental habits that will make their practice a reality.

Coaches and Scrum masters should use retrospectives as their vehicle of choice for introducing many of the habit-forming concepts we introduced in Chapter 9, such as the following:

  • Fostering consistent and habitual thinking
  • Begin with something as basic as guiding the team on a process for conducting simple experiments (e.g., attacking average lead time by adopting a new team policy on blocked work items)
  • Extend by guiding the team to more disciplined regimens such as A3 problem solving
  • Integrating and using team assessment tools to prioritize improvement efforts (i.e., understand which core capabilities are most deficient and take action to improve in those arenas first)
  • Detecting and avoiding patterns of unsafe change

Next Steps

Try what you learn in this post on your own projects by signing up for a free ScrumDo trial.