Agile Sprint Anti-Patterns Webinar #7 Common Mistakes & Solutions
•Download as PPTX, PDF•
1 like•1,580 views
This document announces an upcoming webinar on October 2nd about Sprint Anti-Patterns, which will identify 12 issues that can arise related to the Product Owner, Development Team, Scrum Master, and other stakeholders. It also provides contact information for the webinar host and information about signing up for his newsletter and joining related Slack and Twitter communities.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Agile Sprint Anti-Patterns Webinar #7 Common Mistakes & Solutions
Similar to Agile Sprint Anti-Patterns Webinar #7 Common Mistakes & Solutions (20)
More from Stefan Wolpers
More from Stefan Wolpers (20)
Recently uploaded
Recently uploaded (20)
Agile Sprint Anti-Patterns Webinar #7 Common Mistakes & Solutions
- 1. Hands-on AgileWebinar #7 Sprint Anti-Patterns October 2nd, 2018, at 6 pm CEST (12 pm EDT or 9 am PDT)
- 2. The Scrum Sprint stefan@age-of-product.com
- 4. stefan@age-of-product.com#1: The Absent Product Owner
- 5. #2: The Interfering Product Owner stefan@age-of-product.com
- 8. #4: Board Out-of-Date stefan@age-of-product.com
- 13. #7: No Sprint Goal stefan@age-of-product.com
- 15. #9: Variable Sprint Lengths stefan@age-of-product.com
- 17. #11: Everything Is a Bug stefan@age-of-product.com
- 18. #12: All Hands to the Pumps stefan@age-of-product.com
- 19. Summary: Scrum Sprint Anti-Patterns stefan@age-of-product.com
- 20. Hands-on AgileWebinar #8 Scrum Master Anti-Patterns October 16th, 2018, at 6 pm CEST (12 pm EDT or 9 am PDT)
- 21. The Age of Product Youtube Channel
- 22. Contact Information StefanWolpers Email: stefan@age-of-product.com Blog: Age-of-Product.com Newsletter: https://age-of-product.com/subscribe (Join 19,000-plus peers) Slack: https://hands-onagile.slack.com/ (Join 4,000 peers) Twitter 1: @StefanW Twitter 2: @AgeOfProduct
- 23. About Stefan Wolpers Agile Coach, Scrum Master, and Product Owner since 2006: stefan@age-of-product.com
Editor's Notes
- Welcome 7th Hands-on Agile Webinar I am your host Stefan Wolpers Housekeeping
- We are moving forward! We already covered the sprint planning in webinar #5 — which is available on the Youtube channel Today, we will talk about the sprint itself — what could possibly wrong? Let’s start w/ short refresher from the Scrum Guide: Purpose: Deliver a potentially releasable product increment • Time-box of less than a month (=> Complexity & risk get higher, purpose of the product might change) • but more than 1 week (=> overhead) • No changes are made to the sprint backlog that would endanger the Sprint Goal; • Scope may be clarified and re-negotiated between the PO and Development Team as more is learned. • Quality goals do not decrease – no cutting corners whatsoever: runs on my machine, demo version
- My dirty dozen Sprint anti-patterns: Let us start with Product Owner…
- No feedback to developers during the sprint => increased risk of not meeting the sprint goal The best product backlog refinement shall not answer all questions in advance — that would be way to granular! It is all about real-time collaboration between PO and the developer team Delay in accepting tasks creates an artificial queue (=> nasty if QA is not yet largely automated) NOTE: “potentially shippable product increment at the end of a sprint” does not mean ≠ one deployment per sprint
- You can change the sprint backlog — if the development teams agrees (=> adapt to change over following a plan.) However, no changes by the PO single-handedly, e.g. scope (=> sprint cancellation is the exception) Be pragmatic! Sometimes: – the scope needs to be reduced (for example, capacity is reduced amid unexpected sick leave, a critical bug requires immediate attention) – more refactoring needs to be accomplished prior to delivering a story – there is room for more
- Gold-plating: The team increases the scope of the sprint by adding unnecessary work to sprint backlog items: scope-stretching or gold-plating. the team enlarges the task without prior consulting of the product owner. This ignorance may result in a questionable allocation of resources (Example: OpenID, switch between different OpenID providers — completely useless.) the developers and the product owner need to talk more often with each other. PO not yet co-located with the development team? now would be a good moment to reconsider.
- Board out-of-date: The team does not update tickets on the board in time to reflect the current status. no matter if it is a physical or digital board, it is vital for coordinating a team’s work. Transparency is key to inspection and adaptation (Daily Scrum: who needs help?) It is also an integral part of the communication of the scrum team with its stakeholders. A board that is not up-to-date will impact the trust the stakeholders have in the scrum team: “How shall they deliver software, if they already fail at moving a few stickies?” Deteriorating trust may then cause counter-measures on the side of the stakeholders. The (management) pendulum may swing back toward traditional methods as a consequence. The road from Scrum to PRINCE II is paved with abandoned boards.
- Flow disruption: The scrum master allows stakeholders to disrupt the flow of the development team during the sprint. For example: The SM has a laissez-faire policy as far as access to the development team is concerned. The SM does not object that the management invites engineers to random meetings as subject matter experts. The scrum master allows that either stakeholders or managers turn the daily scrum into a reporting session. Preserving the flow of work through the team during the sprint is the lynchpin of productivity: That’s why WIP limits are useful (=> thus avoid creating artificial queues, for example, concerning code review) That’s why the reason why the PO needs to be available at all times Be cautious: If the Scrum team fails, no stakeholder will read this kind of “what happened during the sprint” fine-print afterward. All they see is “not delivered.”
- All Scrum events are essential for a team’s success — you cannot skip an event. Junior Scrum teams may be tempted to skip Retrospectives to buy some more time to meet the sprint goal. A Scrum Master accepting this “deal” is a scrum master by title only. Actually, the proposal is already a sign how urgent the team needs a retrospective.
- According to the Scrum guide: • Scope may be clarified and re-negotiated between the PO and Development Team as more is learned. More Less: Over-optimism Sprint goal can probably be reached with less Note: Dev team has veto right Other reasons: Tech is not working as expected Technical debt Capacity changes
- Hardening sprint: The scrum team decides to have a hardening or clean-up sprint. That is a simple one: there is no such thing as a hardening sprint in scrum. Let’s revisit the Scrum Guide: Quality goals do not decrease – no cutting corner whatsoever such as runs on my machine, demo version. Hardening sprints are commonly a sign of a low grade of adoption of agile principles by the team or the organization. Team is not yet cross-functional? Is QA still a functional, non-agile silo? Suggesting a hardening sprint thus violates a core principle of Scrum: adherence to the Definition of Done. Worst variation: the PO believes the DoD is matched and the product increment is releasable — that reduces transparency, thus increasing the risk (=> Huge costs at a later stage)
- Variable sprint length: The scrum team extends the sprint length by a few days to meet the sprint goal. This is just another way of cooking the agile books. Remember: the goal is delivering working software that delights the customers. Stop lying to yourself, and address the underlying issues — why didn’t the sprint’s outcome meet the sprint goal? — during the next retrospective Note: I would not consider a deviating sprint length during the holiday season at the end of the year to be an anti-pattern.
- Special forces: A manager assigns specific tasks directly to engineers, thus bypassing the product owner. Alternatively, the manager removes an engineer from a team to work on such a task. This behavior does not only violate core Scrum principles. It also indicates that the manager cannot let go command and control practices. He or she continues to micromanage subordinates although a scrum team could accomplish the task in a self-organized manner. This behavior demonstrates a level of ignorance that may require support from a higher management level to deal with.
- Everything’s a bug: Stakeholder try to speed up delivery of their issues by relabeling tasks as ‘serious bugs’ : First of all — nice try —; nevertheless the SM shall address the stakeholder and coach her on “useful interaction with the Scrum team” Reasons: Local optimization attempt? Personal agenda? (Bonus at risk?) “Agile does not apply to me”-attitude? A special case is the “express lane” for bug fixes and other urgent issues. Every stakeholder will try and make his or her tasks eligible for that express lane. As Joko Willink likes to say: leadership is not what you preach, but what you let slip through. (=> SM) And while you’re at it: Watch also out for stakeholders trying to sneak in small tasks by pitching them directly to developers.
- The management temporarily abandons scrum in a critical situation. This is a classic manifestation of disbelief in agile practices, fed by command & control thinking. Fine weather sailing so to speak. Most likely, canceling the sprint and starting a new sprint addressing the issue at hand would also solve it.
- Let’s summarize the dirty dozen of sprint anti-patterns.
- Some background on myself: I have spent 12-plus years in agile Mostly as a product owner in fast growing, vc-funded startups in Berlin (including a later Google subsidiary) At the moment, I am working as an agile coach/scrum master for a large European electricity and gas provider