1 / 22

Scrum sucks! Kanban Rules!

Scrum sucks! Kanban Rules!. Mark Gibaud #londonagile. Kanban basic concepts. “Kanban” = Visual Card Developed by Taiichi Ohno in the TPS. Kanban in the real world. Starbucks. Why care about kanban?. Improved quality of features Faster turnaround of features

gudrun
Télécharger la présentation

Scrum sucks! Kanban Rules!

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Scrum sucks! Kanban Rules! • Mark Gibaud • #londonagile

  2. Kanban basic concepts • “Kanban” = Visual Card • Developed by Taiichi Ohno in the TPS

  3. Kanban in the real world • Starbucks

  4. Why care about kanban? • Improved quality of features • Faster turnaround of features • Reduces waste (context switching, delays, etc)

  5. 2 Basic Rules • Visualize your work • Limit your work-in-progress - encourages flow

  6. Little’s Law • Little’s Law (queuing theory): • L = λW. • Length of a queue = arrival rate * average wait time • OR Wait time = length of queue / arrival rate • OR Cycle time = WIP / Throughput

  7. Capacity utilization

  8. Example Kanban Board [REDACTED]

  9. Engineering practices • Branch-by-feature • Subversion vs DVCS • Continuous Deployment / DevOps / Frequent Releases • One-click deploy

  10. Scrum metrics • Points - nobody outside dev understands • Velocity - unwieldy and subject to ambiguous fluctuation • Project-level estimation mechanism?

  11. Kanban metrics • Cycle time • Duration an item of work gets through the system • Throughput • How many items get done in x weeks

  12. Scenario 1: Scrum • Developer raises that feature will not be done by Friday, but by Monday • Pressure to get it done => loss of quality • Pressure to delay release => difficult conversations • Pressure not to disappoint customers

  13. Scenario 1: Kanban • Developer raises that feature will not be done by Friday, but by Monday • Fine, I’ll let customers know it’ll be released Monday and not Friday • No quality loss, developer pressure, customer hate

  14. Scenario 2: Scrum • ‘Critical’ bug reported after a release • Argument: Is it REALLY critical? • Patching: ceremony!! • Reputational loss with patching • Interrupts ‘normal’ workflow • If normal bug, gets prioritized against all other backlog items, loses, stays in the product.

  15. Scenario 2: Kanban • ‘Critical’ bug reported after a release • Fix it. Ship it. Usually in less than a day. • Who cares how critical it is? • Who cares what opportunity cost there is? • Doesn’t interrupt ‘normal’ workflow • Customers impressed by response time?

  16. Advantages of Kanban • Simple, understandable metrics • Scales • Non-intrusive, evolutionary • Focus on quality, not deadlines • Metrics that a PMO (and customer) understands • Includes all functions

  17. Kanban scales

  18. Kanban PMO [REDACTED]

  19. Disadvantages • Counter-intuitive practices/foundations? eg. Little’s Law • Fully enabled only by advanced engineering practices • Doesn’t encourage collaboration as well as Scrum • Rely on maturity of team for collaboration

  20. More information • @markgibaud • Google! • VersionOne Whitepaper • NetObjectives Whitepaper • “Demystifying Kanban”

  21. Consider this • A lot of the people using Kanban today, were the people using Scrum 5/10 years ago • Dan North: “Scrum is training wheels” • Songkick, 7Digital

  22. Questions?

More Related