Extending Scrum with Kanban practices

In this post I’ll describe three Kanban practices that can be used to improve a Scrum team’s overall performance:

 

Explicit states and policies

A usual Scrum sprint board has three columns: TODO, WIP and DONE. Also, most Scrum teams have explicit policies for the Definition of DONE and the Definition of Ready. The problem is that the WIP state of this kind of board is a black box: anything can happen there. It’s a Kanban practice to define every state that a story must follow before reaching DONE. This approach helps the team to better organize themselves around a common development process and also to define explicit policies for each state transition. A common Kanban board has these columns: Backlog, Define tests, Design & Code, Run tests, UAT, DONE. Also, the team defines explicit policies for each transition, with very specific rules describing even which branch a story should be in a specific board state. Explicit states and policies gives the team a higher level of transparency, enabling them to find better optimization opportunities and standardization.

 

WIP limits

Another Kanban practice is limiting the number of stories that can be in each state at any given moment, forcing the team to focus on finishing things before beggining new ones. This approach also works great for Scrum teams! For example, we could set the following limits for each state: Backlog (8), Define tests (2), Design & Code (4), Run tests (2), UAT (1), for a team with 6 people (4 devs and 2 QAs). In this configuration it is expected that the Product Owner (or his team) will accept only one story at a time, because we’ve limited the UAT to 1. But the cool thing here is that if the Product Owner don’t accept it quickly, the team will eventually come to a halt, because all their states will reach its limits sooner or later. This simple rule greatly reduces the NOT DONE effect, making both the team and the PO a lot happier!

 

Cycle time measurement and optimization

One of the most important Kanban practices is measuring and optimizing the team’s cycle time, which is the average time that a story takes to go from the first to the last board state. A Kanban team strives to shorten their cycle time to the smallest value possible. This mindset also applies to Scrum teams: they can measure their cycle time during the sprint and always compare it to the last sprints, looking for ways to optimize it. The result of this optimization will be greater velocity, allowing the team to commit to more stories per sprint, what is wonderful!

Experimenting with Kanban: Classes of Service

The Problem

Our team handles two kinds of issues: product evolution and maintenance. Even with a very good overall SLA (cycle time), the team was struggling to evolve with an evolution project composed of about 30 stories, due to the high traffic of maintenance issues that kept comming with higher priority.

The Solution: Classes of Service

Doing some research we found this very good article about an aspect of Kanban that we hadn’t tried yet: Classes of Service. We created two classes: project and express. We limited our “express” lane to have at most one issue at a time, meaning that we can’t have another express issue until the former one is solved and in production. Also, with this configuration we forced all our issues to either belong to a project or be an express one, which forced our Product Owner to create “bug fix packages”, for example, instead of putting tons of micro fixes in the queue. And as a side effect, this configuration also forced our Product Owner to use the express class wisely, improving his prioritization method.

Conclusion

After this tweak, our team started to handle both product evolution and maintenance much more effectively. Both our projects SLA and overall SLA improved and both the team and the Product Owner became happier! I really recommend the use of Classes of Service if you are in a context similar to the one described here and I would be glad to hear about your results, too!

Experimenting with Kanban: introduction

Today I’ll start a series of posts describing my recent experiments with Kanban System for Software Development (a.k.a. Kanban). In this first post I’ll describe our context, the core concepts of Kanban that we implemented, the steps that we took to implement those concepts and our conclusion until now.

Our context

We have to maintain and evolve systems that are already in production, which means that we need to deliver new features and fix bugs. The team was doing a ScrumBut: planning sprints but with a lot of interruptions and distractions during their execution, which caused most sprints to end with stories not done.

Core concepts of Kanban

We created a visual board representing our workflow, we are measuring and optimizing our cycle time weekly, we have limited our WIP for each state and we have explicit policies that describe the rules for each state transition.

How we started

The first step was a training session explaining the core concepts of Kanban to our team, that I did it myself. After that, the entire team participated in the creation of our visual board: defining our states, our WIP limits and policies. Then we populated the board with all the stories and tasks that the team was working at that time and scheduled our daily meetings and monthly retrospectives. After that, things went very smoothly, with the team reviewing and improving our states, limits and policies always targeting at shortening our cycle time. They even decided to print our cycle time history every week, so that they can keep track and improve it constantly. We are using JIRA to help us measure our cycle time: we have our stories both in JIRA and on the board, while the tasks are only on the board.

Conclusion

The team is delivering much more than they were with the ScrumBut implementation and they are feeling much more happy now, because they are being able to see their improvement through the cycle time history graph and also because now they know what each one is doing and being able to help each other more efficiently.

In my next posts I will describe the obstacles that we have already overcome and more details of our Kanban implementation. I’d also like to hear about your experiments! Are you trying Kanban, too?