Scrum Developer Anti-Patterns

TL; DR: Scrum Developer Anti-Patterns

After covering the anti-patterns of the Scrum Master, the Product Owner, and the stakeholders, this article addresses Scrum Developer anti-patterns, covering all Scrum Events and the Product Backlog artifact. Continue reading and learn more about what to look out for if you want to support your teammates who build the Increment.

🇩🇪 Zur deutschsprachigen Version des Artikels: Fehlverhalten von Scrum Entwicklern.

🗳 Update: Join the poll and its lively discussion on LinkedIn.

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.

🎓 Join Stefan in one of his upcoming Professional Scrum training classes!

🖥 💯 🇩🇪 Professional Scrum Product Owner Training w/ PSPO Certificate — Online: June 28-July 1, 2022.

The Role of the Developers in Scrum

According to the Scrum Guide, the “Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint:”

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

• Creating a plan for the Sprint, the Sprint Backlog;
• Instilling quality by adhering to a Definition of Done;
• Adapting their plan each day toward the Sprint Goal; and,
• Holding each other accountable as professionals.

Also, Developers enjoy complete autonomy regarding the technical side of their work:

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

Source: Scrum Guide 2020. 

(Check out the complete Scrum Guide 2020 list on the Developers by downloading the Scrum Guide Reordered.)

The term “Developer” seems to limit the role to technical people, for example, software engineers. However, in the spirit of the Scrum Guide, the term Developer is much more inclusive. In my experience, given proper support from the Scrum Master and the Product Owner, even lawyers and marketers can get comfortable with this designation when utilizing Scrum.

So, let’s dive into an array of common Scrum Developer anti-patterns that signal Scrum Masters that their teammates need support.

Developer Anti-Patterns by Scrum Events

The following list of Developer anti-patterns addresses all four Scrum events plus the Sprint itself:

Sprint Anti-Patterns

Most of the following Developer anti-patterns mostly result from a lack of focus or procrastination:

