Kanban improves self-organization

Today I’m very excited to share with you an incredible side effect that I’m observing in all Kanban implementations that I’m coaching: all teams are improving their self-organization skills! Teams that already had some self-organization are improving it. Teams where their managers were still doing command-and-control are now becoming self-organized, leaving more time for their managers to focus on more important things than scheduling each and every task to their team members.

For instance, before Kanban, a team member wasn’t ever concerned with his colleagues’ work if it didn’t interfere with his own, because his objective was to finish his work only. After Kanban, his objective became to shorten the team’s cycle-time, which is a team-wide metric. With this in mind, all team members started to help each other, which improved their overall delivery rate. This is a very clear example of self-organization improvement!

Another very interesting example is a team where their manager was still doing command-and-control. With the Kanban board he started to focus on the tasks entrance queue only, leaving to the team the job to pull their work. The thing is that this “simple” change is the turning point from command-and-control to self-organization! Which means that now his team is self-organizing itself! This change also freed him much more time to focus on impediments resolution and process improvements with his team, which means that now he and his team are talking more about higher level things, smarter things, things that can really improve the way they work. Amazing!

Conclusion

Kanban improves self-organization in two very clear ways: by forcing a pull workflow instead of push, which breaks command-and-control on its roots, and by setting the team-wide objective of shortening cycle-time, which induces all team members to be more collaborative, efficient and effective.

Experimenting with Kanban: the work is flowing!

One thing that I teach during a Kanban implementation is that the entire team should clap when they make a work item go through their entire workflow. This helps the team understand and internalize that their work has value only when it reaches the final step of their workflow, which for software teams its usually a deployment in a production environment.

There was a team, in particular, that was struggling to complete their work items and no one could understand where the problem was. After I helped them implement Kanban, the two main problems appeared on day ONE:

1. The acceptance step was taking too long, accumulating many work items. Everytime this happened, the team started new work, which was causing a lot of context switching when they had to fix bugs or deploy the accepted work to production.
2. New work items were arriving very poorly defined and with many pre-requisites missing, which caused a lot of work items to halt in the middle of the workflow, causing high traffic on their wall board and many context switching between work items.

To solve the first problem, the team stopped accepting new work if the work already at the acceptance step didn’t get approved (WIP limits!), which forced the business guys to focus on accepting the work already done before asking for new work. To solve the second problem, the team started to refuse work that was poorly defined or with pre-requisites missing (explicit transition rules!), which drastically diminished the halting problem.

At the beginning, this team seldom clapped, at most once each 15 days. Today, this team claps every single day, and I’m not kidding! Today we can say that the work is flowing!

Conclusion

People really want to deliver and improve the way they work, sometimes they just don’t know how. Kanban, with its visualization, flow and explicit rules, helps any team find their bottlenecks and solve it, starting at day one!

One great advantage of Kanban over other agile frameworks: no disruption

The Kanban method practices can be resumed in: Visualization, Flow and Explicit Rules (WIP limits + state transition rules). The interesting point here is that none of these practices implies that you will need to change how you work today. You can start a Kanban implementation simply by:

1. Drawing your actual workflow, understanding it and mapping it to a Kanban board, to achieve visualization;
2. Paying attention to your actual flow, measuring it and assessing its efficiency, so that you can start to track and improve it;
3. Turning your rules explicit by writing them on your Kanban board, so that you can understand how your workflow steps relate to each other;

After you do that, you will start to understand your actual process more deeply, and as a consequence you will be able (and willing!) to improve it. Not just you, but all the people involved in your workflow! You will also start to question if some steps in your workflow are really necessary. Better yet, you will start to question why some steps are taking so long to complete and why some activities always accumulate at some steps.

Relating to your flow, you will be able to track the time needed to complete your work items and how many items your team can deliver at any given period. With this information at hand, you will even start to know your real capacity! As a consequence, your team will enjoy splitting and scheduling their tasks so that they can deliver their work items as fast as possible.

By turning your rules explicit, all the people involved in your workflow will start to behave better, because they will clearly understand what each other needs to do their tasks more efficiently and effectively. Better yet, you will be able to improve those rules, now that you know them explicitly, resulting in a faster delivery rate of the work items on your Kanban board.

Conclusion

A Kanban implementation can always start with no disruption: as simple as a map to help your company understand how it is operating today. This map will show three things: today’s workflow steps, today’s flow and today’s rules. Once you and your team understand how your company is operating today, you all can start to improve it. And believe me, people really wan’t to improve and deliver faster, they just don’t know how… but this is the subject for another post.

Kanban is not go horse!

Many people new to Kanban think it is a “go horse” method: one that you do whatever you want, without any planning, nor cadence, nor predictability. Those people couldn’t be more wrong! There are four practices that are mandatory in Kanban:

Visualization

You must visualize your work and how you work, so that you can understand it and improve it. The most common method for visualization is a wall board with a map of all the states that your work items must pass, from concept to delivery.

Flow

You must measure and optimize your cycle time (or flow), which is the average time needed for a work item to go from your first state to your end state.

WIP limits

You must limit how much work can be at each state at any moment, so that you can improve your process, know your capacity and shorten your cycle time.

Explicit transition policies

You must define explicit transition policies between ALL your states. This ensures that everybody is following the same rules, thus making your process very clear and repeatable by everyone. Those policies include the famous “ready” and “done” policies from Scrum, as they usually map to the first and end transitions on a typical Kanban board.

