Let’s take a moment to visualise the success. Hard, isn’t it? In order to do such thing, David J. Anderson gives us a helping hand and writes about the real-life example. The story of Dragos Dumitru will show us how to follow the path of Kanban method and shift from the worst to one of the best teams in the Microsoft group.
What can Kanban do for you?
First of all, Kanban allows you to implement changes through its Kaizen culture. Kaizen means continuous improvement, using it grants you the possibility to easily influence the current situation, e.g. adapt your rules to your environment, etc.
Kanban offers also improvement opportunities without deep changes in the software development processes. And therefore Kanban enables you to introduce changes with small political resistance.
After applying the Kanban system to Dragon Dimitru’s team the productivity was improved by over 200%, the lead time was reduced by 90% and the predictability also raised significantly. However, it was not a rapid process. The improvements need time to work. Overall, it took around 15 months to finally note down the expected results.
It’s important to realize that substantial progress is possible only when you optimize bottlenecks, avoid waste and reduce variability which influences customer expectations and satisfaction.
How to implement a Kanban system
The first Kanban system was established in the XIT maintenance team of Sustained Engineering Software of Microsoft in 2004. It was implemented within an offshore team in India. This particular unit had the worst reputation regarding customer service in the Microsoft enterprise when Dragos Dumitru became a project manager. Not only the customer service was unsatisfactory, the lead times were long and many open requirements not finished.
At the very beginning, Dragos Dumitru visualized the current workflow in his team. It helped him notice the factors which affected the productivity: the requirements flew uncontrolled in the system, new ones, including undiscovered production errors, were constantly added.
The team also had to do the cost estimations which consumed a lot of the time. These estimations were used to decide whether certain requirements should be implemented or not. Therefore, they had a monthly prioritization meeting. But more than 70 requirements are newly planned and prioritized in these meeting and that lead to disappointed requesters.
Another important issue were additional tasks in the form of Production Text Changes. These came without warning and had to be taken care of by the testers. They worked on them immediately which forced them to leave their primary tasks unattended. .
After Dragos Dumitru discovered the problems he started engaging a Kanban system into his team. The group followed a process given by their managers, and what I mean by that is a set of rules which define the behaviour during certain tasks.
Yet, every situation is different so certain regulations had to be changed during the process. Dragos Dumitru’s decision was as follows – no more cost estimations! From now on, the product managers were the ones to decide upon which requirements should be implement next.
Consequently, he restricted the work in progress to one single requirement per developer and tester,he also added an extra queue for the Production Text Changes. The supply of the product was promised for a 25 days deadline.
The changes worked. The team could satisfy the 25 days limit for supply and the meetings proceeded without any complications. According to the Kanban Dragos Dumitru adjusted the process rules:
- every ticket in the backlog older than 6 months gets deleted
- the weekly prioritization meetings were also omitted
- the prioritization was done via e-mail
Kanban at Avarteq
Here in Avarteq, for every single project we define explicit process rules at the beginning. They are gathered in the Kanban policy of the project. What is obvious, they differ depending on the project. Nonetheless, if during a project we notice that one or more rules don’t work too well, we can easily adapt them to our needs. We also add regulations if we feel something is not clear or omitted.
Let’s take a look at the example. During one of our projects we had weekly Kanban meetings. After some time we observed that these meetings took too much of our time. So we decided to change our rules – the weekly Kanban meetings were replaced with daily stand-up meetings which lasted only 10 minutes. As a result, everyone has to focus on the important things and we can react faster if there are any complications.
Another adjustment affected the cost estimation in our team. We usually have 4 estimation types for tasks: small, medium, large and extra large. But sometimes it’s difficult to decide which estimation time to choose, therefore sometimes the wrong ones were chosen. To improve the predictability, we decided to work only on small tasks. If one assignment is too big it has to be broken down to smaller tasks, which made our work much easier.
I hope I gave you at least a general view of what you can achieve while using Kanban. Only through visualizing the workflow Dragos Dumitru discovered the problems in his team. Then he used some basic Kanban methods and with these little changes the team could improve to a great extent, without even changing the process of software development.
In my opinion, that is one of the biggest advantages of Kanban, it gives you some ‘ready-to-use’ methods to describe and define your process. But remember, you are the one in power, you can adjust everything so that it fits your needs.