36 Scrum Stakeholder Anti-Patterns

TL; DR: Scrum Stakeholder Anti-Patterns

Learn how individual incentives and outdated organizational structures — fostering personal agendas and local optimization efforts — manifest themselves in Scrum stakeholder anti-patterns that easily impede any agile transformation to a product-led organization.

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

🗳 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!

The Scrum Stakeholder and Organizational Excellence in Legacy Organizations

Regularly, InfoQ applies the ‘Crossing the Chasm’ metaphor to engineering practices, thus covering a part of the agile movement to create learning organizations. Its ‘Culture & Methods Trends Report March 2022’ edition found that recent converts to Scrum, for example, will recruit themselves mostly from the late majority and laggards. (The early majority of organizations already embrace business agility, team self-selection, and mob/ensemble programming.)

Those laggards — or legacy organizations — are easy to spot: Some form of applied Taylorism, usually a strict hierarchy to command & control functional silos with limited autonomy, made it into the postindustrial era. Often, these organizations were once created to train farm boys into assembly-line workers within a standardized industrial process churning out standardized products in the name of output optimization. Human beings became cogs in the machinery, rewarded for functioning well without asking questions. Too bad, when nowadays, diversity, autonomy, mastery, and purpose become the driving factors in a highly competitive environment where more of the same for everyone is no longer creating value.

Copyright notice: InfoQ, 2022. All right reserved.

The conflict at the stakeholder level in such legacy organizations is apparent: mostly, the stakeholder is a manager of a functional silo with objectives that do not necessarily align with those of a product or Scrum Team. Where the organization needs to morph into a kind of ‘team of teams’ structure with a shared understanding of purpose and direction as well as the need to create value for the customers at heart, the reality of a legacy organization attempting to become agile is often very different. For managers, it means moving:

• From WIIFM (what-is-in-for-me syndrome) to team-playing — the team wins, the team loses,
• From career planning as an individual to servant leadership in a team of teams structure,
• From knowing it all and being the go-to person to solve problems to trusting those closest to the problem to come up with a solution,
• From ‘failure is no option’ to accepting failure as a means to learn effectively,
• From claiming success as a personal contribution to stepping back and letting the responsible team shine.

Abandoning yesterday's game – and probably its symbols of power, too — and accepting that an agile transformation may provide job security, but most certainly not role security is a monumental undertaking for the majority of the management of a legacy organization. Many of these managers will probably not adapt and even quit the organization sooner or later.

Cannot see the form?
Please click here.

Common Scrum Stakeholder Anti-Patterns

After defining the context, let us consider some Scrum stakeholder anti-patterns in detail. Often, Scrum stakeholder anti-patterns result from a training and coaching void accompanied by preserving individual career objectives. Common in these cases, the organization may limit ‘becoming agile’ to product and engineering teams while the rest of the organization continues practicing the principles of the industrial age. In this context, stakeholder anti-patterns from a Scrum team perspective manifest themselves in the continued pursuit of local optima and personal agendas. Additionally, the incentive structure of the organization likely still fosters predictable stakeholder behavior that contradicts the organization’s goals at a system level.

Charlie Munger: “Never, ever, think about something else when you should be thinking about the power of incentives.”

The following list of Scrum stakeholder anti-patterns addresses system-related issues, issues of individual players, and anti-patterns specific to Scrum events.

Scrum Stakeholder Anti-Patterns at System Level

These anti-patterns result mainly from a half-hearted approach to becoming an agile organization. Typically, this attitude ends in a form of cargo-cult agile:

