Scrum Anti-Patterns: Micromanagement

A design pattern is a description of a solution to a recurring problem. It outlines the elements that are necessary to solve the challenge without prompting the reader to address the issue in a specific way.

Unfortunately, we also regularly see recurring patterns of ineffective behaviour. These are called Anti-Patterns.

The following is an exploration of one of the most common Anti-Patterns: Micromanagement.

Anti-Pattern^[1] Name: Micromanagement

Aliases: Over-Controlling; Someone is Looking over My Shoulder

Scale: Team and/or across multiple teams

Related Anti-Patterns: Sprint Burndown Charts, Velocity is Important, Time Tracking, Individual Incentives

Potential Solutions:

• Service or Servant Leadership
• Sprint as a Black Box
• Focus on Outcomes, not Output
• Leadership Focuses on Strategy and Creating an Effective Work Environment

Why Micromanagement Happens

People new to Scrum often struggle to understand boundaries of control between being an effective manager, ScrumMaster, or Product Owner. This is a critical consideration because, at the heart of Scrum, we’re attempting to grow a group of people into a resilient, high-performing team. These roles are not only relevant in facilitating this growth but are equally capable of stunting it. A key ingredient is allowing self-organization of the group to flourish.

Whether you’re a ScrumMaster or manager, when you see something potentially going wrong, you want to help. This is understandable: you have the best of intentions. You don’t think you’re micromanaging; just making suggestions, offering help and ideas, and avoiding risk. However, micromanagement can take many forms. Executives might make suggestions or give orders directly to Team members. Stakeholders might dictate User Stories to a Product Owner. Managers might insist on things being done a certain way because they’ve been done that way a hundred times before. The list goes on, but they all share a common feature: someone other than the people doing the work is trying to influence how the work ought to be done.

There are many ways micromanagement can show up in a Scrum environment. Below, I’ve outlined some common ones,  by role:

The ScrumMaster as a Micromanager:

• Assigns work to Team members instead of encouraging them to self-organize. This is more likely when the ScrumMaster is given the dual role of ScrumMaster and Project Manager.
• Runs Daily Scrum instead of facilitating the Team as they conduct the meeting.
• Turns Daily Scrum into a status-reporting event as opposed to an activity to prepare for the day’s collaboration.
• Injects their own thoughts and ideas into the Retrospective.
• Tells Team members how to do their job.
• Tells Team members how to solve problems when doing so harms the ability of the Team to find their own solutions.
• Tells Team members what the problems are instead of helping them discover them on their own.

The Product Owner as a Micromanager:

• Adds new work mid-Sprint and demands that it be done immediately. Management sometimes does this too.
• Attends Daily Scrum to get a status update. Daily Scrum is for the Team to help them collaborate and focus for the day. If the Team invites the Product Owner, the Product Owner must remember that and not interfere.
• Uses Daily Scrum as an opportunity to interrogate the Team about their work.
• Looks over Team members’ shoulders, checking in on every last detail. A good Product Owner helps to grow the Team to be empowered and make most of the small decisions on their own.

Management and other Stakeholders as Micromanagers:

• Attends Daily Scrum and injects their own ideas, calling them “suggestions.” Most suggestions from Management are automatically seen as orders.
  • Even having management present at Daily Scrum will cause people to turn the event into a status-reporting event. Instead of looking at each other, Team members naturally make eye contact with the manager. At that point, the Daily Scrum becomes about the manager and not the Team.
  • Suggestions from managers, especially executives, are often taken as orders because these same people control a Team member’s performance review, salary increase, and long-term employment status. Naturally, Team members will seek to please those who hold power.
• Asks the ScrumMaster for frequent updates on progress mid-Sprint.
• Uses the Sprint Burndown chart as a tool to investigate the progress of the Team during the Sprint.
• Looks at the Burndown/Burnup/Cumulative Flow Diagram as a measure of progress, rather than using these as predictive tools to see which items in the Product Backlog will get done.
• Asks for more velocity or demands the Team go faster. Teams often eventually go faster, but only by focusing on improving their skills and quality of their work.
• Tells people how to do their work.
• Dictates User Stories to the Product Owner.
• Treats the ScrumMaster as an errand-runner.

