3 Common Scrum team Failure Modes
•
4 likes•578 views
Slide deck for talk given at Agile Tour 2016
Recommended
More Related Content
Similar to 3 Common Scrum team Failure Modes
Similar to 3 Common Scrum team Failure Modes (20)
Recently uploaded
Recently uploaded (20)
3 Common Scrum team Failure Modes
- 1. 3 COMMON SCRUM FAILURE MODES AND (HOPEFULLY) SOME SOLUTIONS Chris Walsh Dell IT
- 3. CAREFUL NOW… “I Tried These 3 Simple Tricks With My Scrum Team And You Wont Believe What Happened Next…”
- 4. CAREFUL NOW…
- 5. Team Structure Roles Team stability Cross-functionality Self-direction Backlog Management Value Streams Priorities Estimation Schedule Sprint Execution Planning Sprint Flow Product Increment Metrics Development Practices Code Management Test Approach Programming DevOps WHERE TO LOOK…
- 6. THE PRODUCT BACKLOG Fail #1
- 7. TYPICAL SPRINT Sprint Plan 1 Sprint Plan 2 1 2 3 4 5 6 7 8 9 10 Day (2 Week Sprint) Hours Team Retro Sprint Review Product Increment
- 8. SYMPTOMS – PLANNING Sprint Plan 1 Sprint Plan 2 1 2 3 4 5 6 7 8 9 10 Day (2 Week Sprint) Hours Sprint Goal “ ” Sprint Backlog Task list (2-3 days) Team Retro Sprint Review
- 9. SYMPTOMS - SPRINTING Sprint Plan 1 Sprint Plan 2 1 2 3 4 5 6 7 8 9 10 Day (2 Week Sprint) Hours Scrum Board To Do Doing Done Team Retro Sprint Review Burndown
- 10. SYMPTOMS - REVIEWING Sprint Plan 1 Sprint Plan 2 1 2 3 4 5 6 7 8 9 10 Day (2 Week Sprint) Hours Team Retro Sprint Review Product Increment ?
- 11. (POSSIBLE) CAUSES & (POTENTIAL) FIXES
- 12. PRODUCT OWNER? TRY STORY MAPPING WITH THE WHOLE TEAM. FOCUS ON THE WHAT NOT THE HOW.
- 13. DEV TEAM SKILLS Huh? I got nothin’. Ummm.. Just keep smiling… Too busy coding.
- 14. DEV TEAM SKILLS Huh? I got nothin’. Ummm.. Just keep smiling… WORK ON SPECIFIC BACKLOG REFINEMENT SKILLS. ASK QUESTIONS! Too busy coding. TRY STORY MAPPING WITH THE WHOLE TEAM!
- 15. DEV TEAM SKILLS Huh? I got nothin’. Ummm.. Just keep smiling… WORK ON SPECIFIC BACKLOG REFINEMENT SKILLS. ASK QUESTIONS! Too busy coding. TRY STORY MAPPING WITH THE WHOLE TEAM! YOU ARE HERE
- 16. NO PRODUCT VISION? FIND THE PRODUCT VISION. (IT PROBABLY EXISTS SOMEWHERE).
- 17. THE TEAM Fail #2
- 18. SYMPTOMS – SPRINT PLANNING Sprint Plan 1 Sprint Plan 2 1 2 3 4 5 6 7 8 9 10 Day (2 Week Sprint) Hours ? ?
- 19. SYMPTOMS – DAILY SCRUM Sprint Plan 1 Sprint Plan 2 1 2 3 4 5 6 7 8 9 10 Day (2 Week Sprint) Hours ? Which daily Scrum is this? Where’s Bob?What exactly did I do yesterday? So tired. So very tired.
- 20. SYMPTOMS – SPRINT REVIEW Sprint Plan 1 Sprint Plan 2 1 2 3 4 5 6 7 8 9 10 Day (2 Week Sprint) Hours Where’s My £%&*ing Product Increment? Sprint Review Product Increment ?
- 21. SYMPTOMS – CODE BASE SS1 SS3 SS2 Org. Dev Org 1 Dev Org 2 Dev Org 3 System to be developed Organisation contracted to develop the system
- 22. (POSSIBLE) CAUSES & (POTENTIAL) FIXES
- 23. UTILIZATION FIXATION MEASURE QUEUEING TIME OF A FEATURE THROUGH IT’s DEV CYCLE.
- 24. INTERNAL SILOS
- 25. INTERNAL SILOS CALCULATE THE TEAM’s “BUS NUMBER” AND CREATE A PLAN TO INCREASE IT.
- 26. “GETTING TO DONE” Fail #3
- 27. SYMPTOMS – SPRINT REVIEW Sprint Plan 1 Sprint Plan 2 1 2 3 4 5 6 7 8 9 10 Day (2 Week Sprint) Hours Where’s My £%&*ing Product Increment? Product Increment ? Sprint Review
- 28. SYMPTOMS – DAILY SCRUM Sprint Plan 1 Sprint Plan 2 1 2 3 4 5 6 7 8 9 10 Day (2 Week Sprint) Hours Scrum Board To Do Doing Done
- 29. SYMPTOMS - “MINI-WATERFALL” Sprint 1 Sprint 2 Sprint 3 Sprint 4 Code S2 + Bug Fix S1 Code S3 + Bug Fix S2Code S1 Code S4 + Bug Fix S3 Test S3 + Retest Test S4 + Retest Test S2 + Retest Test S1 Time Defects Expected Defect Profile
- 30. SYMPTOMS - “SPRINT+1” Sprint 1 Sprint 2 Sprint 3 Sprint 4 Code S2 Code S3 + Bug Fix S1Code S1 Code S4 + Bug Fix S4 Test S3 + RetestTest S2 + RetestTest S1 Time Defects Expected Defect Profile
- 31. (POSSIBLE) CAUSES & (POTENTIAL) FIXES
- 34. CLEAR DEFINITION OF DONE DO NO MORE THAN ONE THING AT A TIME.
- 35. CLEAR DEFINITION OF DONE DO NO MORE THAN ONE THING AT A TIME.
- 36. LOOK FOR THE SYMPTOMS CREATE OPTIONS USE THE SCRUM EVENTS. COMMITMENT, FOCUS, OPENNESS, RESPECT & COURAGE.
- 38. THANK YOU!
Editor's Notes
- Bad title!
- This is not one of those clickbait “3 simple things that will make you an awesome Scrum Master”
- surveys and industry reports tells us that Agile is basically mainstream now. However, in my experience a *lot* of teams & organizations have simply appropriated the language & terminology of agile and have not fundamentally changed their behaviour So I get asked to help teams on a fairly regular basis. Sometimes it’s new teams starting out, but predominantly teams that have been operating for sometime and have not really realised any benefits in terms of productivity. They have their product backlog, the roles are filled, they’re doing all the scrum events, but it just doesn’t feel like they’re making progress. Very often they can’t put their finger on what is going wrong.
- 4 main areas of inspection (for me) when working with teams.
- In my experience, the failure to produce a well-groomed, prioritized product backlog is at the root of nearly every problem on a Scrum team. If the team can’t understand what they are supposed to build, they typically don’t get anything finished, and nothing at the end of the sprint works. It can effect every aspect of the teams sprint. ***Scrum Guide Tells us…
- Let’s take a look at a typical, if rather “vanilla”-looking sprint.
- So, if there are issues with the product backlog, the first half of the Sprint Planning Meeting (the “What”) takes way longer and is way more painful than it should be. Forming a Sprint Goal, that is cohesive and meaningful is practically impossible (a high “AND” count). The second half (the “how”) is a cycle of referring back to the what You get a lot of “technical” backlogs created by developers, sometimes on the fly, to fill space.
- What else? * The Daily Scrum. – Listen here for impediments directly related to unknowns in the Sprint Backlog. * Look at the scrum board – a lot of items in progress? Parked, awaiting clarification from the PO? * Look at the burndown – bump due to items and tasks added after sprint planning?
- Ok, what else? The Sprint Review: If the team can’t understand what they are supposed to build, how do they get anything finished. Is there very few “done” items ready for review? Perhaps no *Product increment at all? Items rolling over etc. The Retrospective: Listen for some common themes here. Challenges in planning & sprinting, waiting for clarification. Product backlog problems? Complaining about the PO, perhaps?
- CAUSES!
- CAUSES! Product owner is not [doing stuff], or *** does not exist. Product owner is not empowered by the organization to make decisions and trade-offs Product owner is a committee. Product owner finds it difficult to talk in terms of business outcomes and presents a (non-negotiable) solution to the team to be “implemented”. *** Solving this is about figuring out who in the organization has the knowledge and skills to break down the work, make tradeoffs, and help the team develop a shared understanding of the product. Work with the PO on backlog management techniques, how to prioritize, how to estimate, how to write a good story…
- CAUSES!!! A well ordered product backlog is not just the job of the PO. *Sometimes the development team is lacking in specific domain knowledge or technical skills to contribute to backlog refinement. ** Sometimes the team doesn’t know what’s expected of them during backlog refinement. If you hear: “I assume from your silence that you understand this”…
- Set aside time to work on technical & domain skills during the sprint Work specifically on backlog refinement techniques. Review backlog-related impediments in the retrospective and work with your team to figure out what we can do differently in future to prevent them.
- Storymap for this talk.
- You can’t iterate your way to a product vision. You are being set up to fail as a team if you are trying to work without one. This is not the fault of a specific methodology or process. It’s just bad leadership.
- This is another huge problem for organizations trying to implement Scrum. Typically, the larger the organization, the more difficult it is to solve this problem. So, let’s assume the Product Backlog issue has been solved… I work with so many teams where I find that people are matrixed across multiple teams & projects, each with their own priorities. So you get Teams with external dependencies that need to be resolved in order for them to produc a working increment. ***What does the Scrum Guide say?
- what does sprint planning look like? You are trying to understand the story without everyone in the room? breaking down the work without everyone necessary to solve the problem? trying to commit to a sprint when you don’t have all the external dependencies worked out and there is no shared ownership? How do you estimate in the face of all this uncertainty. You can’t get to done no matter how hard you try.
- Daily Scrum. Is everyone there? Are they listening? Developer accidently updated the team about another project he was working on. And nobody noticed!
- If the team is hampered by external dependencies it’s going to be very difficult for them to successfully deliver on their sprint goal. The PO is unlikely to be interested in excuses of team
- Melvin Conway. “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” — M. Conway Alt version “Each organization contains one person who know what’s going on. That person must be fired.”
- CAUSES!
- Many organizations, very often unbeknownst to themselves, want us to be like the guys on the left. At 100% capacity, Busyness over business.! There is often an obsession with “utilization” and no focus at all on “effectiveness”. And how do you maximize utilization? (Oracle dev 5 teams x 20%). End up with 5 project teams with an external dependency that completely hamstrings their ability to deliver value in a timely manner. **MEASURE IT! Track a feature through it’s development cycle and calculate how much time it spends sitting in queues. How much waste is in your system. Work with the team to reduce that cycle time by removing queues where you find them.
- Internally siloed teams are different animals to teams with external dependencies and need a different approach to solve them. While technically “cross-functional” their ability to be truly productive is very limited. ** Identify – make them explicit ** Bus number/Truck number/Lottery number (pessimist v optimist) ** Pair development is a great place to start
- Internally siloed teams are different animals to teams with external dependencies and need a different approach to solve them. While technically “cross-functional” their ability to be truly productive is very limited. ** Identify – make them explicit ** Bus number/Truck number/Lottery number (pessimist v optimist) ** Pair development is a great place to start
- I’m leaving this til the end, because if you resolve the first two problems, it’s much easier to work out the third. This is much more about development practices and team dynamics.
- Obviously, if the team is failing to build an increment of “Done” product, it’s going to be a difficult Sprint Review
- So before the sprint review, it should be possible to see it coming. At the daily Scrum is it obvious that everyone is focussed on their own thing? Developer locally optimise their work instead of trying to optimise the system. At the end of the sprint, it is better to have 80% of the work 100% done than 100% of the work 80% done.
- This leads to hardening sprints!
- This leads to hardening sprints and Release Sprints!
- CAUSES!
- The Real purpose of Scrum is not understood by the organization. Scrum is perceived as a sausage machine for maximizing the amount of stuff that can be churned out of it. Or it’s a hyper-transparent opportunity to micromanage your development teams (a very common complaint from suffering developers) Ken Collier describes scrum teams like this becoming like birds in a nest, beaks open screaming more stories, more stories!!
- Jeff Patton’s (the author of the storymapping book) tweet from last week.
- What can the team do (in the face of all this organizational adversity) CI – Deliver small amounts, frequently BDD, SPE, ATDD, whatever, let the tests drive the development. DoD – Make it clear when you’re Done done Get better at estimating. Not because estimates are important (because I don’t believe they are), but to get everyone on the same page of what is to be built. My preferred method is the one described by steve Bockman in Practical Estimation (99p on kindle from Amazon). Not pokerplanning. 1 thing at a time: Suggest Mob Programming.
- Mob Development/Whole Team Development Data-Viz team in Dell IT, Cork, in action. (Still EMC at time pic taken!) Check out Woody Zuill’s work for more info.
- Give yourself options, treat them as hypothesis and design experiments to validate them