• Lack of transparency: The organization is not transparent about vision and strategy hence the Scrum Teams are hindered to become self-managing. (“If you don't know where you are going, any road will get you there.” In a complex environment with high levels of competition and uncertainty, everyone needs to understand the Why, the What, the How, and the Who. A lack of transparency will stop any effort to become agile dead in the tracks as missionaries won’t flock to the cause but mercenaries. Elon Musk’s “The Secret Tesla Motors Master Plan (just between you and me)” is a good example of leadership transparency at the vision and strategic level.)
• Lack of leadership support: Senior management is not participating in agile processes, for example, the Sprint Reviews, despite being a role model. Instead, they expect a different form of (push) reporting. (The support of the upper management is mission-critical for any transformation. No Scrum team will be successful if the ‘leadership’ is not leading the effort; for example, attending Sprint Reviews to signal everyone in the organization: Becoming agile is here to stay; it is not a fad.)
• Cargo-cult agile by cherry picking: Agile processes are either bent or ignored whenever it seems appropriate, for example, the Product Owner role is reduced to a project manager role. Or stakeholders are bypassing the Product Owner to get things done and get away with it in the eyes of the senior management, as they would show initiative. There is a lack of discipline to support the agile transformation. (Cherry-picking agile practices while ignoring the context required to make them work is a common form of window dressing ‘agility.’ However, being a part of a complex system, isolated agile elements typically rarely work if the organization aims to achieve ‘business agility.’ Becoming agile requires a mindset change followed by organizational change. Simply having ‘retrospectives’ once in a while won’t cut it.)
• Agile on a tight budget: The organization does not spend enough time and budget on proper communication, training, and coaching to create a shared understanding of purpose and direction among all organization members. (Becoming agile and embracing business agility is a monumental and expensive undertaking. Moreover, while expenditures become immediately apparent, the organization may not reap the return on investment for years to come. Therefore, cutting back on necessary expenses early in the transformation, pointing at a ‘lack of results’ is a sure-fire path to failure.)
• Telling people how to do things: In the good old times on the shop floor, it was a valuable trait to train newcomers or workgroups in the art of assembling a Model T — as the manager probably did herself. Nowadays, as we invest most of our time building products that have never been built before, this attitude becomes a liability. (Let the people closest to the job at hand figure out how to do this; in a complex environment, there are no experts: “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.) Guiding by objectives and providing support when requested or needed will be appreciated, though.)
• Steering committee meetings: Unimpressed by the agile ways of working, the stakeholder insist on continuing the bi-weekly steering meetings to ensure that the Scrum team will deliver all their requirements in time. (This one has a quick remedy: Just do not participate in meetings that have no value for the Scrum team while reaching out to the stakeholder and supporting their learning path.)
• Limited to non-existing feedback loops: The sales organization and other functional silos guard the direct access to customers, thus preventing the Scrum teams from learning directly from customers. (The sales organization probably deems a direct contact of Scrum Team members with customers too risky (for their sales plans) and prevents it from happening. The problem is that filtering feedback from customers mainly results in a limited understanding of the customer’s situation on the side of the Scrum team. Furthermore, due to a likely lack of technical competence on the side of the sales organization, critical information regarding potential solutions may never reach the Scrum team, thus limiting its ability to tailor a solution to the customer’s needs. To become an effective product delivery organization, it is hence essential that the Scrum team directly communicate with customers regularly.)

Sprint Anti-Patterns of the IT Management

Also, there are some typical anti-patterns of those stakeholders closest to the Scrum Teams — the IT management:

• All hands to the pumps w/o Scrum: The management temporarily abandons Scrum in a critical situation. (This is a classic manifestation of disbelief in agile practices, fed by command & control thinking and a bias for action to feel “in control” of the situation on their side. Most likely, canceling Sprints and gathering the Scrum Teams would also solve the issue.)
• Reassigning team members: The management regularly assigns team members of one Scrum Team to another team. (Scrum can only live up to its potential if the Scrum Team members can build trust among each other. The longevity of Scrum Teams has proven beneficial to build that trust. Moving people between teams, on the contrary, reflects a project-minded idea of management, rooted in utilization optimization of “human resources” of the industrial paradigm. It also ignores the preferred team-building practice that Scrum Teams should select themselves. All members need to be voluntarily on a team. Scrum does not work if team members are pressed into service. Note: It is not an anti-pattern, though, if Scrum Teams decide to exchange teammates temporarily. It is an established practice that specialists spread knowledge this way or mentor other colleagues. Also, dynamic re-teaming does not constitute an anti-pattern when the members of the involved Scrum Teams decide to do so.)
• Special forces: A manager assigns specific tasks directly to Developers, thus bypassing the Product Owner and ignoring the Developer’s self-organization prerogative. Alternatively, the manager removes a Developer from a 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 of command and control practices. They continue to micromanage subordinates, although a Scrum Team could accomplish the task self-organized. This behavior demonstrates a level of ignorance that may require support for the Scrum Master from a higher management level to deal with.)

