Agile thinking emphasizes self-organization and personal initiative. We want these active in our organizations. However, when this emphasis is taken to an extreme it can imply that there is no place for managers. Some Agile leaders have even said this explicitly.

Lean-Agile, however, says that management and especially middle management has an important role in Agile. It becomes a force-multiplier for organizations in mid- and large-scale organizations. This article describes what middle management can do and how it benefits the Agile organization.

Main Points

• Lean-Agile middle management differs from traditional middle management
• Middle management acts differently within an Agile organization and brings benefits.
• Middle managers facilitate Lean-Agile feedback loops.

Middle Managers as Heroes in the Agile Story

Middle managers are receiving some long-overdue attention in Agile circles. Middle managers have always played a role in Agile transformations. The unkind stereotype depicts middle managers as something like the boss in Office Space, a sinister, disconnected figure who contributes little, but interferes a lot. While I’ve seen some middle managers substantially undermine Agile teams, I’ve also seen others who were genuine supporters. In a few cases, they’ve been the heroes in an organization’s Agile story. When middle managers get in the way of Agile, the reasons are usually anxiety. Do I have a job, now that the team is self-organizing? is a common refrain.

Unfortunately, invoking Agile practices and principles — These are the things that the team should be doing, so get over it — isn’t enough. Most middle managers have been focused on directing their employees, and Agile tells them to stop doing that. Oh, and since only the team attends the retrospectives, don’t let the door hit you on the way out. There’s nothing comforting about getting the bum’s rush.

Managers Eat (FR)OODA Loops for Breakfast

Middle managers can play a constructive role vis a vis Agile teams, but it’s not the directive role to which most of them are accustomed. Habit is a powerful force, however, so managers need something that helps them understand why seemingly innocuous interventions, such assigning work items to particular team members, or mandating a tried-and-true approach to fixing a problem, can be highly disruptive and even destructive. While these details might help managers understand what they should not be doing, they also need specifics about what they should be doing. Exhortations to “Support the team” are too vague, particularly for people worried about their jobs.

Feedback loops provide the answer to both questions. When managers direct teams, they often make themselves the feedback loop. (“I see the problem, and my experience tells me the solution they need to follow.”) Managers need to step back and let teams take responsibility for the feedback loops, and provide critical help when the loops are not operating as well as they should.

Unfortunately, the term “feedback loops” is vague. One person might think that collecting any information is sufficient. Another person might say that without a response, there’s no feedback at all. (Think of those millions of “We value your suggestions!” forms that wind up in the electronic mulch pile.) Teams and managers need a definition of feedback loops, one that gives a better picture of the advantages of team self-direction, and the instances when managerial intervention might be useful.

The OODA loop provides that picture. While the OODA loop was originally designed to explain how to become a better fighter pilot, it quickly found a home in discussions about business models, management practices, and other domains. The OODA loop breaks down any feedback-and-response process into four components:

 

 

Someone needs to move through all four steps for the feedback loop to be complete. That “someone” should be, by default, the team, since they are closest to the action. Otherwise, each step will take longer, and the risk of information loss is much higher.

Case in point: One of the most dangerous errors that IT departments make is blocking the team from the customer. For internal political reasons, the team either interacts with these customers in rare moments, such as demos, or not at all. Intermediaries are supposed to proxy for the people using the software, but they often don’t understand their clientèle. A hospital administrator, for example, is unlikely to be a good proxy for doctors and nurses. If only the team could talk to some doctors and nurses directly, the team would be far more successful at observing these customers, orienting towards ways of supporting their work, deciding on particular designs and priorities, and acting on those decisions.

Value-stream mapping (VSM) can add dramatic detail. How long does it take for the team to detect a bug? How long does it take to determine its origins and severity? Are there delays in deciding when and how to address the bug? A simple VSM exercise can generate some key insights into the real state of feedback loops.

Once middle managers see how the OODA loop works, they can understand how, with even the best intentions, they may inadvertently disrupt its operation within teams. For example, the busy manager who wants to be part of decisions to re-prioritize stories is prolonging the decide part of the OODA loop, delaying the act portion, and may be missing important context from the observe and orient segments. The same busy manager who says, “I’ve seen this kind of bug before, and here’s how you fix it,” short-circuits the investigation into the reasons behind the bug (observe and orient), increasing the risk of applying the wrong “fix.”

The OODA loop also delineates how middle managers can play a more positive role. Yes, teams are central to Agile. Yes, teams should be ultimately responsible for building good feedback loops. No, they don’t always live up to that standard. Sitting outside the team, managers sometimes have a perspective that the team lacks. The OODA loop gives the manager a way of diagnosing these problems, then working with the teams on fixing them.

Technical debt often sabotages feedback loops at the team level. In theory, technical debt should be just another topic for continuous improvement, since it undermines velocity, impairs self-organization, lowers team morale, and plays havoc with estimation and plans. Therefore, teams should be finding, fixing, and finishing technical debt on an ongoing without any difficulty or drama.

 

In reality, teams often find themselves in a technical debt trap. The gradual accumulation of technical debt quietly consumes time that might otherwise be spent on better things. Without realizing it, the team gets into a situation where it feels it has no time to assess technical debt, or take any corrective measures. Teams sometimes get into a state of denial when technical debt reaches this level, refusing to admit there is a serious problem. The causal connection between technical debt is not a completely straight line, so the team might not be even aware that technical debt may be at the source of their woes. I’ve also seen technical debt exacerbate dysfunctional relationships within the team, further deepening the crisis. In one case, a senior developer grew increasingly defensive about the topic, blaming unmet sprint commitments on the other team members’ lack of skills, not his own cavalier way of writing code. What should have been a mundane discussion about refactoring instead turned into bitter personal recriminations.

 

Fortunately, experienced managers sitting outside the team can see technical debt creating these patterns emerging, and help the team grapple with them more effectively. The OODA loop provides a better starting point for discussion than a directive to, “Just go an clean up the code.”

• Observe. Is the team aware of the current level of technical debt? If the problem is not, there are several ways a manager can make the team aware of the importance of measuring it. One development manager of my acquaintance made education about technical debt a priority for one-on-one discussions with engineers who worked for him. He also offered to help the team implement a static code analysis tool.
• Orient. Is the team not recognizing the impact of technical debt? Again, a manager can provide some important coaching. Teams may not be aware that there are models for how to assess the impact, such as A2DAM.
• Decide. Is the team nervous about taking steps that might reduce technical debt in the long term, but take time away from implementing stories in the short term? If so, managers can provide top cover for teams worried about the potential backlash from customers or stakeholders.
• Act. Did the team stop dealing with technical debt, after taking some small steps in dealing with the problem? The manager can encourage the team to treat technical debt reduction as an ongoing campaign, not a one-time affair. Fix, assess, fix some more, assess again — the manager can help the team see that further action is likely to be necessary.

Subtly, the OODA loop in this example has positioned managers where they need to be in an Agile organization:

• Advice. They have an important part to play as trusted advisors, based on their greater objectivity and experience.
• Material support. Managers can help get resources needed to respond to whatever the feedback loop reveals.
• Diplomacy. They can smooth relations between the team and the rest of the organization.
• Investigation. Managers can research questions, such as the most current techniques and tools for dealing with technical debt, that the time may not have time to pursue.
• Professional development. As managers, they also have the opportunity to provide training and mentoring to team members.

By seeing their job as supporting the OODA loop, not supplanting it, managers can understand that losing the directive part of their role is not a fatal blow to their careers. Instead, life in an Agile organization allows them to focus on the other activities that managers should be pursuing.