In the end, all of these boil down to the same basic set of problems: a misguided need or desire to help by exerting control, often founded on a belief that the person telling knows how to do something better than the person doing the work,^[2] and the feeling of being out of control themselves.

We all do some of these things on occasion, so don’t berate yourself if you have. It’s normal human behaviour, but it is problematic when it becomes a recurring and defining part of your management style.

Consequences of Micromanagement

In the last few years, several models for understanding human behaviour in modern work environments have appeared. The authors, and the framework they created to reflect their research, are:

– Dan Pink – Autonomy, Mastery, and Purpose^[3]

– Susan Fowler – Autonomy, Relatedness, and Competence^[4]

– David Rock – Status Certainty, Autonomy, Relatedness, and Fairness^[5]

Notice how autonomy is at the core of all of the research? Each of them report that people need to have freedom and independence to be able to do their best work. I can also say it is no coincidence that Autonomy, along with Engagement and Self-Organization, is also at the heart of Scrum. These aspects are all undermined when micromanagement is allowed to pervade.

To illustrate how individual effects of micromanagement can lead to larger, self-perpetuating negative consequences, we offer a simple Causal Loop Diagram (CLD) for each, and then a more comprehensive master CLD at the end. To try to keep it as simple as possible, we won’t repeat connections in the smaller CLDs, but you will see the overall effects and connections in the master.

Micromanagement leads to:

A) Disengagement of Team members
Worldwide, 67% of employees are disengaged.^[6] They show up to work because they’re paid, not because they care about or enjoy their work. Disengaged people will still do their jobs, but generally aren’t putting much energy into product or process improvement, and they’re certainly not willing to experiment and fail. When there are enough of them in one place, they kill off the energy of others with their zombie-like behaviours. In extreme cases, actively disengaged employees can become destructive.^[7] In 2017, 18% of employed people worldwide were actively disengaged. These people aren’t just bored or unhappy, they’re actively resentful and undermine the works of others.

Disengagement is often engendered when a manager (or ScrumMaster or Product Owner for that matter) finds themselves pressured to work faster. Often, they feel the easiest way to increase work speed is to look at the Team’s work and find a way to “help them.” This “help” almost always impinges on the Team’s autonomy and damages Team members’ engagement with the work at hand. As the Team becomes less engaged, the quality and quantity of work drops, illustrated in the Causal Loop Diagram below by the reduction in Customer Happiness. Unsurprisingly, as Customer Happiness is reduced, it leads to more external pressure on management to work faster.

B) Reduction in Self-Organization
Without autonomy and self-organization, the Team’s capacity is reduced and opportunities for them to experiment, fail, and learn from that experience disappears.

C) Delays in Decision-Making
Delays in decisions will begin to occur because the micromanager causes a bottleneck because Team members will often be afraid to make a decision without the micromanager’s support, agreement or, worse, sign off. So instead, they wait, sometimes making things even worse by doing work that merely keeps them busy instead of the most important work of delivering value to the customer.

These delays obviously harm productivity and customer outcomes, which leads to more pressure to adapt and recover from these building losses. However, these same delays mean that micromanaged groups can’t adapt to changing circumstances fast enough, often making the whole situation worse. This is another negatively reinforcing feedback loop.

The more the manager tries to take control, the more decisions they must make. The more decisions, the longer each decision must wait to be made. As decision time increases, Team members will do lower-priority work while they wait. They don’t want to start something important after all, because if the decision for the original problem arrives, they will have to drop whatever they are doing to attend to the new work. Both delayed decisions and low-priority work mean that less is done to delight the customer.

D) Limited Communication within the Team
As micromanagement increases and the Team increasingly needs the decision-maker before anything can progress, there is less need to talk to your peers, since there is a diminishing number of things to talk about. As a result, Knowledge Silos, prevalent in waterfall-style work, creep in, or possibly never go away in the first place. Additionally, this reduction in communication harms quality by reducing the diversity of thought available for tackling different problems. Siloed micromanagers also harm decision quality directly because they generally don’t seek opinions other than their own.

