A couple of weeks ago I was discussing Kanban with one of the managers at the client I work for. He was curious about the method and wanted to learn more about it. Having talked about the power of making work visible and limiting work in progress, I argued that perhaps the single most important aspect of Kanban is its ability to drive evolutionary change: One small change will leave the way open for other changes. The response I got was that it sounded like too much of a sales pitch. He wanted to know if I had any experience from projects where this had happened. Fortunately I had…
I have previously blogged about how we introduced Kanban in the post From Scrum to Kanban. In this project several interesting things happened. It was the first project where we tried to apply Kanban practices. Having huge respect on the impact change make on people, we were very careful with making only a few changes. And we took great care in explaining why we thought applying these changes were a good idea. Ultimately, you want the team to pull a change into the process instead of pushing a change on the team. Initially we implemented two changes:
- We visualized our development process as it was on a physical card board using index cards and post-it notes (we had a task board already in the project, so this was a minor change)
- We limited work in progress
Everything else remained unchanged. There were no new roles or no extra planning. Nor were there any new tools to learn. The team could therefore proceed with their work without needing any special training. I believe this was highly appreciated amongst the members in the team.
Limiting WIP will get your change process started
Once we had visualized the value stream and started to limit work in progress, interesting things started happening. The first couple of days we experienced good flow and we managed to move things from the ready queue through development and into system test. After a while though, we experienced that work started to pile up in the system test phase. Since we were at capacity in upstream processes, we were unable to start new work. If we were to respect the WIP limits we had no other choice than to resolve the block in system test. We did so by having more resources do testing.
Having solved the problem in system test (at least for the time being) we proceeded with development as before. A couple of days later we found ourselves pretty much in the same situation. This time around, after having reestablished flow, we wanted to investigate the reason behind this behaviour. One of them was with the way we planned our work:
All team members in the project (3 developers, 1 tester, 1 BA and 1 PM) had previously been doing projects using Scrum and were used to detailed sprint planning with detailed technical tasks and estimates as the expected outcome.
It turned out that we were still planning work into technical tasks and that we were tracking these on our board. The problem we now saw, with WIP limits and having system test as part of our process, was that these tasks just weren’t testable from a testers perspective. So we sat down to discuss the matter and after a really good discussion, we ended up on agreeing that all “tasks” or “features” needed to earn their place on the board by being truly testable. We found that the easiest way to achieve this was if we managed to focus our tasks around business value. (We referred to these as tasks rather than stories, but looking back at it we were really creating small stories)
One change often leads to another…
Interestingly enough, this change led us into questioning the way we did our planning. Discussions in planning meetings were quite often focused around technical details. We agreed that these technical discussions did not provide any value. On the contrary, these discussions would often make us drift away from the really important stuff: Understanding which product to build. We decided to make an effort not to go into too much technical details in our discussions and instead focus on the actual requirements.
The result was an improved planning process. Not only did we manage to cut the time spent on planning to about 50 %, the common understanding was also that the outcome of the planning had improved. In our daily work it led to an improved flow of work through our process, all the way from the input queue, through development, system test and to the done queue.
Small incremental changes proved to be a successful recipe
The project turned out to be a success. It was delivered on time, at cost and with high quality. Team members were happy. In fact, during the project retrospective meeting several members of the team told that this was one of the best projects they had ever been on. I think one of the main reason behind the project success was the teams’ ability to do small positive changes helped by the incredibly powerful technique of limiting work in progress.