After a long time of trying to figure out how to approach the difficulties we have in the team I’m currently focusing on, I decided to try and sell in Kanban.
The team have been doing Scrum for about a year and when I first got here the first thing we needed to do was achieve a cadence with all the work related to the backlog in order to get it in a better shape. Now that we have done that we can start focusing on other things. One in particular is our inability to get things from the code review stage to done. Despite many different attempts at tackling this issue, we haven’t found a sustainable solution. We always seem to fall back in to old habits.
So, after a few months of struggling with this, I decided to try and convince the team to try Kanban in order to manage the work flow. This was not the only reason for wanting to try Kanban, but the one related to work flow. A few other positive effects I expect to see from this transition is:
- Slack time and the possibility to innovate
- Higher throughtput of stories
- Higher quality with fewer bugs
- Happier stakeholders with more frequent releases
- Better teamwork
The first version of the board is resembling the current work flow with very few limitations.Kanban is all about working with the WiP (Work in Progress) limits for each column. To start with I have only limited the team to work on two stories at any given time. This will of course change because I’m already seeing areas where other limitations will increase the focus, but I will let it be for now.
This was the first post regarding the transition to Kanban, I will definitely follow up on this and provide more metrics along the way.