Development Team Anti-Patterns

Stefan Wolpers — March 15, 2020

TL; DR: Development Team Anti-Patterns

After covering the Scrum Master and the Product Owner, this article addresses Development Team anti-patterns, covering all Scrum Events as well as the Product Backlog artifact. Learn more about what to look out for if you want to support your fellow teammates.

The Role of the Development Team in Scrum

According to the Scrum Guide, the Development Team “consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work.”

Development Teams are hence essential to Scrum’s built-in checks & balances as the Development Team has the sole control over the Sprint Backlog and is watching over the Definition of Done. Generally, Development Teams need to have the following characteristics to be successful:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
• Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
• Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Source: Scrum Guide 2017.

(Check out the complete Scrum Guide 2017 list on the Development Team by downloading the Scrum Guide Reordered.)

While the direction from the Scrum Guide sounds straight forward, in practice, some people get confused that the role “Development Team” is assigned to a group of people, thus creating a sub-team within the larger Scrum Team, while the roles of Scrum Master and Product Owner are assigned to individuals. Even more confusing might be the situation, when both Scrum Master and Product Owner are also actively creating the Product Increment, resulting in the Development Team being identical with the Scrum Team. Finally, the term Development Team seems to limit the role to technical people, for example, software engineers.

However, in my experience, given proper support by the Scrum Master, even lawyers and marketers can get comfortable with the designation “developer” when utilizing Scrum for their purposes. So, let’s dive into an array of common Development Team anti-patterns that signal Scrum Masters that their team needs support.

Development Team Anti-Patterns by Scrum Event

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

Sprint Planning Anti-Patterns of the Development Team

• Capacity? The Development Team overestimates its capacity and takes on too many tasks. (The Development Team should instead take everything into account 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.)
• Ignoring technical debt: The Development Team is not demanding adequate capacity to tackle technical debt and bugs during the Sprint. (The rule of thumb is that about 20 % of resources are well-spent every Sprint to fix bugs and refactor the codebase. If the Product Owner ignores the need for this work, and the Development Team accepts this attitude, the Scrum Team will find itself in a downward spiral, turning slowly but steadily into an output-focused feature factory. Its future product delivery capability will decrease.)
• No slack time: The Development Team is not demanding 20% slack time from the Product Owner. (If a team’s capacity is always over-utilized, its performance will decrease over time. This will particularly happen in an organization with a volatile daily business. As a consequence, everyone will focus on getting his or her tasks done. There will be less time to support teammates or to do pair programming, for example. The team will no longer address smaller or urgent issues promptly. Individual team members will become bottlenecks, which might seriously impede the flow within the team. Lastly, the ‘I am busy’ attitude will reduce the generation of a shared understanding among all team members. Overutilization will always push the individual team member into a less collaborative mindset, impeding self-organization. On the other side, slack time will allow the Scrum Team to act collaboratively and focus on the outcome.)
• Planning too detailed: During the Sprint Planning, the Development Team plans 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.)
• Too much estimating: The Development Team estimates sub-tasks. (That looks like accounting for the sake of accounting to me. Don’t waste your time on that.)
• Too little planning: The Development Team is skipping planning altogether. (Skipping planning is unfortunate, as it is also an excellent opportunity to talk about how to spread knowledge within the Development Team, where the architecture is heading, or whether tools are adequate. For example, the team might also consider who will be pairing with whom on what task. The Development Team planning part is also well-suited to consider how to reduce technical debt, see above.)
• Team leads? The Development Team does not come up with a plan to deliver on its forecast collaboratively. Instead, a ‘team lead’ does all the heavy lifting and probably even assigns tasks to individual team members. (I know that senior developers do not like the idea, but there is no ‘team lead’ in a Scrum Team.

Sprint Anti-patterns

Most of the following Development Team anti-patterns 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 work deemed necessary to meet the Sprint Goal by the end of the Sprint. The flow theory suggests that the productivity of a team improves with a work-in-progress (WiP) limit. The WiP limit defines the maximum number of tasks a development team can work on at the same time. Exceeding this WiP number results in creating additional queues that consequently reduce the overall throughput of the Development Team. The cycle time, which is the period between starting and finishing a ticket, measures this effect.)
• Cherry-picking: The Development Team cherry-picks 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 often notice tickets queueing in the code-review-column, for example. It is also a sign that the Development Team is not yet fully self-organizing. Look also for Daily Scrum events that support this notion, and address the issue during the Sprint Retrospective.)
• Board out-of-date: The team does 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 Development Team’s 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 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 back to PRINCE II is paved with abandoned boards.)
• Side-gigs: The Development Team is 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 Development 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 Development Team is probably rather a group anyway.)
• Gold-plating: The Development Team increases the scope of the Sprint by adding unnecessary work to Product Backlog items of the Sprint Backlog. (This effect is often referred to as scope-stretching or gold-plating. The Development team ignores 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 resources. However, there is a simple solution: the developers and the Product Owner need to talk more often with each other, 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 Development Team, now would be the right moment to reconsider.)

