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 which easily can impede any agile transition.
Do you want to get this article in your inbox? You can sign up here and join 25k other subscribers.
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. InfoQ’s recent ‘Culture & Methods – the State of Practice in 2019’ edition found that new converts to Scrum, for example, will recruit themselves mostly from the late majority and laggards. (The early majority of organizations are already adopting BDD/DDD or Pragmatic Agility.)
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, 2019. 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 in trusting those closest to the problem to come up with a solution,
- From ‘failure is no option’ to embracing 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 transition may provide job security, but most certainly not role security is a monumental undertaking for the majority of the management of a legacy organization. Probably, many of these managers will not adapt and even quit the organization sooner or later.
Common Scrum Stakeholder Anti-Patterns
After defining the context, let us consider some Scrum stakeholder anti-patterns in detail. Most often, Scrum stakeholder anti-patterns result from a training and coaching void accompanied by not changing individual career objectives. Thus, they manifest themselves in the continued pursuit of local optima or personal agendas. In both situations, the incentive structure of an organization most likely still fosters a predictable 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 Scrum events, system-related issues as well as issues of individual players.
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-organizing teams:
- Pitching developers: The stakeholders try to sneak in small tasks by pitching them directly to developers, bypassing the Product Owner. (Nice try #1.)
- Everything’s a bug: The stakeholders try to speed up delivery by relabeling their tasks are ‘serious bugs.’ (Nice try #2. A special case is an “express lane” for bug fixes and other urgent issues. In my experience, every stakeholder will try and make his or her 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 flow of the team during a sprint. Any of the examples will impede the team’s productivity and might endanger the Sprint goal. The Scrum Master must prevent them from manifesting themselves:
- The Scrum Master has a laissez-faire policy as far as access to the Development team is concerned. Particularly, he or she is not educating stakeholders on the negative impact of disruptions and how those may endanger the accomplishment of the Sprint goal.
- The Scrum Master does not oppose line managers taking team members off the team assigning other tasks.
- The Scrum Master does not object that the management invites engineers to random meetings as subject matter experts.
- The Scrum Master turns a blind eye to mid-Sprint changes of priorities by the Product Owner.
- Lastly, the Scrum Master allows either stakeholders or managers to turn the Daily Scrum into a reporting session.
Product Backlog and Refinement Anti-Patterns
These stakeholder anti-patterns result from ignoring the role of the Product Owner, turning him or her into a mere scribe. Two important anti-patterns of this kind are:
- Requirements handed down: The Product Owner creates user stories 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: Product Backlog item creation is a Scrum Team exercise.)
- Prioritization by proxy: A single stakeholder or a committee of stakeholder prioritize the Product Backlog. (The strength of Scrum is building on the strong position of the Product Owner. The PO is the only person to decide what tasks become Product Backlog items. Moreover, the Product Owner also decides on the ordering of the Product Backlog. Take away that empowerment, and Scrum turns into a pretty robust 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 Development Team members are waiting in line to “report” progress to a stakeholder.
- Talkative chickens: “Chickens” actively participate in the Daily Scrum. (Stakeholders are supposed to listen in but not distract the Development Team members during their inspection.)
- 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-organizing teams.)
- “A word, please”: Stakeholders are waiting until the Daily Scrum is over and then reach out to individual Development Team members for specific reporting from them. (Nice try. However, this hack is also unwanted behavior and distracts the Development Team.)
- Direct assignment of tasks: A stakeholder assigns tasks directly to a Development Team member.
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 Development Team by defining its 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 Development Team is making a forecast on behalf of the Development Team.)
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. However, it is the prerogative of the Product Owner to decide what to ship 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. 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: External stakeholders—also known as customers—do not attend the Sprint Review. (Break out of your organization’s echo chamber, and invite some paying users to your Sprint Review.)
- Starting over again: There is no continuity in the attendance of stakeholders. (Longevity is not just beneficial at the 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. 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 still is not sufficient, consider having additional meetings if your team deems them necessary. However, the Retrospective is off-limits to stakeholders.)
- Let us see your minutes: Someone from the organization—outside the team—requires access to the retrospective minutes. (This is almost as bad as line managers who want to participate in a retrospective. Of course, the access must be denied to ensure that Scrum Team members will also point at critical issues in the future.)
Scrum Stakeholder Anti-Patterns at System Level
These anti-patterns result mainly from a half-hearted approach to becoming an agile organization. Typically, it ends in the 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-organizing.
- Lack of leadership: Senior management is not participating in agile processes, for example, the Sprint Reviews, despite being a role model. Instead, they do expect a different form of (push) reporting.
- 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 o 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 transition.
- 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 members of the organization.
- 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. Just let the people closest to the job at hand figure out how to do this. Guidance by objectives and providing support when requested or needed will be appreciated, though.
- Steering meetings: Unimpressed by the agile ways of working, the manager insists on continuing the bi-weekly steering meetings to ensure that the team will deliver all her requirements in time. This one has a quick remedy, though: just do not participate in meetings that have no value for the team.
- Limited to non-existing feedback loops: The sales organization and other functional silos guard the direct access to customers, thus preventing the product teams from learning.
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. Most likely, canceling Sprints and gathering the Scrum Teams would also solve the issue at hand.)
- 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 teams is hence essential. Moving people between teams, on the contrary, reflects a project-minded idea of management, rooted in utilization optimization at the team member level 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 rarely work if team members are pressed into service. Note: It is not an anti-pattern, though, if the Scrum Teams decide to exchange teammates temporarily. It is an established practice that specialists spread knowledge this way or mentor other colleagues.)
- Special forces: A manager assigns specific tasks directly to engineers, thus bypassing the Product Owner and ignoring the Development Team’s prerogative to self-organize. Alternatively, the manager removes an engineer 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. He or she continues to micromanage subordinates, although a Scrum Team could accomplish the task in a self-organized manner. 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 of how stakeholders can impede the progress of a product team. Four of the most common ones are as follows:
- The ‘My budget’ syndrome: Stakeholders do not compete for a Scrum Team capacity 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 particularly in organizations, that tie additional benefits to individuals. Instead, resources need to be allocated in the spirit of optimization for 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. (There are several reasons causing this phenomenon ranging from a founder or entrepreneur who pursues his or her product vision without engaging in customer discovery activities. Or the product delivery organization is solely briefed indirectly by key account managers. Probably, the sales department deems a direct contact of Scrum Team members with customers too risky and hence prevents it from happening. What these patterns share is 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 difficult to come by as the culprits typically reject the idea that they are guided by selfish motives. For becoming an effective product delivery organization it is essential that the team directly communicates with customers at a regular base.)
- 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 provide those to the product delivery organization as requirements. (The problem with customers is that they usually lack the depth of knowledge required to provide useful answers to this question. Most of the time, they also lack the level of abstract thinking necessary to come up with a 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 the reason why product-people 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 in the hope 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 demanded in more pressing fashion, typically four 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 value.)
For more information watch the webinar: Product Discovery Anti-patterns.
Scrum Stakeholder Anti-Patterns — Conclusion
There are a lot of different reasons why Scrum stakeholders do not act as expected. 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, though, Scrum stakeholder anti-patterns need to be overcome to turn an agile transition 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.
✋ Do Not Miss Out: Join the 6,900-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now 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.
Scrum Stakeholder Anti-Patterns — Related Posts
Download the Scrum Anti-Patterns Guide: 160-plus ways to improve your way of Scrum.