For those of you who wonder "why would anybody convert a Scrum team to Kanban" (see earlier blog) – it is important that you understand the true intent. (..yes there is one! 🙂 What expected output do you have from a process framework?
This important "why" question is often left out in the debate. The heated "Scrum vs Kanban" discussion is a good example. Try yourself "why are you using Scrum"? (or Kanban). At what point would you throw the tool out for not delivering?
It is no wonder debates turns heated if we disagree on where we are heading. But if we instead start with clarifying intent ("why") – then the actual choice of tools becomes less important (more like a boring context summary 🙂
Why then? How do you know that the process tool works for you?
- First (obvious) – it helps you deliver running software.
- Second (less obvious) – it makes you do continuous improvement effectively
If you are getting results from continuous improvement – your tool is right. If it is not happening, it is probably wrong. (check yourself, what improvements have you benefited from lately?)
This was the main reason I chose to implement Kanban in the Scrum teams. It was not because the sprints where not delivering, it was because the improvements didn’t happen.