Anti-Patterns of the Daily Scrum

The Daily Scrum is the key “inspect & adapt event” for the Development Team. If the Daily Scrum is not working, at least in my experience, don’t expect the Development Team to meet the Sprint Goal. Common Development Team anti-patterns of the Daily Scrum include:

• 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 stand-up, 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?)
• Status report: The Daily Scrum is a status report meeting, and Development Team members are waiting in line to “report” progress to the Scrum Master, the Product Owner, or maybe even a stakeholder.
• Ticket numbers only: Updates are generic with little or no value to others. (“(March 16, 2020), I worked on X-123. Today, I will work on X-129.”)
• Problem-solving: Discussions are triggered to solve problems, instead of parking those so they can be addressed after the Daily Scrum.
• Planning meeting: The Development Team hijacks the Daily Scrum to discuss new requirements, to refine user stories, or to have a sort of (Sprint) planning meeting.
• 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? Often, the Development Team cannot answer that question immediately. (In that respect, visualizing the progress towards the Sprint Goal is a useful exercise. Removing the Development Team task of maintaining a mandatory burndown chart from the Scrum Guide a few years ago does not imply that a burndown chart is obsolete.)
• No use of work-item age: A Development team member 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 Development Team 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.)
• Cluelessness: Team members are not prepared for the Daily Scrum. (“I was doing some stuff, but I cannot remember what. Was important, though.”)
• Excessive feedback: Team members criticize other team members right away sparking a discussion instead of taking their critique outside the Daily Scrum.

Development Team Anti-Patterns: Sprint Review

• Death by PowerPoint: Participants 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.)
• Same faces again: It is always the same folks from the Development Team who participate, not everyone. (Unless the organization scales Scrum based on LeSS or Nexus and we are talking about the overall Sprint Review, this Sprint Review Anti-pattern is a bad sign. To maximize the learning, the Sprint Review needs all Scrum Team members on deck. The challenge is that you cannot enforce the team’s participation either, however. Instead, make it interesting enough that everyone wants to participate. If this is not happening, you should — as a Scrum Master — ask yourself how you have contributed to this situation.)
• Cheating: The Development Team shows items that are not “done.” (There is a good reason to show unfinished work on some occasions. Partially finished work, however, violates the concept of “Done,” one of Scrum’s first principles.)
• No Sprint Review: There is no Sprint Review, as the Development Team did not meet the Sprint Goal. (A rookie mistake. Particularly in such a situation, a Sprint Review is necessary to create transparency.)

Sprint Retrospective Anti-Patterns of the Development Team

• #NoRetro: There is no retrospective as the Development Team believes there is nothing to improve. (There is no such thing as an agile Nirwana where everything is just perfect. As people say: becoming agile is a journey, not a destination, and there is always something to improve.)
• Dispensable buffer: The team cancels 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 is a clear sign 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 going on here. Guess which Scrum event is designed for that purpose?)
• Extensive whining: The Development Team uses the retrospective primarily to complain about the situation and assumes the victim’s role. (Change requires reflection, and occasionally it is a good 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.)
• Product Owner non-grata: The Product Owner is not welcome to the retrospective. (Some folks still believe —for whatever reasons—that only the Development Team members and the Scrum Master shall attend the team’s retrospective. However, the Scrum Guide refers to the Scrum Team, including the Product Owner. It does so for a good reason: the team wins together, and the team fails together. How is that supposed to work without the Product Owner?)

Anti-Patterns at the Product Backlog Level

• No time for refinement: The team does not have enough refinement sessions, resulting in a low-quality backlog. (The Scrum Guide advises spending up to 10% of the Development Team’s time on the Product Backlog refinement. Which is a sound business decision: Nothing is more expensive than a feature that is not delivering any value.)
• Too much refinement: The team has too many refinement sessions, resulting in a too detailed backlog. (Too much refinement isn’t healthy either.)
• Submissive team: The Development Team submissively follows the demands of the Product Owner. (Challenging the Product Owner whether his or her selection of issues is the best use of the Development Team’s time is the noblest obligation of every team member: why shall we do this?)

Development Team Anti-Patterns — Conclusion

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

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

Business & Finance Articles on Business 2 Community

(26)