Too fast for Scrum? | AgilePT 2015
Too fast for Scrum? | AgilePT 2015 http://linkedin.arraiscastro.com http://talks.arraiscastro.com Scrum adoption comes with relevant organizational challenges that some companies manage poorly. First, there is the misconception that scrum, by itself, makes your teams faster. While contributing to quality, scrum can make your teams more productive, but a poorly designed agile process may turn your teams slower at the end. Second, there is the misconception that the need to move hyper fast makes your backlog so organically alive that timeboxed sprints become impossible to achieve. We see a lot of companies moving to Kanban, as the epiphany of extreme agility. Sometimes, all they want is to avoid the huge challenges associated with organizing the work flows so that a stable development time window is provided to their teams. Priorities changing all the time, new stories popping up each day, the will to change anything, anytime, with the excuse that it is required by the customers, and lack of senior management commitment are typical drugs used to kill sprints and agile ceremonies. Agility is not a process, it is a mindset, based on a culture, focused on delivering the most value as soon as possible. Taking scrum (or kanban) as a structured recipe for success and applying it as if we were making a delicious cake may, at the end, cause some stomach pains (and even food poisoning on extreme cases)!
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Too fast for Scrum? | AgilePT 2015
Similar to Too fast for Scrum? | AgilePT 2015 (20)
Recently uploaded
Recently uploaded (20)
Too fast for Scrum? | AgilePT 2015
- 1. too fast for Scrum? Antonio Arrais de Castro
- 2. about.me cto@ by Antonio Arrais de Castro https://www.linkedin.com/in/arraisdecastro
- 3. going sustainably fast =>
- 5. clear goals
- 10. even with all that…. may you get too fast for Scrum?
- 11. “too fast” symptoms… “It is a struggle to keep the sprint backlog stable during each sprint.” “Priorities change daily… sometimes hourly…” “Aren’t we spending too much time planning?” “It looks we are being productive but not too effective…” “We can’t support our maintenance efforts with timeboxed sprints.” “Multitasking is increasing, we have devs working on too many small tasks at a time.” “Some people talk about the cone of uncertainty. Our looks like a rectangle…”
- 12. “too fast” symptoms… When “move fast” under uncertainty becomes the mission statement, you start to see teams feeling that Scrum starts to block their agility. Sprint backlog changes should be avoided in scrum, as a principle. But building a stable environment for your team during the sprint duration should not be an impossible mission….
- 14. “Scrum, by itself, makes your teams faster”
- 15. “Scrum, by itself, makes your teams faster” A poorly designed agile process may turn your teams slower at the end!
- 16. “the need to move hyper fast makes your backlog so organically alive that timeboxed sprints become impossible to achieve”
- 17. “the need to move hyper fast makes your backlog so organically alive that timeboxed sprints become impossible to achieve” Challenging… hell yes… but not impossible!
- 18. “Scrum and Kanban are recipes for success”
- 19. “Scrum and Kanban are recipes for success” There is not such thing! Scrum and Kanban are helpers, not recipes.
- 20. “The agile methodology is great”
- 21. “The agile methodology is great” There is no such thing as an “agile methodology”. Scrum may be considered an agile based framework. Remember, no recipes available!
- 22. “Scrum is based on the assumption that teams are good at estimating”
- 23. “Scrum is based on the assumption that teams are good at estimating” Most of the team members are lousy estimators. But they can improve continuously. Scrum assumes that it is not possible to work with precise time based estimations and promotes using intervals instead.
- 24. “Sprints are incompatible with having maintenance work”
- 25. “Sprints are incompatible with having maintenance work” Yes, it is tricky! But you need to find your optimal strategy to deal with it. And it is not impossible.
- 27. jumia.team 288 jumia IT 91 Porto Tech center 4 Porto Tech companies jumia (all) 2500 ALGERIA SENEGAL ANGOLA CAMEROON IVORY COAST EGYPT BANGLADESH MYANMAR PAKISTAN GHANA KENYA MOROCCO NIGERIA UGANDA TANZANIA …
- 28. porto.tech.center Scrum Kanban 4 now Each time decides Scrum Scrum+Kanban Each team decides 2 weeks N.A. 2 weeks 2 weeks N.A. Distributed maintenance Maintenance team Each team handles own issues Distributed maintenance Each team decides 9 teams 5 teams 3 teams 3 teams 6 teams
- 29. our road to awesomeness RadicalCode Fix Scrum Scrum + Kanban Kanban Scrumban Scrum Man, we’re driving fast!
- 30. road to awesomeness RadicalCode Fix Scrum Scrum + Kanban Kanban Scrumban Scrum Deeper team involvement. Great!
- 31. road to awesomeness RadicalCode Fix Scrum Scrum + Kanban Kanban Scrumban Scrum Maintenance vs. feature development focus.
- 32. road to awesomeness RadicalCode Fix Scrum Scrum + Kanban Kanban Scrumban Scrum Reacting faster, prios are queen.
- 33. road to awesomeness RadicalCode Fix Scrum Scrum + Kanban Kanban Scrumban Scrum Humm… there was a strange factory feeling around.
- 34. road to awesomeness RadicalCode Fix Scrum Scrum + Kanban Kanban Scrumban Scrum Balancing fast reaction to changes, product commitment and stability.
- 36. is this our recipe?
- 40. thanks