These problems are often made worse in places where functional managers have a say in who does what kind of work. For example, a functional manager responsible for Quality Assurance (QA) might suggest that only QA people can create and run test cases. This arbitrary and artificial wall prevents other Team members from cross-skilling and learning how to test, which could contribute to better quality work or a faster delivery rate. Functional managers, as a feature of their position, tend to have a vested interest in maintaining personal empires, so they work to ensure that boundaries and barriers stay up. Ultimately, in a healthy Agile work environment, there shouldn’t be a need for functional managers, and they should instead redefine their role to more positively contribute to the growth and autonomy of the teams they oversee.

These Silos subsequently increase the need for heroism since fewer people can only do certain kinds of work. These “heroes” ultimately harm self-organization and often work quality, coming under increasing pressure to work faster while being unable to seek help from their own Team. (We’ve not displayed quality on the diagram above because it was already getting too busy – instead, poor quality is just a subset of what makes customers unhappy).

Finally, reduced communication also harms the ability to experiment, innovate and learn from failure, hampering any hope of improving.

Micromanaging anti-pattern CLD (Causal Loop Diagram)

If the above looks bloody complicated, that’s… well, because it is. Human beings are complicated, and trying to herd large groups of us into doing complex work is especially challenging. Trying to do all that with micromanagers is mind-bogglingly convoluted.

Typical Causes of Micromanagement

• Matrixed organizations or Functional Managers – which tends to be exhibited by maintaining separate functional teams apart from the Scrum Team
• Individual rewards that promote heroism, increase the size of knowledge silos, and harm self-organization of teams
• A belief that one person knows better than another, which is closely related to…
• A belief that you can better control outcomes by controlling people. This is a delayed negatively reinforcing feedback loop because in every case, these behaviours harm the quality of work and therefore, harm the customer happiness. This is hard to see on a day-to-day basis because the negative effects on the customer are usually delayed. After all, the customer only notices they’re getting poorer-quality work sometime after it has been delivered.
• When one person feels micromanaged they will often react by applying that same degree of control to others. Unfortunately, this also is a negatively reinforcing feedback loop.

Solutions for Micromanagement

• Insulate the team from some of the above-mentioned dynamics:
  • Make the Sprint a Black Box – Explain to stakeholders that once the Sprint has started, the Team needs space to succeed
  • Don’t track or display the Sprint Burndown chart – Too often the Sprint Burndown is used by those outside the Team to ask the question “Why aren’t you going faster?”
  • If the official electronic tool is used to spy on the Team in Sprint, then the Team might consider using something outside of that tool for the Sprint Backlog. (e.g. Index cards).
  • If the Product Owner is micromanaging during Daily Scrum, the ScrumMaster should suggest that they not attend until the relationship is improved.
  • Suspend individual rewards for members of your Scrum Teams. (This is a short avoidance, not a fix. Ultimately, individual rewards should end.)
• Instead of giving managers one number for team velocity, always use ranges with probabilities. I usually recommend giving three numbers: 20, 50 and 80% confidence intervals.
• Never allow the Release Burndown and other charts to be viewed without also providing the context of the Product Backlog – move the conversation away from how much faster can you go, to which items can be done by the end of the Sprint.
• Renegotiate the relationship between managers and Development Team members.
• Reinforce Working Agreements between Development Team, ScrumMaster and Product Owner so that all have a good understanding of their boundaries.
• Educate managers that a “request” from management will be seen as a requirement by many Development Team members.
• Educate managers that attending Daily Scrum on a regular basis sends the Development Team a signal that they need adult supervision. Management are best involved at the Sprint Review.
• Work on Cross-Skilling to breakdown silos within a Team and the organization at large.
• Eliminate individual rewards. Even better, replace the annual performance^[8] reviews entirely and move to a continuous feedback model.
• Have organizational leaders focus on outcomes, not the details of the work or how the Team does the work.
• The further up the organizational ladder a leader is, the further into the future they should be encouraged to be looking for long-term strategy.
• Seek to understand the sources of pressure that are being placed on various managers and stakeholders, so that their Scrum Teams, Agile Coaches – one tool to help model this is Systems Thinking. Once we understand the pressure, then we can seek to change the circumstances to reduce/eliminate the pressure.

Mark Levison

Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.