From my own experience these days a lot of companies in UK associate Agile with Kanban practices a lot. Lets try to think though it. Agile methodologies emerged in attempt to manage uncertainty in a (not only software) project lifecycle. The essence of Agile Methodology is described by Deming Cycle:
This process applies to projects, teams, iterations and pretty much every bit of interaction we have with a system called a software project. Any Agile ceremony should be tailored to add some value to one of the bullet points from the list above. Now, Scrum and Kanban are the Swiss army knives under the umbrella of Agile Methodologies. Both provide a toolset if you know how to use those properly. However, it depends heavily on a project and a Team which tool would fit better. In my understanding Scrum is optimizing the process for transparency and predictability when Kanban is optimized for bandwidth and resolving bottlenecks.
Scrum
Kanban
However, I don't think we need to prioritize one over another. Scrum suits perfectly fine when you're developing in a goal-centric environment. Kanban suits you much better when you're working in a one-by-one task environment (operations mode) and there's no clear end-goal. Just improvements along the assembly line.
- Plan
- Do
- Check
- Act
- Repeat
This process applies to projects, teams, iterations and pretty much every bit of interaction we have with a system called a software project. Any Agile ceremony should be tailored to add some value to one of the bullet points from the list above. Now, Scrum and Kanban are the Swiss army knives under the umbrella of Agile Methodologies. Both provide a toolset if you know how to use those properly. However, it depends heavily on a project and a Team which tool would fit better. In my understanding Scrum is optimizing the process for transparency and predictability when Kanban is optimized for bandwidth and resolving bottlenecks.
Scrum
- push culture (nurtures management)
- promotes transparency which imparts teams commitment
- pushing hard for predictability and constant improvement over iterations
- fits younger teams (less established) and provides sufficient guidance to avoid common pitfalls
- fits greenfield projects more when the amount of work is well defined and there's plenty of it
Kanban
- pull culture (nurtures leadership)
- from my experience after pushing for some time and without being reminded of the uber goal people relax a bit. So we need some way of measuring where we're at with respect to the project as a whole
- operates from a prospective that the system's cost is as high as the cost of the slowest chain
- fits well established projects with senior teams more
- fits maintenance with non well-defined backlog when there're spikes of work
However, I don't think we need to prioritize one over another. Scrum suits perfectly fine when you're developing in a goal-centric environment. Kanban suits you much better when you're working in a one-by-one task environment (operations mode) and there's no clear end-goal. Just improvements along the assembly line.
No comments:
Post a Comment