TL; DR: My Top Ten Worst Scrum Anti-Patterns
I recently was invited to a Scrum.org Webinar, and I picked a topic close to my heart: the worst Scrum anti-patterns. So, without further delay, here are my top ten of the meanest, baddest Scrum anti-patterns I have experienced.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 33,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
📈 Free: Download the Agile Metrics Survey 2021.
My Top Ten Worst Scrum Anti-Patterns
Here we go, my personal list of the meanest, baddest Scrum anti-patterns that will guarantee that your Scrum team will be kept shackles and perform well below its potential:
#10: The Oversized Product Backlog
The Product Backlog of your Scrum team comprises hundreds of entries, from user stories to ideas to hypotheses and experiments to documentation fragments—you name it. Dumping everything into the Product Backlog—probably in the name of transparency—poses a massive challenge for various reasons:
- Garbage in, garbage out: Increasing the quantity of input does not increase the outcome of the Scrum Team’s work. In other words: Being “busy” ≠ providing value to customers & the organization.
- The Product Backlog is the Scrum Team’s best chance to identify every Sprint the best way ahead to make your customers’ lives easier. Hence you need signals, not noise. Too many entries may make teammates less inclined to engage in the Product Backlog refinement actively.
The solution: Apply the Goldilocks principle—“just right”—and find your balance as a team. Then, dump the rest. You want an actionable Product Backlog that comprises eight to maybe twelve weeks of work. Be warned, though: Typical objections to deleting unnecessary Product Backlog items range from “we cannot delete them—it is our documentation as required by governance” to “we invested so much work in creating them.” (The former is a form of loss aversion, the latter a manifestation of the sunk cost syndrome.)
Cannot see the form?
Please click here
#9: Misaligned Incentives
The incentives of Scrum teams on the one side and stakeholders or individual team members on the other side contradict each other—which can easily result in a moral hazard. For example, the sales department tries to save the quarterly bonus by ‘requiring’ new features they hope will bring new revenue. Even worse, they start selling “new features” without the Scrum team’s knowledge, probably accepting deadlines and penalties in the process. (It is a form of Product Backlog management through the backdoor.)
#8: The Developers Code Fallacy
Generally, the Scrum team’s Product Owner supports creating a shared understanding among all Scrum team members on the why, the what, and the how. However, the real magic starts unfolding when Developers observe customers when they use the product and listen to them sharing their everyday problems.
However, more often than not, amid adhering to the inherited functional silos, Developers are supposed to deliver “code” and only code. They are not supposed to talk to customers or take over customer support duties to understand their problems first-hand.
From my perspective, that is pure Taylorism at work, entirely output-oriented. The problem is, we are no longer assembling Model-Ts. But we go every day, where no one has ever gone before. In a complex environment, those closest to a problem are best suited to make the right decision to solve it.
Hence, it becomes necessary that all Scrum team members talk directly with customers to understand their challenges better and avoid the misallocation of the Scrum team’s development time. (My rule of thumb: Coding is no more than 50 % of the whole effort of creating value for our customers. The best way to increase the productivity of a Scrum team is to avoid building unnecessary stuff. Now, guess how you can best address this issue? Right: Developers talk to customers.)
#7: Product Owner by Proxy
Your Product Owners do not represent a committee and are hence solely accountable for the maximization of value created on behalf of the customers. Nevertheless, in many organizations, stakeholders see Product Owners primarily as a tactical role, turning requirement documents into Jira tasks.
There are many reasons for that attitude, from being in the early phase of a transformation—thus being less skilled in Scrum—to a general lack of trust in the capabilities of the Scrum Team. No matter the reason, Product Owners in this situation should team up with their Scrum Masters and try to fill the role in the intended way. Otherwise, you may face grave consequences:
- You are likely to end up in a feature factory.
- Probably, you will be shipping the org chart instead of creating real value for the customer. (Conway’s law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”)
- If you practice metered funding for the Scrum Team, on top of that, it is like introducing Waterfall 2.0 through the backdoor.
#6: Hardening Sprint
At the core, this Scrum anti-pattern is a simple challenge: There is no such thing as a hardening Sprint in Scrum.
If there is one thing that comes to mind regarding Scrum, it is the relentless focus on quality, expressed in the Definition of Done and delivered with every Increment. As a Scrum team, our quality goals never decrease; there is no cutting corner whatsoever, such as “it works on my machine.”
Therefore, a hardening Sprint is commonly a sign of a low grade of adoption of agile principles by the Scrum team or the organization. There are plenty of reasons for that; for example, the Scrum team is not yet cross-functional or at an early stage of its Scrum adoption. Alternatively, the “QA department” may still be a functional, non-agile silo. The organization’s incentive structures probably favor the output of the individual over the outcome of the Scrum team. (Which often results in the creation of a feature factory, accumulating technical debt.)
#5: HIPPO-ism
The product creation process is at least partly driven by the beliefs of individuals of the higher management caste. This can be best described with the famous quote from Jim Barksdale, the then CEO of Netscape: “If we have data, let’s look at data. If all we have are opinions, let’s go with mine.”
Think about it: how does the pay-grade, and hence the individual’s position in the social hierarchy of the organization, qualify that person to have the ‘right’ idea? The Macintosh was a brain-child of Steve Jobs, and he deserved credit for that. He also almost killed it prematurely by refusing to add expansion slots to the design. (I do believe that the Macintosh II made the iPhone possible.)
#4: Dogmatism
Although everything points to the incompatibility of the Scrum framework and dogmatism, some Scrum Masters still believe in applying the Scrum Guide literally. Unavoidably, this approach will cause friction in the team and the organization as Scrum is a framework, not a methodology. However, the problem is that teaching as well as “being right” feels good:
- Team members come and ask for help; now, the Scrum Master has a purpose.
- When Scrum team members follow the rules, the Scrum Master has influence or authority.
- Being among the chosen few who interpret the Scrum Guide “correctly” secures status and respect among teammates and the broader organization.
- The Scrum Master may easily attribute the Scrum team’s progress or success to their teaching; now, they also have proof regarding their mastery of Scrum.
- Finally, their mastering of Scrum is a convincing argument for the organization to keep the dogmatic Scrum Master on the pay-role; apparently, the Scrum teams need an interpreter of the Scrum Guide to reap the framework’s benefits.
https://youtu.be/sDBcytKY6uM>
#3: No Failure Culture
Why Embracing Failure as an Option Is Essential
Scrum is about figuring out what is worth building to improve your customers’ lives while mitigating risk in a complex environment. Literally, we do not want to bet the farm on a hunch what customers will purchase in the future. Hence, we employ empiricism—based on transparency, inspection, and adaptation—in a continuous feedback loop that allows us to defer an investment decision to the last economically feasible moment in time.
However, despite all this mitigation effort, any Sprint Goal remains a hypothesis until we release the resulting Increment into the hands of our customers. The release is the moment of truth, and occasional failure is inevitable—even for the best Scrum Teams. Therefore, the question is not if we will fail, but when we will fail. Moreover, how we will deal with the failure.
What Happens If There Is no Failure Culture
A former client of mine, a large utility company, practiced at the time a no-failure approach to promotions: A failed project on your internal record meant you would not take the next step on the career ladder. As a result, everyone played safe, which resulted in short-term orientation as not-failing became more important than innovation. Consequently, the organization was increasingly struggling to attract new (tech) talent when software started eating the world.
Suppose “good” failure is not celebrated as a critical part of the learning process, and incrementalism becomes the name of the game. In that case, the Innovator’s Dilemma, as coined by Clayton Christensen, becomes a more likely fate of the organization. If resilience is a worthwhile goal to achieve, think of Netflix’s chaos monkey, failure needs to be an option.
And failure needs to be openly discussed—without repercussions—so everyone can learn from the case. And as it should be, leaders need to confess first. One approach could “failure nights,” or sharing your wrong decisions from the past openly. For example, see Bessemer Venture Partners’ “The Anti-Portfolio. Honoring the companies we missed.”
#2: Taylorism & Micromanagement
Shouldn’t it be a low-brainer that solving complex adaptive problems of the 21st century does not work by applying methods from the 1890ies? Apparently, it is not. The Manifesto for Agile Software Development has been instrumental in addressing the systemic issues resulting from clinging to Taylorism that numerous organizations still face today.
Unfortunately, this ideology of the need to protect the organization from its workers—who managers expect to start slacking the moment they are not directly supervised—is incompatible with the idea of solving complex, adaptive problems and becoming a learning organization. (If you like to broaden your understanding of the precursors of Taylor’s “scientific management system,” I recommend reading Caitlin Rosenthal’s “Accounting for Slavery.”)
If your commitment to becoming an agile organization is serious, you will need to act upon this challenge.
#1: No Product Vision, no Product Goal
If you don’t know where you’re going, any Product Backlog will get you there. (The classic quote from Lewis Carroll works here, too.) Before you try to come up with a list of stuff to build, fix the product vision problem first as it directly feeds into the Product Goal, which consequently determines the composition of the Product Backlog.
The content and order of the Product Backlog lead to the next question: What are we fighting for? The resulting problem of the lack of a product vision likely means that the Product Owner cannot align the business objective of an upcoming Sprint with the overall product vision and the Product Goal. (A serious Sprint goal is a negotiation between the Product Owner and the rest of the Scrum team to a certain extent. It shall be focused and measurable. The Developers’ forecast, the Sprint Goal, and the business objective go hand in hand.)
Without this structural alignment of product vision, Product Goal, and the resulting Sprint Goals, your Scrum team will stay below its true potential—guaranteed!
Top Ten Worst Scrum Anti-Patterns — Conclusion
Complexity has its challenges, and Scrum is no exception: “The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory.” (Source.)
Adapting and augmenting the framework is hence a necessity. However, by all means, adhere to Scrum’s first principles in the process.
What are your top ten Scrum anti-patterns? Please share them with us in the comments.
The Worst Scrum Anti-Patterns: Recommended Reading
Three Wide-Spread Scrum Master Failures in 5:31 Minutes—Making Your Scrum Work #1
Cargo Cult Agile: The ‘State Of Agile’ Checklist For Your Organization
Scrum First Principles — How to Elon Musk the Scrum Guide
Download the Scrum Anti-Patterns Guide for free.
📅 Scrum Training Classes, Workshops, and Events
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
✋ Do Not Miss Out and Learn more about the Worst Scrum Anti-Patterns — Join the 10,000-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 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.