Personally Motivated Scrum Stakeholder Anti-Patterns

There are numerous ways in which stakeholders can impede the progress of a product team. Five of the most common ones are as follows:

• ‘My budget’ syndrome: Stakeholders do not pitch for a Scrum team’s attention but claim that they allocate “their” budget on feature requests as they see fit. (That process leads to the creation of local optima at a silo or departmental level. The effect can be observed mainly in organizations that tie additional benefits to individuals. Instead, product development capacity needs to be allocated in the spirit of optimizing the whole organization. Note: ‘pet projects’ also fall in this category.)
• ‘We know what to build’: The is no user research, nor any other interactions of the product delivery organization with customers. (Several reasons are causing this phenomenon ranging from a founder or entrepreneur who pursues their product vision without engaging in customer discovery activities. Or the product delivery organization is solely briefed indirectly by key account managers. The sales department probably deems direct contact of the Scrum Team members with customers too risky and prevents it from happening. These patterns share either a bias that is hurting the learning effort or a personal agenda. While the former can be overcome by education, the latter is more challenging to come by as the culprits typically reject the idea that selfish motives guide them. To become an effective product delivery organization, it is essential that the team directly communicate with customers regularly.)
• Selling non-existing features: What features do you need us to provide to close the deal? Sales managers chase sales objectives by asking prospects for a feature wish-list and forwarding those to the product delivery organization as requirements. (The customers' problem is that they usually lack the depth of knowledge required to provide valuable answers to this question. They also lack the level of abstract thinking necessary to develop a valuable, viable, usable, and feasible solution. As the saying goes: if the only tool you are familiar with is a hammer, every problem will look like a nail. Pursuing the sales process in such a way will lead the product into a feature comparison race to the bottom, probably inspired by bonuses and personal agendas. This is why product folks like to observe customers in their typical environment using a product to avoid misallocating resources on agenda-driven features. At a systems level, reconsidering individual monetary incentives for salespeople is helpful, too. In a learning organization, teams win, not individuals.)
• Bonus in limbo: We are nearing the end of a quarter. Bonus-relevant KPIs (key performance indicators) are at risk of not being met. The responsible entity demands product changes or extensions, hoping that those will spur additional sales. (This behavior is comparable with the ‘what features do you need to close the deal’ anti-pattern, but it is demanded in a more pressing fashion, typically four to six weeks before the end of a bonus period.)
• Financial incentives to innovate: The organization incentivizes new ideas and suggestions monetarily. (Contributing to the long list of ideas and thus the hypotheses short-list should be intrinsically motived. Any possible personal gain might inflate the number of suggestions without adding much value while making it harder for the product organization to identify the signal in the noise.)

📺 For more information, please watch the webinar: Product Discovery Anti-patterns.

Scrum Stakeholder Anti-Patterns at Scrum Event Level

The Sprint

Anti-patterns of this sort point at stakeholders’ ignorance of the core idea of Scrum — self-managing teams:

• (Regular) emergency work: Someone in your organization has sold a non-existing feature or functionality to a customer to close a deal, probably already including delivery dates and contractual penalties in the case of non-delivery. Now, they want the Scrum Team to focus on delivering this item. (There might be moments where this outside intervention in the Scrum process may be unfortunate but acceptable. The more concerning issue here is the prospect of this behavior becoming a regularity. If the leadership does not acknowledge the exceptionality of the situation, it may derail using Scrum in the organization.)
• Pitching Developers: The stakeholders try to sneak in small tasks by pitching them directly to Developers. (Nice try #1. However, all suggestions for the future allocation of the Scrum Team’s time compete with each other, and the Product Owner is the referee in this process.)
• Everything’s a bug: The stakeholders try to speed up delivery by relabeling their tasks are ‘serious bugs.’ (Nice try #2. A particular case is an “express lane” for bug fixes and other urgent issues which some Scrum teams establish. In my experience, every stakeholder will try and make their tasks eligible for that express lane.)
• Flow disruption: The Scrum Master allows stakeholders to disrupt the flow of the Scrum Team during the Sprint. There are several possibilities for how stakeholders can interrupt the team’s flow during a Sprint, for example:
  
  • Stakeholders constantly address Developers during the Sprint, ignoring that regular interruptions harm the Scrum team’s effectiveness; here: accomplishing the Sprint Goal. (Note: I do not advocate that Scrum Masters shall restrict stakeholders’ access to team members in general. However, they need to educate stakeholders on how to best communicate with the Scrum team.)
  • Line managers take team members off the Scrum Team, assigning them to other tasks. (Creating a Scrum team is an expensive exercise due to the inevitable drop in productivity during the norming and storming phases. Hence, changing their composition is a critical decision that shall include the team members. Scrum teams are no ‘talent pools’ in disguise at the disposal of line managers.)
  • Line managers add members to the Scrum Team without prior consultation of the team members. (Preferably, the Scrum Team members should decide who joins the team, see above.)
  • Stakeholders or managers turn the Daily Scrum into a reporting session. (This behavior will impede the Developer’s productivity by undermining their self-management while reintroducing command & control through the backdoor.)

Product Backlog and Refinement Anti-Patterns

These stakeholder anti-patterns result from ignoring the role of the Product Owner, turning them into a scribe. Two important anti-patterns of this kind are:

• Requirements handed down: The Product Owner creates Product Backlog items by breaking down requirement documents received from stakeholders into smaller chunks. (That scenario helped to coin the nickname “ticket monkey” for the Product Owner. Remember: Refining Product Backlog items is a team exercise. Moreover, using practices like user stories templates helps everyone understand the Why, the What, and the How. Remember Karl Popper: “Always remember that it is impossible to speak in such a way that you cannot be misunderstood.”)
• Prioritization by proxy: A single stakeholder or a committee of stakeholders prioritizes the Product Backlog. (The strength of Scrum is building on the solid position of the Product Owner. The Product Owner is the only person to decide what tasks become Product Backlog items. Hence, the Product Owner also decides on ordering the Product Backlog. Take away that empowerment, and Scrum turns into a pretty powerful waterfall 2.0 process.)

The Daily Scrum

Most anti-patterns in this category result from perceived information needs — think of them as withdrawal symptoms:

• Status report: The Daily Scrum is a status report meeting, and the Developers are waiting in line to “report” progress to a stakeholder. (The “three Daily Scrum questions” often serve as a template for this anti-pattern.)
• Direct assignment of tasks: A stakeholder assigns tasks directly to a Developer. (It is the prerogative of the Developers to pick all work they deem necessary to accomplish the Sprint Goal during the Sprint Planning. No one is authorized to increase the Developers’ workload by assigning new tasks to them.)
• Command & control by the management: Line managers are attending the Daily Scrum to gather “performance data” on individual team members. (This behavior is defying the very purpose of self-managing teams.)
• "A word, please”: Line managers are waiting until the Daily Scrum is over and then reach out to individual Developers for specific reporting from them. (Nice try. However, this hack is also unwanted behavior and distracts the Developers.)
• Talkative chickens: “Chickens” actively participate in the Daily Scrum. (Stakeholders are supposed to listen in but not distract the Developers members during their inspection of the progress towards the Sprint Goal.)
• Communicating via body language: Formally, stakeholders remain silent. However, they participate in the Daily Scrum via their body language. (Again, stakeholders are supposed to listen in but not distract the Developers. Yet rolling eyes and face-palming are as powerful as the spoken word. Moreover, even subtle forms of body language represent communication, as one cannot “not communicate.” Furthermore, some stakeholders may have a naturally intimidating presence that can prove harmful to the communication among the Developers.)

Sprint Planning Anti-patterns of Stakeholders

Forecast imposed: The Sprint forecast is not a team-based decision. Or it is not free from outside influence. (There are several anti-patterns here. For example, an assertive Product Owner dominates the Developers by defining their scope of the forecast. Or a stakeholder points at the team’s previous velocity demanding to take on more user stories. (“We need to fill the free capacity.”) Or the ‘tech lead’ of the Developers makes a forecast on behalf of everyone else.)

The Sprint Review

Again, this category is often a combination of ignorance, fighting a perceived loss of control or pulling rank to override scrum principles:

• Scrum à la Stage-Gate®: The Sprint Review is a kind of Stage-Gate® approval process where stakeholders sign off features. (This Sprint Review anti-pattern is typical for organizations that use an “agile”-waterfall hybrid: there are some happy agile islands, for example, our Scrum team, surrounded by a sea of waterfall, driven by functional silos, budgeting, and top-down goal-setting. Still, in such a world, the Scrum team is tasked with accomplishing a Product Goal. Therefore, it is the prerogative of the Scrum Team to decide what to ship and when.)
• No stakeholders: Stakeholders do not attend the Sprint Review. (There are several reasons why stakeholders do not participate in the Sprint Review: they do not see any value in the event, or it is conflicting with another important meeting. In addition, they do not understand the importance of the Sprint Review event. No sponsor is participating in the Sprint Review, for example, from the C-level. To my experience, you need to “sell” the event within the organization, at least at the beginning of using Scrum.)
• No customers present: External stakeholders—also known as customers—do not attend the Sprint Review. (Break out of your organization’s echo chamber and invite some customers and users to your Sprint Review. And do not let the sales folks object to this idea. Ignoring the direct feedback from customers at the Sprint Review inevitably leads to a lesser outcome.)
• Starting over again: There is no continuity in the attendance of stakeholders. (Longevity is not just beneficial at the Scrum team level but also applies to stakeholder attendance. If they change too often, for example, because of a rotation scheme, their ability to provide in-depth feedback might be limited. If this pattern appears, the Scrum Team needs to improve how stakeholders understand the Sprint Review.)
• Passive stakeholders: The stakeholders are passive and unengaged. (That is simple to fix. Let the stakeholders drive the Sprint Review and put them at the helm. Or organize the Sprint Review as a science fair with several booths where team members introduce solutions to specific problems the Sprint addressed. Shift & Share is an excellent Liberating Structure microstructure for that purpose.)

The Sprint Retrospective

Here, it is mainly about control and line management issues:

• Stakeholder alert: Stakeholders participate in the Retrospective. (There are several opportunities in Scrum that address the communication and information needs of stakeholders: the Sprint Review, the Daily Scrum, probably even the Product Backlog refinement, not to mention opportunities of having a conversation at water coolers, over coffee, or during lunchtime. If that spectrum of possibilities is not sufficient, consider having additional meetings if your team deems them necessary. For example, there is the opportunity to have a meta-level Retrospective, explicitly including the Scrum team’s stakeholders. However, the Retrospective as a Scrum team-internal event is off-limits to stakeholders.)
• Line managers present: Line managers regularly participate in Retrospectives. (This is among the worst Sprint Retrospective anti-patterns I can imagine. It turns the Retrospective into an unsafe place. And who would expect that an unsafe place would trigger an open discussion among the team members? Any line manager who insists on such a proceeding signals their lack of understanding of basic Scrum practices.
• Let us see your minutes: Someone from the organization — outside the Scrum team — requires access to the Retrospective minutes. (This is almost as bad as line managers who want to participate in a Retrospective. But, of course, this information is solely available to team members.)

Scrum Stakeholder Anti-Patterns — Conclusion

There are many different reasons why Scrum stakeholders do not act in line with agile principles. Some result from organizational debt, particularly in legacy organizations from the industrial area. Some are intrinsically motivated, for example, by personal agendas, while others originate from a lack of training or anxieties. Whatever the reason, Scrum stakeholder anti-patterns need to be overcome to turn an agile transformation into a success. Otherwise, you might end up in some form of cargo-cult agile or Scrumbut.

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

📖 Related Posts

A Sprint Review without Stakeholders — Making Your Scrum Work #3

Product Discovery Anti-Patterns Leading to Failure

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.

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

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 Scrum Stakeholder 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.