There are many reasons why you want to try a new way to do your work and in the Agile world, there are many methodologies or techniques that you can try. No matter which way you want to take, always an example is a helpful tool in the first steps.
I will try to show you in a simple way Kanban as a powerful and easy option to start with a new methodology.
The Basic Implementation
If you are here, maybe you know what Kanban is; if you don’t, you can find a short and effective reference in this post by Germán Nemes.
As Kanban is a low prescriptive methodology, all you need for the minimal implementation is a three column table and an already prioritized backlog.
At this point, you may not be in a position of putting a limit for a work in progress. You need some time to see how the work flows through the table, from left to right. You need to be patient and learn from what your team does every day.
A Possible First Improvement
Suppose that you have already started with Kanban in its minimal expression as we showed above. After a while, you started to identify some patterns or behaviors. Suppose that what you started to see is that some tasks that you have already considered Done return to the Backlog as bugs from the Testing team. In accordance with the frequency that this occurs, it is time to bring Testing to the Kanban flow. Your table will evolve to something like this:
In company with cross-functional teams, this is an easy and natural evolution of the process. Actually, many teams start their boards in this way.
Therefore, depending on the team structure of the organization this is not an easy change. When the companies are based on very specialized Silo Teams (Design, Development, Testing, etc) and this type of evolution is not possible, you can use your Kanban observations to show the needs of a structural change.
Testing as part of the flow has a lot of benefits, all of them are related with saving time and money. I think that one summarized all of them: you can say with high confidence that when a task is done, it is really done.
This is just an example, a great characteristic of Kanban is that you can work in the area of your processes that you need, without hard guidelines or restrictions.
Metrics
It will not be long until you feel that the empiric observation is not enough to understand how the things are going with Kanban. That is the moment to start with some metrics strategy. You can check this post of Pablo Corvalan about the need for metrics to learn faster.
There are some well-known metrics in Kanban. The Cumulative Flow Diagram is the most known chart because you can get information about different aspects of your processes from it. Pawel Brodzinski wrote a very good guide about the CFD in this post.
Despite the common metrics, as Kanban is low prescriptive, you are free to measure what you want (this is one of the characteristics that I like most of Kanban). While Scrum focuses on the Velocity of the team or some other KPIs; Kanban allows you to explore freely any area of your processes. If you are interested in your team’s Velocity, you can measure it, but if you consider that the Velocity is not your problem, you don’t need to do it. If you want to see what is happening with your estimations, just measure it. And so on.
Our Team Experience
We started using Kanban based on the experience of another team in the company, then our first table was more complex than the three columns table showed above and we measured the whole process from the beginning. In a blackboard and with blue masking tape we draw our Kanban board: that was a fun day.
Something that was very exciting was that other teams that work in the same product with us start with Kanban too after our initiative.
Part of our team was in another location, then we quickly moved from a physical to a digital board. While we worked with a local board some of us moved the post-it notes of the remote team members through the board. We also started with daily meetings, this was very useful in order to consolidate the team despite the distances.
At the beginning, Testing was not part of our board, but we included them soon. After this, we started to notice that the number of reopened tickets was a little higher than the company average. With this metric we had information to change our process: we implemented a functional review before Testing. This change not only lowered the amount of reopened tickets, but also allowed us to learn about how we were doing our job collectively and the effort for each review was very little.
After a couple of weeks, we had a lot of information about our team:
- Our velocity
- The distribution of our work by project / type of task / developer
- Our precision in the estimations and when we had more accurate estimations
- The average size of our tasks
- Where we had bottlenecks
- etc.
We continued making changes to our process, but as first experience example I think that the story at this point is enough.
Conclusion
If your team is not following any Agile methodology and you think that starting with Agile could be good for you, Kanban is a very good option:
- it is low prescriptive and easy to learn
- it almost does not change the way you do your work (for sure you have a list of task to do and possible status for those tasks) you can start with Kanban
- You can get information to validate the changes in the process and to verify the results of those changes
- If you have references to previous experiences with Kanban, these points are easiest to reach.
At this moment, we moved our methodology to Scrum. Scrum is more structured and it is heavy to implement. In order to start with Scrum, maybe, you will face many cultural changes. Personally, I think that my own experience with Kanban help me to understand better and to apply better the Scrum principles, ceremonies and tasks.
Again, if you want to start with Agile my advice is:
- start with Kanban,
- learn about your process and your team,
- improve your processes.
And after significant time and if you feel that your organization and your team need another approach, then start to investigate Scrum or some other methodology.
