Is It Scrum, or Is It Scrum-Adjacent?

Tamara Runyon

I often have students tell me that one of the key insights they have during my scrum certification classes is that they thought they were practicing scrum at their company, but no, they really are not. One student named it scrum-adjacent practices. I love that description! Scrum-adjacent practices: they sound like scrum on the surface – in general, scrum language is used; but behavior has not really changed.

---

An example is when the values and principles of the Agile Manifesto are ignored or, worse yet, unknown! Another example might be when a manager confidently states the team is "scrumming" because they have a "DSU" every day.

Maybe your team has heard the term "definition of done" but is not quite sure what that is. Or your company is using Jira as a tool, and everyone around you claims this is what makes your organization "Agile”.

Well, how do you know? Are you implementing the spirit of Agile? Inspecting and adapting, learning early, and delivering valuable working product frequently? Or are your practices using Agile language (maybe even scrum language), but underneath behavior has not really changed?

Are you finding that despite all the training and language changes, you and your teams are not delivering the expected results or experiencing the team engagement and satisfaction that you were led to believe was the pot of gold at the end of the scrum rainbow?

In this first of a multi-part series (there are so many bad practices out there to cover!), we will explore different signs of trouble that may indicate a team is straying from the core principles of scrum. In this first post, we'll look at one symptom of a potentially scrum-adjacent team: the unempowered scrum team. We will identify a few anti-patterns of behavior that may be contributing to the symptom and discuss the scrum practices that should be happening. 
​
By recognizing the signs of scrum-adjacency (I just made that word up!), you can help your team and organization take corrective action and realign themselves with the true spirit and practices of scrum.

Anti-Patterns

First, let’s identify a few anti-patterns that disempower and de-motivate scrum team members. Practices such as these often lead to disengagement by scrum team members and lackluster results.

Scrum-Adjacent: Product Owner as Product Manager
A clear symptom of an unempowered scrum team is when the scrum developers are assigned work by an individual in advance of the sprint planning event. This may be a product owner, or it may be a first line manager who has not adjusted their behavior from a more traditional management set of practices and does not recognize that they are "managing" rather than leading.

​​This symptom can often be recognized simply be looking at the product backlog. If each sprint has been planned out in detail by the product owner, or if each developer on the team has had tasks assigned in the product backlog itself, this is a sure sign the product owner is really acting as a product manager.
​
Scrum-Adjacent: The Product Backlog is the Sprint Backlog
Another closely related scrum-adjacent practice that can disempower your scrum team is when the product backlog and the sprint backlog are co-mingled in one place in your tool. This scrum-adjacent practice can lead to a situation where the product backlog is treated more like a Gantt chart or work breakdown structure. A tell-tale sign this practice is occurring is when details such as the actual tasks dictate the how, who, and when something will be built. In this scrum-adjacent pattern, these details are often created by the product owner and/or scrum master and then "shared" with the team during sprint planning. 

Scrum-Adjacent: The Distrustful Product Owner
Perhaps the product owner feels they "own" the product, and therefore must track who is doing what on a daily or weekly basis in order to feel that they are in control. Perhaps they are being held responsible for meeting some annual performance targets (sometimes disguised as OKRs) that are handed down from senior management.

A clear indicator of this anti-pattern is when the product owner focuses more on the individual work, believing this will automatically lead to optimal output, but in actuality turning into micromanagement.

Scrum Adjacent: Team Manager as Product Owner
In other situations, when the scrum team is formed, management decides the team’s manager should act as product owner, while continuing to be responsible for team members’ individual performance reviews and career development. Nothing has really changed except the language used. Situations such as this can lead to fear and distrust on the part of the product owner, which leads to fear and distrust on the part of the team. This kind of distrust can drive some very dysfunctional behaviors. 

I've seen a situation where the Product Owner demanded the scrum master report the number of hours each individual team worked on each task. This metric was required on a regular basis and masked as “velocity”. The rationale was to ensure that everyone was contributing equally to the team’s work, which management reasoned would ensure the most efficient way for the team to deliver value. It was very destructive to team morale and engagement.
​
Scrum-Adjacent: The Scrum Master as Project Manager
Another symptom of Scrum-adjacency is when the scrum master is also a project manager. Often, in the early part of a scrum adoption, the scrum master's annual review assumes that they are “managing” the work, and everyone external to the team treats them as if they are doing so. Without support, scrum masters (that were former project managers) in this situation can easily fall back on old behaviors of command and control that worked for them in the past. 

