Kanban at General Secretariat of the Council of the European Union

We did a couple of  introduction workshops back in April where we discussed the foundations of agile development, talking about the values and principles behind it. We introduced the participants to the basics of the scrum framework as well as a short tour around the Kanban method. We also digged a bit deeper into agile project management, regardless of the framework or methodology used. It was enough for 1 team that mostly did projects that take somewhere between 3 and 12 months to start trying to apply scrum. While at the same time the second team picked up Kanban as their methodology since they had a lot more changing priorities, mostly because of the short nature of their projects.

After a couple of months of experimentation it was time for a facilitated retrospective and a more elaborate workshop on how to implement all the finer details of the Kanban method. So we went back in October to see how the teams were doing and how we could help them to improve even more. On day 1 we started off by explaining the father of Kanban, the theory of constraints by running the bottleneck game simulation. This helped to build a basic understanding of why Kanban works the way it does and what the principles are behind the scenes. By going through all the focusing steps of the theory of constraints, we optimized the Return On Investment of each team tremendously. Next step was to start building the metrics needed to measure if improvement actions are really improving the system or not.

For that we looked into cycle time variation reports to help them determine the common cause variation within their work items. By mapping out all the finished work in this chart, both teams quickly realized they had several categories of work, with very specific control limits.

So this was the basis to go into the next chapter of the course, Classes of service. Both teams came up with 3 different classes of service based on the cycle time of each category and external expectancy. All classes of service were given a descriptive name so that people outside the team could also relate to them and help with determining the correct class of service for new items. Day two started off with build a board for both teams, based on their actual work done over the last few weeks. We did a team-focused value stream mapping and came up with a general story for their work. Starting from the real work items we started plotting out the different steps each work item passed through. This was a very difficult exercise for most team members and opened up a lot of items to discuss in a retrospective. Because these items were clearly very deeply rooted in the mutual understanding between the team members, I choose to stop the workshop and go into a small retrospective for an hour. After that we continued to map out different pieces of work and ended up with a general workflow for each team.

Second graph to look into was of course the cumulative flow diagram. In this chart a team can visualize all their work, being it in the backlog or ongoing or done. This graph will also help you in finding and measuring  possible improvement for the WIP limits. In this diagram you can easily see where the bottleneck of your system resides and how changing the WIP limits moves this bottleneck around. Since they are strongly related, next step was to determine initial WIP limits. There is no magic formula for this, the only thing we always advise teams is to think about the number of items they think they can effectively manage in parallel and then subtract 2 from that number and start with that.

And never forget that the best way to speed up work items being finished is by lowering the WIP limit. On day 3 we had a big retrospective, going through all the questions both teams had and finding options for each of their major issues. In the afternoon, each of us went with one of the teams to facilitate a retrospective on their specific problems and needs. And both teams came up with 3 improvement actions to be implemented in s short period of time. Both teams have been bootstrapped with Kanban enough to get started. We will be visiting them again in a couple of months to see their progress and discover if and where we can still assist them in improving their system. But for now, they have all the tools they need to become more effective.