Webinar #7: Scrum Sprint Anti-Patterns

TL;DR: Webinar #7: Scrum Sprint Anti-Patterns

The seventh Hands-on Agile webinar Scrum Sprint Anti-Patterns analyzed 12 ways a Scrum team can improve its effectiveness by avoiding typical sprint anti-patterns. Learn more about gold-plating, delivering Y instead of X, absenteeism, side-gigs, and organizing people instead of the flow of work.

Update 2018–10–30: The Replay of the Webinar Scrum Sprint Anti-Patterns Is Available

The video of the webinar is available now:

Note: If the browser will not video automatically, click here to watch the replay of the webinar Scrum sprint anti-patterns directly on Youtube.

If you prefer a notification by email, please sign-up for my weekly newsletter and join 19,786 peers.

Download the ’Scrum Anti-Patterns Guide’ — another free ebook from the Hands-On Agile series of practical guides from the trenches. It covers more than 160 scrum anti-patterns that hold your scrum team back.

Webinar Scrum Sprint Anti-Patterns: The Episodes

• The first episode covers the absent Product Owner: This means no feedback to developers during the sprint thus increasing the risk of not meeting the sprint goal. The best product backlog refinement shall not answer all questions in advance — that would be too granular and thus waste. A successful sprint is all about collaboration between the Product Owner and the developer team in real-time.
• The second episode covers the interfering Product Owner: You can change the sprint backlog — if the development team agrees — as the sprint backlog is not static. However, the Product Owner cannot single-handedly change it, for example, increase its scope. (The sprint cancellation is the exception to this rule if you want to consider abandoning the current sprint as a change of its sprint backlog.)
• The Third episode covers scope-stretching or gold-plating: The development team increases the scope of the sprint by adding unnecessary work to sprint backlog items. For example, the development team enlarges a task without prior consulting of the Product Owner. This ignorance may result in a questionable allocation of resources thus endangering achieving the sprint goal as well as creating waste.
• The fourth episode covers out-of-date sprint boards: The development team does not update tickets on the board in time to reflect their current statuses. 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 during the daily Scrum: who needs help, is our plan to achieve the sprint goal still working? An up-to-date board 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 confidence 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.
• The fifth episode covers the flow undermining Scrum Master: 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. Or the SM does not object that the management invites engineers to random meetings as subject matter experts. Or the scrum master allows that either stakeholders or managers turn the daily scrum into a reporting session.
• The sixth episode covers the skipped Retrospective: 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. The proposal is already a sign of how important the team needs a retrospective.
• The seventh episode covers the static sprint goal: According to the Scrum guide, the Scope may be clarified and re-negotiated between the Product Owner and the development team as more is learned. There is no such thing as a static sprint goal.
• The eighth episode covers the 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. Hence hardening sprints are commonly a sign of a low grade of adoption of agile principles by the development team or the (engineering) organization. If you encounter this anti-pattern, ask yourself: Is the development team cross-functional? Or is QA still a functional, non-agile silo? Suggesting a hardening sprint thus violates a core component of Scrum: adherence to the Definition of Done.
• The ninth episode covers variable sprint lengths: The scrum team extends the sprint length by a few days to meet the sprint goal. This extension is just another way of cooking the agile books. Please remember: the sprint goal is delivering working software that delights the customers within the available time-box. Stop lying to yourself, and address the underlying issues — why didn’t the sprint’s outcome meet the sprint goal in time? — during the next retrospective.
• The tenth episode covers special Scrum forces: A manager assigns specific tasks directly to engineers, bypassing the Product Owner. Alternatively, the manager removes an engineer from the Scrum 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 the 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.
• The eleventh episode covers the everything-is-a-bug stakeholder hack: Stakeholders try to speed up delivery of their issues by relabeling tasks as ‘serious bugs.’ First of all — nice try! Nevertheless, the Scrum Master shall address the stakeholders in question and coach them on “useful interaction with the Scrum team.” As Joko Willink likes to say: leadership is not what you preach, but what you let slip through. And while you’re at it: Watch also out for stakeholders trying to sneak in small tasks by pitching them directly to developers.
• The twelveth episode covers the all-hands-to-the-pump moments: The management temporarily abandons Scrum in a critical situation. This is a classic manifestation of disbelief in agile practices, fed by command & control thinking. It is 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.
• The last episode summarizes the dirty dozen of the sprint anti-patterns: from gold-plating, delivery Y instead of X, to absenteeism, side-gigs, and organizing people instead of the flow of work. Don’t miss the next Hands-on Agile mini-series and subscribe to this Youtube channel.

?? Join 825-plus Agile Peers on Youtube

Now available on the Age-of-Product Youtube channel:

• ?? Scrum Sprint Anti-Patterns
• Agile Failure Patterns 2.0
• Product Owner Anti-Patterns

? Do Not Miss Out: Join the 4,100-plus Strong ‘Hands-on Agile’ Slack Community

I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

?? Do you want to read more like this?

Well, then:

• ?? Join 19,786 peers and sign-up for my weekly newsletter
• ?? Follow me on Twitter and subscribe to my blog Age of Product
• ?? Alternatively, join 4,100-plus peers of the Slack team “Hands-on Agile” for free.

Webinar #7: Scrum Sprint Anti-Patterns was first published on Age-of-Product.com.