So what IS Scrumban?

3 years ago in Agile Israel 2009 I talked about ScrumBan. The slideshare presentation has been one of most popular ones, and remarkably enough it is the second hit on google when searching for ScrumBan. Go figure… Anyhow from time to time people ask me where they can go look up what Scrumban is and I find myself not sure where to point them for a good brief description. I have a problem with my presentation - it is not aligned with the “Kanban Method” for evolutionary change. It is more applying Kanban together with some Scrum concepts as a mashup. This can be a great process framework for teams starting up (which I want to write about in an upcoming post), but it is NOT Scrumban.

Among-st the Kanban community ScrumBan is the name given to applying the Kanban Method for evolutionary change to a Scrum context. You start with an instance of Scrum and apply the Kanban thinking to it. In this post I will try to give a concise description of how that might look like.

Let’s say you applied Scrum. If it works great you are able to deliver working tested software every sprint, there is sustainable pace, great collaboration, and no feeling of wasted time around the edges. Your retrospectives are about finding impediments and dealing with them, and not about estimation accuracy and commitment woes. If that is the case, I’m not sure you need ScrumBan to help you with the team capabilities. Start looking outside the team for how to improve. Consider using Lean Startup ideas to deliver more of the right things, or DevOps/ContinuousDeployment to shorten the time to market.

Most teams though are not there yet. They are having problems with their sprints. Stories leak out, Software is not necessarily working or tested, and the discussion in the Retrospective is focused on how to calculate the right velocity, what % of time to allocate to surprises, estimation inaccuracies and other such problems. If you are working in or with such a team, ScrumBan can help by giving you a change management process you can use as a guide on your improvement journey.

ScrumBan is an application of the Kanban Method, so naturally the three basic principles apply (David J Anderson recently wrote a concise post about the Kanban Method and whether it is a framework or not, you should go read it):

1. You start with what you do now - That is your Scrum. All the ceremonies, artifacts, roles and responsibilities you are currently using. That is right, You start with everything. The Sprint, Scrum Master, Sprint Backlog, Taskboard, Sprint Burndown, whatever you are currently using.
2. You agree to pursue an evolutionary approach to change - You understand that things will change over time. You might adapt some of the aspects of Scrum. You might add new practices/policies. You might drop some. The important thing is that you agree to pursue improvement towards a process that is more effective for you, one that will help you meet your business goals more effectively.
3. You initially respect current roles, responsibilities and job titles - Again, you start with your Scrum and your organization. You don’t change the job titles. Whatever you did so far with your Scrum implementation, that is where you start. You might get some ideas for change when you read about ScrumBan and Kanban, but the Kanban Method is about considering/introducing those changes when they make sense, not as a big change up front.

After understanding and adopting the basic principles, you start using the Kanban core practices. I will use David’s recent language and elaborate on what they might mean in a Scrumban context

1. Visualize - make the invisible work and its workflow visible - Some Scrum teams already visualize work and its flow. One of the keys to effective visualization of a Scrum context are making sure you see the flow of backlog items from early requirement to done. It is not enough to visualize the sprint backlog. It is important to make the flow of work into and out of the sprints visible as well, since many teams have difficulties exactly with this aspect. In addition, Scrumban is typically about visualizing the flow of Product Backlog Items (PBIs) or Stories, rather than Tasks. Tasks are created late in the game and don’t flow all the way. Some teams visualize tasks as well, but it is optional.

2. Limit WIP - implement a virtual kanban system - Once you have a Kanban board visualizing the flow, the next step is to implement a kanban system. This calls for Limiting the Work in Progress, which in Scrum context basically means you limit the amount of PBIs in progress at any point in time. Once the limit is reached, the alternative to starting a new story is to go and help others deal with their story. This can mean helping others in your expertise area or going upstream or downstream to help (e.g. Developers help Testers, Testers help Product Owner, etc.). Limiting WIP introduces pain. The pain of not being able to do what you’re comfortable with and got used to. We want to channel this pain towards ways of improving the team’s process and policies so in the future the flow will be better and the WIP Limit will be less painful. Improving engineering practices, using techniques such as ATDD, Reducing batch/PBI size, Cross-training, or any other technique can be considered as a way to make the WIP Limit more comfortable. Over time as team capabilities improve, the WIP Limit can be tightened to catalyze even more improvement in capabilities. Limiting WIP is a great way to drive real collaboration at the team level. Side Note: that the “Sprint Backlog” itself is a WIP Limit - it limits the amount of PBIs that can be started during the sprint unless all of them are finished. It is a shame that many teams and even coaches miss this point. In any case even if you are treating the Sprint as a WIP Limit, Using granular limits on number of stories active during the sprint will help you improve flow even further.

3. Manage Flow - with the virtual kanban system in play using WIP Limits, it is now time to run the system and manage the flow. Teams start looking at the cycle times of PBIs/Stories for information on where there is room for improvement. They monitor cycle time/aging in real time to see struggling stories and find ways to help them along. They care about the healthy flow of work (which within a sprint is not less important than whether the sprint forecast/commitment is met - but more on that elsewhere). They start using Cumulative Flow Diagrams which add information about the queues within the system to a Burnup chart.

