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. To explore the topic more deeply, please see this growing collection of articles. 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. Hint: words like Tell/Assign/Should are good warning signs that micromanagement is happening! 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 […]
↧