• No WiP limit: There is no work in progress limit. (The purpose of the Sprint is to deliver a potentially shippable Product Increment that provides value to the customers and thus to the organization. This goal requires focused work to accomplish the necessary work to meet the Sprint Goal by the end of the Sprint. The flow theory suggests that a team's productivity improves with a work-in-progress (WiP) limit. The WiP limit defines the maximum number of tasks the Developers can work on simultaneously. Exceeding this WiP number creates additional queues that consequently reduce the overall throughput of the Developers. The cycle time—the period between starting and finishing a ticket—measures this effect.)
• Cherry-picking: The Developers cherry-pick work. (This effect often overlays with the missing WiP issue. Human beings are motivated by short-term gratifications. It just feels good to solve yet another puzzle from the board, here: coding a new task. By comparison to this dopamine fix, checking how someone else solved another problem during code review is less rewarding. Hence you may notice tickets queueing in the code-review-column, for example. It is also a sign that the Developers are not yet fully self-organizing. Look for Daily Scrum events that support this notion and address the issue during the Sprint Retrospective.)
• Board out-of-date: The Developers do not update tickets on the Sprint board in time to reflect the current statuses. (The Sprint board, no matter if it is a physical or digital board, is not only vital for coordinating the Developers’ work. 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. Deteriorating confidence may then cause counter-measures on the side of the stakeholders. Consequently, the (management) pendulum may swing back toward traditional methods. The road back to PRINCE II is paved with abandoned boards.)
• Side-gigs: The Developers are working on issues that are not visible on the board. (While sloppiness is excusable, siphoning off resources and by-passing the Product Owner—who is accountable for the return on investment the Scrum Team is creating—is unacceptable. This behavior also signals a substantial conflict within the “team.” Given this display of distrust—why didn’t the engineers address this seemingly important issue during the Sprint Planning or before—the Developers are probably rather a group than a team anyway.)
• Gold-plating: The Developers increase the scope of the Sprint by adding unnecessary work to the Product Backlog items of the Sprint Backlog. (This effect is often referred to as scope-stretching or gold-plating. The Developers ignore the original scope agreement with the Product Owner. For whatever reason, the team enlarges the task without prior consulting of the Product Owner. This ignorance may result in a questionable allocation of development time. However, there is a simple solution: the Developers and the Product Owner need to talk more often, creating a shared understanding from product vision down to the individual Product Backlog item, thus improving the trust level. If the Product Owner is not yet co-located with the Developers, now would be the right moment to reconsider. Alternatively, a distributed Scrum Team may invest more time in how to communicate synchronously and asynchronously best to improve its level of collaboration and alignment.)
• Ignoring the Definition of Done: The Developers reduce product quality below the level defined in the Definition of Done to meet a deadline. (The Definition of Done serves a critical role in the Scrum framework: It represents the quality standard that signals to everyone what the Developers need to accomplish to create a potentially releasable Increment. By “releasable,” we mean that we can deliver the Increment into the hands of our customers and users without any legal, financial, or ethical repercussions. Watering this quality level down to meet a—properly arbitrary—deadline imposed on the team puts the team’s success at risk as it introduces undone work and technical debt. Both of these consequences of neglecting the quality standard will impede the Scrum team’s ability to be innovative at a later stage. Please note that there is no business agility without technical excellence. The latter starts with adhering to the Definition of Done at all times.)
• What technical debt? The Developers do not demand adequate time to tackle technical debt and bugs and preserve the quality standard of the product. Instead, they fully embrace the feature factory, shipping one new feature after the other. (My rule of thumb is that the Developers shall consider allocating up to 20 % of their time to fixing bugs and refactoring the codebase. A high-quality tech stack is at the core of being able as a Scrum team to adapt the following steps to lessons learned and recent market trends. Technical excellence is a prerequisite of any form of business agility; preserving this state is a continuous process that requires a steady and substantial investment. Read more: Technical debt and Scrum.)
• No slack time: The Developers do not demand 20% slack time—or unplanned capacity—from the Product Owner. (This overlaps with the Sprint Planning, creating Sprint Goals, and the team’s ability to forecast. However, it cannot be addressed early enough. If a team’s capacity is always utilized at 100 %, its performance will decrease. Everyone will focus on getting their tasks done. There will be less time to support teammates or to pair. Minor issues will no longer be addressed immediately. And ultimately, the ‘I am busy’ attitude will reduce the creation of a shared understanding among all team members why they do what they are doing.)

Sprint Planning Anti-Patterns of the Developers

Scrum’s Sprint Planning aims to align the Developers and the Product Owner on what to build next, delivering the highest possible value to customers. Some common Developer anti-patterns are as follows:

• No capacity check: The Developers overestimate their capacity and take on too many tasks. (The Developers should instead consider everything that might affect its ability to deliver. The list of those issues is long: public holidays, new team members and those on vacation leave, team members quitting, team members on sick leave, corporate overhead, Scrum events as practices such as Product Backlog refinement, and other meetings, to name a few.)
• Planning too detailed: During the Sprint Planning, the Developers plan every single task of the upcoming Sprint in advance. (Don’t become too granular. One-quarter of the tasks are more than sufficient to not just start with the Sprint, but also start learning. The Sprint Backlog is emergent, and doing too much planning upfront might result in waste. Scrum is not a time-boxed form of the waterfall planning practice.)
• Too little planning: The Developers skip planning altogether. (Skipping planning is unfortunate, as it is also an excellent opportunity to talk about how to spread knowledge among the Developers, where the architecture is heading, or whether the tools are adequate. For example, the team might also consider who will be pairing with whom on what task. The Developers’ planning part is also well-suited to consider how to reduce technical debt, see above.)
• Team leads? The Developers do not devise a plan to deliver their forecast collaboratively. Instead, a ‘team lead’ does all the heavy lifting and probably even assigns tasks to individual Developers. (I know that senior developers do not like the idea, but there is no ‘team lead’ on a Scrum Team. Read More: Why Engineers Despise Agile.)

Developer Daily Scrum Anti-Patterns

The Daily Scrum is an essential event for inspection and adaption, run by the Developers, and guiding it for the next 24 hours on its path to achieving the Sprint Goal. The Daily Scrum is hence the shortest planning horizon in Scrum and thus highly effective to guide the Scrum team’s efforts. 

Contrary to popular belief, its 15-minutes timebox is not intended to solve all the issues addressed during the Daily Scrum. It is about creating transparency, thus triggering the inspection. If an adaption of the plan or the Sprint Backlog, for example, is required, the Developers are free to handle the resulting issues at any time. In my experience, most Daily Scrum anti-patterns result from a misunderstanding of this core principle.

• No routine: The Daily Scrum does not happen at the same time and the same place every day. (While routine has the potential to ruin every Retrospective, it is helpful in the context of the Daily Scrum. Think of it as a spontaneous drill: don’t put too much thought into the Daily Scrum, just do it. Skipping Daily Scrums can turn out to be a slippery slope: if you skip one Daily Scrums or two, why not skip every second one?)
• Orientation lost: The Daily Scrum serves one purpose as it answers a simple question: Are we still on track to meet the Sprint Goal? Or do we need to adapt the plan or the Sprint Backlog or both? Sometimes though, the Developers cannot answer that question immediately. (In that respect, visualizing the progress towards the Sprint Goal is useful. Removing the Developers’ task of maintaining a mandatory burndown chart from the Scrum Guide a few years ago does not imply that such a visualization is useless.)
• Cluelessness: Developers are not prepared for the Daily Scrum. (“I was doing some stuff, but I cannot remember what. Was important, though.”)
• Status report: The Daily Scrum is a status report meeting, and Developers are waiting in line to “report” progress to the Scrum Master, the Product Owner, or maybe even a stakeholder. (The “three Daily Scrum questions” often serve as a template for this anti-pattern.)
• Ticket numbers only: Updates are generic with little or no value to others. (“Yesterday, I worked on X-123. Today, I will work on X-129.”)
• Planning meeting: The Developers hijack the Daily Scrum to discuss new requirements, refine user stories, or have a sort of (Sprint) Planning Meeting, probably collaborating with the Product Owner.
• Problem-solving: Discussions are triggered to solve problems, instead of parking those so they can be addressed after the Daily Scrum.
• Excessive feedback: Team members criticize other team members right away sparking a discussion instead of taking their critique outside the Daily Scrum.
• Monologs: Team members violate the timebox, starting monologs. (60 to 90 seconds per team member should be more than enough time on-air.)
• Statler and Waldorf: A few team members are commenting on every issue. (Usually, this is not just a waste of time, but also patronizing and annoying.)
• No use of work-item age: A Developer experiences difficulties in accomplishing an issue over several consecutive days and nobody is offering help. (Often, this result is a sign that people either may not trust each other or do not care for each other. Alternatively, the workload of the Developers has reached an unproductive level as they no longer can support each other. Note: Of course, the Scrum Guide does not mention the ‘work item age.’ However, it has proven to be a useful practice.)
• There are never any impediments: No one reports any obstacles; no one needs any help or support from their teammates. (Congratulations on your seemingly well-oiled machine! However, maybe, Developers do not feel safe to address issues, challenges, or problems?)

Developer Anti-Patterns concerning the Sprint Review

Are we still on track to accomplish the Product Goal? Moreover, how did the previous Sprint contribute to our Scrum team’s mission? Answering these questions and adapting the Product Backlog in a collaborative effort of the Scrum Team with internal and external stakeholders is the purpose of the Sprint Review. Some common anti-patterns are:

• Death by PowerPoint: Participants of the Sprint Review are bored to death by PowerPoint. (The foundation of a successful Sprint Review is “show, don’t tell,” or even better: let the stakeholders drive the discovery. The Sprint Review is not a “demo,” carefully avoiding all obstacles to preserve the illusion of progress and control. Instead, it is an essential opportunity to inspect what the Scrum team accomplished, receive valuable feedback, and adapt the Product Backlog collectively. It is about creating transparency on the state of the progress toward the Product Goal.)
• Same faces again: It is always the same Developers who participate in the Sprint Review; however, they are not all Developers. (Unless the organization scales Scrum based on LeSS or Nexus and we are talking about the overall Sprint Review, this Sprint Review anti-pattern of limited attendance of Scrum team members is a bad sign. The Sprint Review needs all Scrum team members on deck to maximize the learning. The challenge is that you cannot enforce your teammates’ participation either. Instead, make it interesting enough that everyone wants to participate. If this is not happening, you should ask yourselves how you have contributed to this situation in the past. It is lucky a coincidence that an event tailored to this need follows immediately after the Sprint Review — the Retrospective.)
• Side gigs: The Developers worked on issues outside the Sprint Goal, and the Product Owner learned about those for the first time during the Sprint Review. (This Sprint Review anti-pattern is truly “rocking the boat.” Focus, commitment, and openness — just to name the most apparent Scrum values violated here — are the first principles for collaboration among Scrum team members. Anything that the Developers want to address during the Sprint needs to be communicated during the Sprint Planning. However, a particular case is when the Product Owner is usually so pushy about shipping new features that there is little or no time to attend to refactoring or bug fixing unless the Developers tackle these jobs under the radar. In this situation, I would have sympathy for the approach. Nevertheless, the Scrum team needs to fix this problem. Generally, allocating 20 % of the team’s capacity to the before-mentioned tasks could be a start.) 
• Undone is the new “done:” More often than not, the Developers show work items that are not “done.” (There is a good reason to show unfinished work on some occasions. For example, to provide transparency to stakeholders on essential yet challenging tasks. However, regularly reporting to Sprint Review attendees on partially finished work violates the concept of “Done,” one of Scrum’s first principles. There is no need for a successful Scrum team to demonstrate to stakeholders that they are worth their pay-cheques.)

Retrospective Developers Anti-Patterns

What event could better embody Scrum’s principle of empiricism than the Sprint Retrospective? I assume all peers agree that even the simplest form of a Retrospective—if only held regularly—is far more helpful than having a fancy one once in a while, not to mention having none. Some notorious Developer anti-patterns include:

• #NoRetro: There is no Retrospective as the team believes there is nothing to improve, and the Scrum Master accepts this notion. (There is no such thing as an agile Nirwana where everything is perfect. As people say: becoming agile is a journey, not a destination, and there is always something to improve.) 
• Dispensable buffer: The Developers cancel Retrospectives if more time is needed to accomplish the Sprint Goal. (The Retrospective as a Sprint emergency reserve is a common sign of cargo cult Scrum. I believe it is even a worse anti-pattern than not having a retrospective because there is presumably nothing to improve. That is just an all-too-human fallacy bordering on hubris. However, randomly canceling a Retrospective to achieve a Sprint Goal clearly shows that the team does not understand basic principles, such as empiricism and continuous improvement. If the Scrum team repeatedly does not meet the Sprint Goal, it should inspect what is happening here. Guess which Scrum event is designed for that purpose?) 
• Not improving the Definition of Done: The Developers do not advocate regularly revisiting the Definition of Done and discussing whether it needs to improve. (As the saying goes: Standing still is moving backward. When the Scrum team increasingly better understands how to solve its customers’ problems, this advance in knowledge needs to be represented in a regularly adapted Definition of Done. Otherwise, the Scrum team would risk diminishing its contribution to the organization’s overall path to business agility.) 
• Extensive whining: The Developers use the Retrospective primarily to complain about the situation and assumes the victim’s role. (Change requires reflection, and occasionally it is a suitable exercise to let off steam. However, not moving on once you have identified critical issues and trying to change them defies the purpose of the Retrospective.) 

Developer Anti-Patterns at the Product Backlog Level

Scrum is a tactical framework to build products, provided you identify what is worth making in advance. But even after a successful product discovery phase, you may struggle to create the right thing in the right way if your Product Backlog is not up to the job—garbage in, garbage out. Some forms by which Developers contribute to mediocre team success are:

• No time for refinement: The Developers do not have enough Product Backlog refinement sessions, resulting in a low-quality backlog. (The Scrum Guide no longer advises spending up to 10% of the Developers’ time on the Product Backlog refinement. However, investing in good refinement is still a sound business decision: Nothing is more expensive than a feature that is not delivering any value.)
• Too much refinement: The Scrum team has too many refinement sessions, resulting in a too detailed Product Backlog. (Too much refinement isn’t healthy either. There is a moment when the marginal return of an additional refinement effort is zero or probably even negative—think analysis-paralysis. The only way for a Scrum team to understand whether the previous validation of the underlying hypotheses of a new feature is correct is to build and ship this thing. There is no way to figure this out at the green table, refining and discussing the issue endlessly.)
• Too much estimating: The Developers even estimate sub-tasks. (That looks like accounting for the sake of accounting to me. So don’t waste your time on that. Remember: the purpose of estimating is to identify misalignment among the Developers regarding the What and How of items from the Product or Sprint Backlog. Read more: Estimates Are Useful, Just Ditch the Numbers.)
• Over-sized Product Backlog: The team creates a massively comprehensive Product Backlog. (Building an “inventory of work-items” is an anti-pattern. In a complex environment with a lot of uncertainty, though, this upfront investment likely leads to waste in the form of Product Backlog items that are refined but will never be released as more valuable items are later identified. The Developers should point to this challenge and support the Product Owner in keeping the Product Backlog concise and actionable; an inventory of three to six Sprints is typically more than adequate.
• A submissive Scrum team: The Developers submissively follow all demands of the Product Owner. (Challenging the Product Owner whether their selection of work items is the best use of the Developers’ time is the noblest obligation of every team member: Why shall we do this? Scrum does not work without everyone living up to the checks & balances built into the framework. It is easy to fall in love with “your solution” over addressing the real customer problem. If Developers simply make whatever the Product Owner “suggests,” the overall value created by the Scrum team will likely be below its potential. That is why you want missionaries on your team, not just mercenaries.)

Scrum Developer Anti-Patterns — Conclusion

Given the essential role Developers have to live up to make Scrum successful, it is no surprise that there are plenty of anti-patterns to observe. The good news is, though, that many of those are entirely under the control of the Scrum Team. All it takes to tackle these Developer anti-patterns for the team is starting to inspect and adapt. Why not use your next Retrospective for this purpose?

Which Developer anti-patterns have you observed? Please, share them with us in the comments.

📖 Developer Anti-Patterns — Related Posts

27 Product Backlog and Refinement Anti-Patterns

27 Sprint Anti-Patterns Holding Back Scrum Teams

Scrum: 20 Sprint Planning Anti-Patterns

Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team

15 Sprint Review Anti-Patterns Holding Back Scrum Teams

21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams

Download the Scrum Anti-Patterns Guide for free

✋ Do Not Miss Out and Learn more about Developer Anti-Patterns — Join the 11,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.

The article Scrum Developer Anti-Patterns was first published on Age-of-Product.com. (This is another one for you, Shaun.)