Scrum Stakeholder Anti-Patterns

— May 8, 2018

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.

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 recent ‘Engineering Culture and Methods InfoQ Trends Report – January 2018’ edition found that new converts to Scrum, for example, will recruit themselves most likely from the late majority and laggards. (The early majority of organizations is already adopting Lean, Kanban, and Scrum derivatives.)

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 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, 2018. 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 is 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 embracing failure as a means to learn fast,
• From claiming success as a personal contribution to stepping back and letting the responsible team shine.

Abandoning (May 12, 2018)’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.

A List of Scrum Stakeholder Anti-Patterns

After defining the context, let us consider 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 ceremonies, system related issues as well as issues of individual players.

Scrum Stakeholder Anti-Patterns at Scrum Ceremony Level

The Stand-up or Daily Scrum

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

• Status report: The stand-up is a status report meeting, and team members are waiting in line to “report” progress to the scrum master, the product owner, or maybe even a stakeholder
• Talkative chickens: “Chickens” actively participate in the stand-up. (I think it is acceptable if stakeholders ask a question during the stand-up. However, they are otherwise supposed to listen in merely.)
• Anti-agile: Line managers are attending stands-up to gather “performance data” on individual team members. (This behavior is defying the very purpose of self-organizing teams.)

The Sprint

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

• Directly pitching developers: The stakeholders try to sneak in small tasks by pitching them directly to developers. (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. Every stakeholder will try and make his or her tasks eligible for that express lane.)
• Disrupting the flow: The stakeholders disrupt the flow of the scrum team. (See above, scrum master section.)

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 anti-pattern is typical for organizations that use an agile-waterfall hybrid. Otherwise, it is the prerogative or 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 go to the sprint review: they do not see any value in the ceremony. 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. In my experience, you need to “sell” the ceremony within the organization.
• No customers: External stakeholders—also known as customers—do not attend the sprint review. (Break out of your organization’s filter bubble, and invite some paying users of your product.)
• Starting over again: There is no continuity in the attendance of stakeholders. (Longevity is not just a team issue, but also applies to stakeholders. If they change too often, for example, because of a rotation scheme, how can they provide in-depth feedback? If this pattern appears the 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.)

The Sprint Retrospective

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

• Line managers present: Line managers participate in retrospectives. (This is the worst anti-pattern I can think off. It turns the retrospective into an unsafe place. And who would expect that an unsafe place triggers an open discussion among the team members? Any line manager who insists on such a proceeding signals his or her lack of understanding of basic agile practices. Note: If you are small product delivery team at a start-up and your part-time scrum master (or product owner) also serves in a management function, retrospectives might be challenging. In this case, consider hiring an external scrum master to facilitate meaningful retrospectives.)
• 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.)
• Encore — no suitable venue: There is no adequate place available to run the retrospective. (The least appropriate place to have a retrospective is a meeting room with a rectangular table surrounded by chairs. And yet it is the most common venue to have a retrospective. Becoming agile requires space. If this space is not available, you should become creative and go somewhere else. If the weather is fine, grab your stickies and go outside. Or rent a suitable space somewhere else. If that is not working, for example, due to budget issues, remove at least the table so you can sit/stand in a circle. Just be creative.

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 teams are hindered to become self-organizing.
• Lack of leadership: Senior management is not participating in Agile processes, for example, the sprint demos, 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 scrum 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 and thus support of the agile transition.
• Agile light: The management abandons self-organization the moment a critical problem appears to form ‘task forces’ instead.
• 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 hands 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.

Personally Motivated Scrum Stakeholder Anti-Patterns

There are numerous ways 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 pitch for development resources 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 product team people 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.)

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 make an agile transition a success. Otherwise, you might end up in some form of cargo-cult agile.

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

Business & Finance Articles on Business 2 Community

(162)