How do you go about converting a development team from Scrum to Kanban? Can we benefit from incremental improvements in projects under high pressure?
Here is a case study of a team who transformed from Scrum to Kanban and managed to save a derailing project. I hope it can inspire others to experiment and improve.
Some of the things I learned:
- Incremental improvement works, even under high pressure
- Key problems are typically cross functional. The better you are in building a cross functional momentum – the faster you’ll overcome them
- Kanban works as a tool for incremental improvement
- Quality over speed – always more important than the tool
(… and I have a far way to go until I can order a proper cup of tea and a croissant 🙂
Anyway, here’s the link:
Great article. I learned a lot of it. Basicly because we are facing some problems also, mostly with the involvement of other teams.
At the end of your case study you told about the HR girl. Well I work in a HR company and we have implemented Kanban also in non IT related teams, like Cunsulting, … We even used Kanban at our New Years party were 36 people had to coock for 1600 people. And they used Kanban to get everything smooth. It was great.
I think this is a great success story for Kanban. And I’m really delighted to see that you started by introducing TDD.
However, I also feel like the title is misleading because this really was not Scrum team when you started — they were merely pretending to be a Scrum team.
This was evident in your own description:
These are strong indications that the team was not really doing Scrum (no matter what they thought they were doing).
Well I am open to suggestions regarding better name for the title 🙂
But, I think the title question highlights another problem. We carry different views of how to apply Scrum “right” based our context experience.
An open definition is both a strength, and a weakness. The trade-off being: If we would narrow the definition more firmly (say insisting that any scrum implementation has a definition of done = in production with no increase in technical debt – we’d also would narrow the community of the people learning to do software in a better way.