TL; DR: Agile Management Anti-Patterns
Learn more about agile management anti-patterns the aspiring servant leader should avoid during the organization’s transition: From applying the Stage-Gate® approach through the back door to the ‘where is my report’ attitude to other beloved signs of applied Taylorism.
Update 2020-09-05: I added new graphics and fixed content debt.
🗞 Do you want to get this article in your inbox in the future? You can sign up here for our weekly ‘Food of Agile Thought newsletter’ and join 29k other subscribers.
Agile Management Anti-Patterns in Learning Organizations
The following anti-patterns are a selection of expected behavior by traditional managers often found in organizations that have embarked on their transition journey, but not yet reach the destination of becoming a learning organization:
- “I have a certificate, too.” Managers should avoid mentioning this level of formal education in discussion with agile peers if they want to be taken seriously. While everyone will appreciate the effort, participating in a 2-day workshop does not mean that they mastered navigating the waters of dual-track Scrum, for example. Respect needs to be earned; managers do not get by rank.
- Using the budgeting process as a Stage-Gate® to exercise control through the back door: The budgeting process is hard to align with agile requirements like the longevity of teams. Hence, the actual process will have to change over time. However, it is a sign of mistrust, though, if the management uses the budget permanently as a means of controlling the teams, making them “pitch” every two months or so. There is absolutely nothing “agile” to be found in this practice. Instead, the management ought to provide the teams with goals and guidance on how to achieve these, along with funding sufficient to meet the objectives.
- The ‘where is my report’ mentality: The manager expects to receive reports regularly instead of participating in events, for example, the Sprint Reviews. A quick look at the Manifesto for Agile Software Development should help the manager, though: ‘Individuals and interactions over processes and tools’ is a core principle of all agile practices.
- 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 the requirements in time. This one has a quick remedy, though: Do not participate in meetings that have no value for the team.
- Team building without involving the team: The manager decides who is joining or leaving the team without involving the team itself in the decision process. Building a high performing team is not accomplished by moving FTEs from one spreadsheet to another. There is a reason why special forces, for example, put so much effort and time into the longevity of teams, and an agile organization should follow the example. The least the manager can do is involve the team in all decisions that may affect the team composition. Read More: “Peer Recruiting.”
- 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 managers probably did themselves. 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.
- Abandoning management all together: Interestingly, some managers seem to believe that self-organizing teams do not require any form of management anymore. Nothing could be further from the truth: There are always issues at an organizational level that teams love outsourcing to their management. If you like to figure out what that might be, give Management 3.0’s delegation poker a chance.
- Disrupting the flow: The manager disrupts the flow of the Scrum Team by inviting random team members to various meetings of little or no value, or by disrespecting time-boxes of Scrum events, or the Sprint itself. Scrum Master, you will need to intervene in this case.
Cannot see the subscription form?
Please click here
Management Anti-Patterns Regarding Scrum
If your organization uses Scrum as a part of the product delivery process, there are various scrum specific management anti-patterns. (Please note that managers and internal stakeholders tend to overlap functionally and are often used in this context synonymously.)
General Agile Software Development Anti-Patterns
These anti-patterns show tendencies to overrule Scrum as a ‘fine weather sailing’ exercise:
- 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 Scrum 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. Also, for very experienced Scrum Teams, dynamic reteaming might be an option worth pursuing.)
- 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.)
- Hardening sprints: While the idea of continuous delivery is to permanently provide more value to customers by frequently shipping new code, it is acceptable to continue thinking in releases. There may be legal reasons for that, or customer care and sales need to be thoroughly trained in advance, or the customers prefer it this way. What is not acceptable in an agile engineering organization, though, is preserving QA as a separate, siloed entity that demands time for end-to-end testing before releasing any new code. That is true cargo cult agile. Instead, move the QA engineers into the Scrum Teams and focus on test automation and other well-established CD practices.
Daily Scrum Anti-Patterns of the Agile Manager
The Daily Scrum is a simple yet essential event for the Development Team and can easily fall victim to agile management anti-patterns:
- Reporting session: The manager expects that everyone delivers a sort of status report. The anti-pattern has an advanced version: the manager “runs” the Daily Scrum, signaling the team members when it is their turn to speak.
- Talkative chickens: By definition, the manager is a “chicken,” and chickens are supposed to listen in. Actively participating in Daily Scrums is reserved for Development Team members. (It may be acceptable if managers ask a question once in a while during the stand-up, though. Beyond that, they can talk to the Product Owner or Scrum Master, and why not visit the Sprint Review regularly?)
- Anti-agile: Line managers are attending Daily Scrums to gather “performance data” on individual team members. (Do not be surprised to find them thinking in the story-points-per-developer “performance” category as well.)
Agile Management Anti-Patterns: The Sprint
Multiple attempts—conscious or not—come to mind how managers try to bypass Scrum principles, for example, by ignoring the nature of the Sprint Backlog such as:
- 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 particular 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.)
Agile Management Anti-Patterns: The Sprint Review
It does not take a lot for managers to derail the Scrum Team’s motivation in the most critical Scrum event — the Sprint Review. Watch out for the following agile management anti-patterns:
- 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 managers in the trenches: 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.)
- 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.)
Sprint Retrospective Anti-Patterns of the (Line) Management
While managers are not supposed to participate in Sprint Retrospectives, they might nevertheless negatively influence those. These three agile management anti-patterns about Scrum that are notable:
- Line managers are present: Line managers participate in Sprint Retrospectives. (This is the worst anti-pattern I can think of regarding the topic of this article. 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 their lack of understanding of basic agile practices. Note: If you are a 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 at least 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 to ensure that Scrum Team members will also point at critical issues in the future.)
- 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. Read More: Agile Workspace: The Undervalued Success Factor.)
Conclusion
There are numerous agile anti-patterns of typical managers, covering the whole range from mindset to processes. While the latter can be fixed by providing training and coaching continuously, the former is not trivial to address. While some die-hard command and control-minded managers will never make the transition, others may have a chance to change their perspective from ‘how do I make my superior happy’ to ‘how can I make my team successful.’
What agile management anti-patterns have you observed? Please share it with us in the comments.
✋ Do Not Miss Out: Join the 8,000-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, 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.
📖 Related Posts
I recommend the following additional articles on agile management anti-patterns:
Agile Failure Patterns In Organizations
Why Agile Turns into Micromanagement
27 Sprint Anti-Patterns Holding Back Scrum Teams/a>
15 Sprint Review Anti-Patterns Holding Back Scrum Teams
📅 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.
