Agile Management Anti-Patterns — An Introduction for Aspiring Servant Leaders

Agile Management Anti-Patterns

Agile Management Anti-Patterns — An Introduction for Aspiring Servant Leaders
via Blog by Stefan Wolpers

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.

Continue Reading