TL;DR: Agile Management Anti-Patterns
Learn more about Agile management anti-patterns the aspiring Agile manager should avoid during the organization’s transition. From stage-gate through the back door to the ‘where is my report’ attitude.
Agile Management Anti-Patterns in Learning Organizations
The following anti-patterns are a selection of common behavior by traditional managers often found in organizations that haven’t yet managed to become (fully) Agile:
- “I am a CSM, too.” A manager should avoid mentioning this level of formal education in discussion with Agile peers if they want to be taking 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 Agile. Respect needs to be earned; it is not delivered 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 original 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 that is sufficient to meet the objectives.
- The ‘where is my report’ mentality: The manager expects to receive reports regularly instead of participating in ceremonies, for example, the stand-ups or 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: just 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 any 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 work groups in the art of assembling a Model T—which the manager probably did. 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.
- 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 want 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 ceremonies, or the Sprint itself. Scrum Master, you will need to intervene in this case.
Agile Management Anti-Patterns for 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 ‘fair 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 and 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 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. It also ignores the preferred team building practice that Scrum teams should find 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 two 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. 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 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 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 fine 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.
Agile Management Anti-Patterns: The Stand-Up
The Daily Scrum is a simple ceremony, and yet it can be abused in various ways by managers:
- Reporting session: The manager expects that everyone delivers a sort of status report. The anti-pattern has an advanced version: the manager “runs” the stand-up, 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 stand-ups is reserved for team members. (It is acceptable if managers ask a question during the stand-up, though. Beyond that they can talk at any time to the product owner or Scrum Master.)
- Anti-Agile: Line managers are attending stands-up 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
There are also attempts to bypass Scrum principles, for example, by ignoring the nature of the Sprint backlog such as:
- Pitching developers: The manager tries to sneak in small tasks by pitching them directly to developers, thus ignoring the product owner as well as basic Scrum principles.
- Everything’s a bug philosophy: The manager tries to speed up delivery of certain features by relabeling tasks as ‘serious bugs.’ (A special case is an “express lane” for bug fixes and other urgent issues. Every manager 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 important Scrum ceremony — the Sprint review. Watch out for the following anti-patterns:
- Scrum à la stage-gate: The Sprint review is a kind of stage-gate approval process where managers 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 and when.)
- No manager in the trenches: Managers do not attend the Sprint review. (There are several reasons why managers do not attend 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. None of the sponsors are participating in the Sprint review, for example, from the C-level. To my experience, you need to “sell” the ceremony within the organization to successfully transition to an Agile organization.)
- Starting over again: There is no continuity in the attendance of managers. (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 managers understand the Sprint review.)
- Passive managers: The managers are passive and unengaged. (That is simple to fix. Let the managers drive the Sprint review and put them at the helm. Or organize the Sprint review as a science fair with several booths.)
Agile Management Anti-Patterns: The Retrospective
While managers are not supposed to participate in retrospectives, they might nevertheless negatively influence those. These are the three Agile management anti-patterns about Scrum that are notable:
- Line managers are 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 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 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 need be denied as retrospectives are a safe place.)
- 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 post-its 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.
Conclusion: Agile Management Anti-Patterns
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 more successful.’
What management anti-patterns have you observed? Please share with us in the comments.