Implementing Kanban in Practiceoriginally written by Vikram Gupta
Our summary and key takeaways
In this great interview, InfoQ talks to dr Arne Roock of IT-Agile about the process of getting started with Kanban, what is and what isn't advisable and whether you need external help or not.
The first observation made, is of the fact that Kanban is not a project management method as such, that it is mainly a change method. The only difference when approaching this choice in making the decision whether you want a change or not. Once this is decided on, there are two ways to go about it - making a revolution (applying the change right away) or doing it steadily and gradually.
When starting to apply the methodology, this is Dr Roock's advice:
- Let the management know about this, in order to be able to run this change through as much big an work area as possible.
- Visualize the work, which is crucial for knowledge based organizations, in which you cannot see the tasks completed or pending, since they don't exist physically. Thanks to this, teams very often begin to appreciate just how much work there is in progress (started but not finished). Visualization of tasks brings about better understanding of the task queue and the team's overall capacity.
- Create a feedback and review system - this will allow for the workflow to be controlled and improved as quickly as opportunities arise.
- Manage the workflow - with the great transparency that a Kanban board provides, it's easy to spot bottlenecks and manage the resources in a way which will enable the system to function better.
- Take the opportunities to always be improving - with daily or weekly meetings in front of the board, it's easy to see the team's and process' weak spots, improvement chances and to sum up what works and what does not.
- Introduce metrics - depending on what exactly do you want to be working on improving, choose the right one for you (Cycle Time, Cumulative Flow etc.)
How big a team it's best to start with?
When asked about how big (far reaching) should the starting Kanban be, Roock makes a good point of not stretching it any further than the reach of your control. Sure, it would be great to get everyone in the organization to change the way they work into a more productive one, but if you aren't going to be able to control it, it won't get anywhere far. So, start small and extend as and when it becomes possible. If you do it right, people outside the team will begin to notice and will be naturally curious about how it happened and how can they get this too. He goes on to underline the necessity of staying respective of current roles and processes, when applying Kanban from the start. Making diametrical changes from one day to another is very rarely successful.
Physical or online Kanban boards?
Dr Roock acknowledges the electronic Kanban boards, but remains convinced that at the beginning it's best to have the board present in the room, also for distributed teams, which can use a buddy system with success (people responsible for mirroring the board in the other location). But with more than two locations of the team, he certainly suggests switching to electronic boards, but underlines the need to keep other means of communication open (if possible, joined stand-up meetings).
How many details should the board represent?
There is a great rule of 3 by 3. When standing 3 meters away from the board, within 3 seconds you should be able to tell what the current process stage is. If you only have the crucial stages on the board, this is most likely possible, but if you have a great number of columns and swimlanes, this will not be doable, you'll get lost in it.
Dr Roock refers to the difference between Scrum and Kanban WIP limits - Scrum puts a limit on the number of items in a Sprint, whereas Kanban limits the amount of work at any given time by column, swimlane or person. He stresses, that we shouldn't confuse a blocked item with one that is being worked on, neither should we make a blocked item equal to an expedited one. Expedited items are very costly for the team, and therefore having one of these shouldn't mean we're ready to pull more work in, rather that we need to place more resources into solving this.
Is an expert necessary to get started?
This depends very much on the team's approach, experience and size. If there is someone in the company that knows enough about how to implement Kanban, this may be enough, but if they only know a little bit, it may be very tricky and lead to discouragement, especially in larger teams. Should you need an expert consultant, it's recommended that they coach your team in often, but short bursts. This way any problems are picked upon before they become a habit, and quick process improvement is more likely to take place.
Arne Roock's final advice is to never start doing Kanban simply by the book. The crucial part of Kanban is understanding the process, making improvements as and when they are needed, more than following a strict textbook on best Kanban practices. Kanban is for you, not the other way round.