One clear indication of this anti-pattern is when the scrum master feels it necessary to track "velocity" by individual team member, which is a pernicious symptom of micro-management. Another indication is if the scrum master feels they are responsible for ensuring developers are "burning down" an appropriate amount every day and using the burndown chart to direct team members.

The scrum-master-as-project-manager anti-pattern is distressingly common.  For example – a company implements scrum and decides that all project managers are now scrum masters. Nothing has really changed here. The "scrum master/project manager" is focused on the deliverables rather than on the people and practices. There may be a change in language, but this rarely results in changes in behavior that reflect an empowered scrum team.

In a situation such as this, management may direct the scrum master/project manager that they are responsible to ensure the team delivers the product –meeting scope, schedule, and budget. This is an indication that nothing above the team level needs to change, and that the actions necessary to transition to scrum only need to be implemented on the development floor. Nothing could be further from the truth.

Scrum Practices

Now that we’ve identified some common anti-patterns that may result in the unempowered scrum team, let’s explore what healthy scrum practices may look like in similar situations.

Scrum Practice: Product Owners are Fiercely Focused on Outcomes, Not Output.
The product owner's role is to discover and communicate what needs to be built, and in what order; not to manage the work of the scrum team. This can sometimes feel like an ambiguous change from a traditional product manager or business analyst role.

In scrum, the product owner leads the way in defining and communicating product goals and strategy with the team and stakeholders; ensuring the product backlog is populated and prioritized appropriately, and collaborating with the developers to ensure everyone understands what needs to be build and why.

Product owners will make difficult tradeoff decisions when prioritizing product backlog items and be accountable for those decisions. In this way, product owners are responsible for the business value that the team produces, not ensuring everyone is equally busy. 

Product owners cannot succeed without frequent collaboration with scrum developers. A positive sign this collaboration is occurring is that regularly scheduled product backlog refinement meetings are held, during which the entire Scrum Team attends and together reviews high priority product backlog items. Together they create a short "runway" of product backlog items that are ready to be brought into a sprint.

The Product Owner will use this information in the prioritization/ordering of the product backlog. Only the highest priority product backlog items are refined in this collaborative way. This practice follows the lean practice of waiting for the last responsible moment to make important decisions, thereby eliminating the waste in breaking down and defining items far in advance that may eventually be removed from the product backlog altogether. 

Scrum Practice: The Scrum Team Collaboratively Plans the Sprint
By not planning sprints in detail far in advance, we are able to easily accept change late in the process, allowing for new features or functionality to be added or moved up in priority as the product owner and team learn more about their stakeholders’ needs. As the scrum team learns more about the product and stakeholder needs over time, they will be able to practice empiricism, to inspect and adapt to better meet stakeholder needs.  

Scrum Practice: The Scrum Master Supports and Guides
The scrum master should guide, coach, and facilitate conversations for the team rather than control the team. During the sprint, ensuring impediments are removed and protecting the team from distractions and interruptions are all part of the scrum master's work. Letting go of control can sometimes be challenging for scrum masters, but it is essential for fostering a self-managing team.

Letting go of control, however, does not mean leaving a struggling team to learn how to manage themselves and the work of the sprint without help. Coaching, facilitating, listening, communicating, and teaching are all essential skills that scrum masters bring to the team that fosters the environment the team needs to deliver appropriate functionality early and often.

Conclusion

Recognizing signs of trouble in the scrum team is crucial for maintaining the integrity of the scrum framework. By addressing these signs head-on, teams can realign themselves with the core principles of scrum and reap the benefits of agility, collaboration, and continuous improvement.
If you look around and realize your team works in an environment that is dis-empowering, you may be working in a Scrum-adjacent environment. What does a dis-empowering environment look like? If you find managers are focused more on throughput than outcomes, defining unhealthy metrics that must be met, or regularly interfering with the team’s work, these are clear indications.
Remember, Scrum is not a one-size-fits-all solution, and teams should strive to adapt it to their specific context while staying true to its guiding values and practices. With a commitment to self-management, transparency, and continuous learning, teams can overcome challenges and thrive in their Scrum journey.