Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to fail at scrum

58 views

Published on

Shippio's product team experience with implementing scrum over 6 months and attempts to overcome encountered problems

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

How to fail at scrum

  1. 1. How to fail at SCRUM ...and hopefully learn from it
  2. 2. Nothing - Benefits 1. No overhead 2. Everybody is talking to each other
  3. 3. Nothing - Drawbacks 1. Constant discussion is overhead 2. Nobody knows what is going on
  4. 4. We need a backlog!
  5. 5. Issue
  6. 6. Backlog - Benefits 1. Don’t need to ask PO to know what to do 2. We can see who is working on what
  7. 7. How to recognize a bad backlog? 1. A list of EVERYTHING we THINK we need 2. It’s HUGE 3. Everything has the same priority => “ASAP”
  8. 8. Backlog - Consequences 1. “The Scrum Backlog is where Features go to die” 2. We don’t know the progress 3. It never ends 4. Product piles on random features
  9. 9. We need milestones!
  10. 10. Issue Milestone
  11. 11. Milestones - Benefits 1. Set of multiple features decided at once 2. Motivation to finish 3. Achievement feeling
  12. 12. 1. Bad backlog with an arbitrary deadline: “Finish BETA” 2. Always changes How to recognize a bad milestone?
  13. 13. Consequences 1. Stressful 2. Deadline never respected
  14. 14. We need sprints!
  15. 15. Issue Milestone Sprint
  16. 16. Sprint - Benefits 1. Gives a goal for a shorter period of time 2. Have people plan and debrief on a regular basis
  17. 17. How to recognize a bad sprint? 1. Arbitrary commitment 2. No clear objectif 3. No debrief
  18. 18. Sprint - Consequences 1. Committed tasks not achieved or poorly in a rush 2. No lessons learnt
  19. 19. We need epics!
  20. 20. Issue Milestone Sprint Epic
  21. 21. Epics - Benefits 1. Focused: 1 epic = 1 feature 2. Faster to deliver 3. PO dictates less technical implementation
  22. 22. 1. 1 epic ≠ 1 feature: e.g. “Make website” 2. No specification: “Implement billing” => How? How to recognize a bad epic?
  23. 23. Consequences 1. Features are improvised 2. Back and forth during the implementation: dev ⇔ PO ⇔ customer 3. Lots of refactoring
  24. 24. We need triage!
  25. 25. Triage - Benefits 1. Break down into smaller epics 2. Time to research before implementation
  26. 26. 1. Sorting of epics for the “day after” 2. Focus on implementation detail instead of planning for future sprints How to recognize a bad triage?
  27. 27. Triage - Consequences 1. Redundant with sprint planning 2. Features keep being designed during implementation
  28. 28. We need design sprint!
  29. 29. Design sprint - Benefits 1. Take a step back and catch up on planning 2. Team building: dev, design and PO work together 3. Brainstorming is fun!
  30. 30. Not sure yet, we just started this week! How to recognize a bad sprint design?
  31. 31. Thank you!
  32. 32. Questions?
  33. 33. We are recruiting!

×