Conclusion

So you cannot do whatever you want, because you have very explicit rules. You can have as many states as you see fit, so you can have a “planning” state, also. By measuring and optimizing your flow, you have cadence and predictability. So, no, Kanban is not go horse!

Workflow mapping to a Kanban board: state, queue or transition rule?

A common question that arises once you start implementing Kanban is whether a step of your workflow should be mapped to a Kanban board state, queue or a transition rule between two states. My approach to this question has been this:

State

If your work item will usually be in that workflow step for at least an entire day, with some tasks going on until it can be considered ready to move on, then this workflow step should be mapped to a Kanban board state.

Queue

If your work item will usually be in that workflow step for at least an entire day, but without any task going on, then this workflow step should be mapped to a Kanban board queue, which is a buffer to your next state so that you can smooth your work items’ flow.

Transition rule

If your work item will usually be in that workflow step for just a couple of hours, this is a very good sign that maybe this workflow step should be mapped to a transition rule between two states of your Kanban board. Our teams usually create one task for each transition rule, in addition to the other tasks needed to consider a work item ready to move on, so that they ensure that no rule will be forgotten.

Conclusion

It is important to have in mind that you can always change things until you find the best format for your Kanban board. You can always start with a workflow step mapped to a Kanban state and after a week or two you can try to transform that state in a transition rule, to test which configuration works better for your team.

What do you think? Does it make sense?

Experimenting with Kanban: keeping track of a roadmap

One common question that arises when we start a Kanban implementation is if we won’t lose track of the macro roadmap of our product due to Kanban’s continuous flow. It’s generally accepted that Scrum forces the Product Owners to plan some sprints ahead and also to have a release plan for his product, while Kanban don’t prescribe sprints nor release plans. Well, the answer to this question is: yes and no.

Yes, we can lose track of the macro roadmap of our product due to Kanban’s continuous flow, because Kanban offers this degree of freedom. It’s also this freedom that enables Kanban to be used in a lot of contexts, like the one of infrastructure teams, where they don’t have a roadmap to follow, but mostly incidents to solve.

And no, we can still keep track of the macro roadmap of our product using Kanban with two different approaches. The first one is by forcing the Kanban work items to be features, or better yet, MMFs, instead of small tasks, so that our entrance queue becomes a roadmap. We can also control the size of our entrance queue with a max limit and we can have a rule stating that we should not have less than N features on it at any time. This will force a roadmap and yes, you will still be doing Kanban. Another approach is to use Kanban with iterations, instead of continuous flow, thus forcing the planning of your iterations and maybe forcing a release plan, too. And yes, Kanban don’t prescribes continuous flow, too!

Doing Kanban with iterations is usually called Scrumban. 😉

Focusing on product advancement instead of the development team performance

Even though cycle time is a good metric about team’s peformance, as I described in my previous post, all stories and features that a team is delivering should be validated by the Product Owner (or Product Owner team) once they are in production. This validation should check if the stories and features just delivered made the product advance in the way it was expected.

But what is this product advancement thing? Well, it depends on your product’s context. Better yet: it depends on your key performance indicators (a.k.a. KPIs). A product is advancing if it is improving its KPIs. As an example, if your KPIs are pageviews and number of subscribers, then your product advanced only if the delivered stories and features increased your pageviews and number of subscribers. This post describes a very good way to define your KPIs. This book is also a very good reading about how to define your product’s advancement metrics.

My point is that many companies are more concerned with their teams’ capacity: how many story points a team can deliver or how long is a team’s cycle time. But they should be more concerned with their products’ advancement! A team’s capacity is only a mean for achieving something greater: product advancement. And product advancement is achieved only if the right stories and features are being prioritized.

What do you think? Makes sense?

Experimenting with Kanban: the cycle time metric

If there is a Kanban practice that keeps surprising me again and again is the cycle time metric measurement and optimization. We defined cycle time as the average time that a story takes from our first state (backlog) to our last state (production). It tells us how much time our team takes to finish a story, on average.

Compared with the velocity metric that most Scrum teams uses, cycle time proved to be more accurate for planning and simpler to comprehend. It is more accurate because it is something that we are measuring and not something that we are guessing. And it is simpler to comprehend because its measurement unit is time and not points. While time is something that we have been dealing with since we were born, points are an artificial unit created to simplify software estimation, which is a very complex task by itself. So, instead of guessing how many points each story costs and then taking as much as the team guesses it can handle in a sprint, we know that the team finishes one story every X days, on average, and that N stories will take them (N * X) days to finish, on average. Much simpler!

My first surprise was when I saw the number of stories one team was refusing after we started to measure cycle time. When I asked them why they were refusing those stories they told me that they were refusing them because those stories were missing some important pre-requisites. Those pre-requisites included: other team’s components readiness in our integration environment, infra-structure, definitions etc. Without those pre-requisites they were likely to come to a halt during development, what would affect their cycle time directly! WOW! Very nice! For the first time, the team became aware of the importance of their definition of ready! And they were fighting for it, now! Amazing!!

Another great surprise was how the team became concerned with their cycle time to the point that they decided to print their cycle time evolution graph and put it on the wall, above their kanban board, so that they could always track it and discuss actions to improve it during their daily checkpoints. This behavior answered a concern that I had since the beginning of our kanban implementation: couldn’t the team become slower without the sprint’s timeboxes? And today I can tell you for sure: NO! The answer is: cycle time. 😉

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!