4. Make management policies explicit - Some scrum teams make their “Team Rules” explicit. This is a similar approach. You make your process explicit. Both so empowerment can happen - people on the Scrum Team cannot be empowered if they don’t know the process. Self Organized teams cannot work if they don’t have a shared understanding of how work is done. But making the process explicit also helps improve. With the “invisible” process now made visible, healthy discussions about “why we do things this way” or “how will changing this policy affect our flow/results” become easier and happen more naturally. Remember that here we are talking about the team’s policies for how it manages itself. Some of the policies might be driven by the organization and require management approval for changes. Many of them will belong to the team and should be evaluated and experimented with actively as part of the Retrospectives.

5. Improve Collaboratively - using models and the scientific method to implement a “guided” approach to evolution. Start treating your Retrospectives as the place to design experiments. With an idea of how something might improve your capabilities, Plan what you aim to test, what will be the validation that you are on the right direction, and in the next Retrospective review the results and decide whether another round of experimentation is necessary (Pivoting) or whether you can deploy the change as a standard operating policy for the team. Use improvement frameworks such as A3 / Toyota Kata for this process. Invite in models like Reinertsen’s Principles of Product Development Flow to understand the interaction of Batches, Cadence, Heartbeat, Teams, Variability, WIP, Cycle Times, in ways you never had before.

So far I just talked about the guiding principles and the practices you follow when applied to the change process. Beyond this point, any more changes to the way you work will emerge from what you discover when you visualize the flow, limit the WIP, make the management policies explicit, and start to have collaborative improvement discussions focused on hypothesis, experiments and learning what works.

You probably feel “cheated” at the moment. Is this all there is to it? Where’s the actual stuff? The changes to the sprint model? What about the roles? One way to finish this post would be to stop here and emphasize the complex nature of each team’s context and how we don’t know exactly what will emerge.

I will risk going a bit beyond that and share a couple of emerging behaviors seen in teams that go on this journey. Not all teams will see the same patterns. And don’t go using these patterns as a recipe book. Doing that might be useful, but it is a different kind of change process. I will write in the future about “Kan-Beat”, “Kan-dance”, “Kan-Bum” or whatever we decide to call the approach of starting a team with a Kanban+Scrum mashup. In the meantime you might get a few ideas for how to design a useful green-field process.

Rolling Finish/Start of Sprints

One of the first things teams realize when they start thinking about flow is that the sprint represents a “Batch Transfer” process. Many PBIs wait to go into a Sprint or get out of it, even though they are ready and could be processed without wait. In addition they realize the requirement to “clear the table” when finishing a sprint and “restart the machine” when starting again is in conflict with smooth sustainable flow. So what typically happens is that the Sprint Cadence becomes more of a heartbeat of rallying points to summarize what happened since last time, think about improvements, and do some look-ahead planning. Think about pit-stops in motor racing. The aim is to minimize the time it takes. If it could magically become one of those “Refuelling zones” in video games where stuff just magically happens to your car while you pass in the zone without even so much as a slowdown, it would be perfect. A word of caution is that some way of maintaining “Sustainable” pace should be used. “Jogging” periods each sprint are only one way to do it. Just be careful not to go into an endless stream of work. After all we are talking about human beings not machines.

Sprint Planning-Lite - Deemphasizing Estimations and Forecasts

When teams understand that limiting WIP is a great way to achieve the focus and fast cycle times, they more often than not ask themselves about whether they still need the Sprint Commitment as a way to focus themselves. Combined with the fact that people exposed to Kanban start to hear case studies and examples of teams that replaced estimations with just ensuring small enough units of work and use cycle-time based forecasting rather than deep up front estimations, they now explore what I call “Sprint Planning Lite” - a ceremony which is more looking at the big picture of upcoming work items and making sure it is a coherent picture and the items are ready, and give a general forecast what will be delivered and a specific forecast for items that are time-sensitive. Typically less time is spent on calculating accurate capacity - a big picture of main capacity changes from last sprint is enough just to have early warning of flow problems (e.g. tester is away for a few days on an Agile Testing workshop). Some teams don’t even look at each specific story in-depth deferring this discussion to the time it will be pulled into work. Some teams do a high level estimation using a lightweight team estimation game to make sure they are aligned on the story implications, and have a discussion only about specific stories. I found this style of planning is like a fresh wind to most teams, so it is well worthwhile trying.

In this post I started by saying ScrumBan isn’t a development process in and of itself. It is a process for evolving a Scrum instance to be more Lean/Flow oriented.

Then I talked about how this change process works by enumerating Kanban’s basic principles and core practices as applied to ScrumBan.

I then added some emerging properties when applying ScrumBan to Scrum. When you apply ScrumBan to Scrum you might end up with some of those or other ones.

It is now up to you, the reader. ScrumBan/Kanban/Scrum are just means to achieve an end. Start with why you need to change anything in how you do things. Visualize the invisible to have a better grasp where you are. Design experiments and validate your thinking on ideas that will improve your performance, pivot away from useless/harmful practices and drive towards what attracts the results you seek.

If you’re interested in some help figuring out if ScrumBan is a good fit for you and how to go about implementing it, I can help.