Agenda SCRUMBAN: Yet Another Agile Methodology? SCRUM vs Kanban Conclusion Q&A
SCRUMBAN: Yet Another Agile Methodology ? SCRUM works fine ! • Client is happy • Team is happy => we are happy ! BUT • We reached the support phase in our project … • Our teams work on different (client) projects with unpredictable resource planning … • we still like SCRUM (principles)…
Yet Another Agile Methodology ? Solution : let’s switch to Kanban ! • Works perfectly with ad hoc issues • Let’s us bent more rules BUT • We still like the daily SCRUM meeting … • We made a lot of effort on creating the current team roles …
Yet Another Agile Methodology ?
Yet Another Agile Methodology ? Solution: let’s make a best of breed combination: SCRUMBAN
Yet Another Agile Methodology ? SCRUMBAN
SCRUM vs Kanban A perfect marriage ? Tailor the combination to your team / project needs
SCRUM vs Kanban Both are Lean and Agile Both use pull scheduling Both limit WIP Both use transparency to drive process improvement.
SCRUM vs Kanban Both focus on delivering releasable software early and often. Both are based on self-organizing teams. Both require breaking the work into pieces. In both, the release plan is continuously optimized based on empirical data (velocity / lead time).
SCRUM vs Kanban SCRUM KanbanTimeboxed iterations Prescribed OptionalTeam commitment Sprint backlog OptionalDefault metric Velocity Lead timeCross functional teams Prescribed Optional Specialist teams allowedItem size Completed within 1 sprint No size prescribedFollow up diagram Burndown chart No prescibed (CFD)WIP limited Indirectly (per sprint) Directly (per WF state)Estimation Prescribed OptionalAdding new items Not allowed Whenever capacity is available
SCRUM vs Kanban SCRUM KanbanTeam ownership Sprint backlog Board shared by teamsRoles Prescribed (SM, PO, Team) OptionalBoard reset After each sprint PersistentPrioritization Prescribes prioritized Optional product backlog
Conclusion SCRUMBAN – Makes SCRUM principles applicable for support projects – Can be fully tailored to team / project needs – Might become less transparent (focus on flow / sprint) – Tools might not support all required features
One final thought … A hammer doesn’t build a house, the person swinging the hammer does. It’s all in how you use the methodologies available.