Where I Think “Agile” is Headed, Part 2: Where Does Management Fit?

In Part 1, I wrote about how “Agile” is not a silver bullet and is not right for every team and every product. This post is about how management fits into agile approaches.

Too often, managers think “agile” is for others, specifically teams of people. Teams need to figure out how to manage their WIP, collaborate with the customer, and deliver something small every day.

Team-based “agile” is not enough. If the managers don't change their behaviors, a team cannot sustain any agile approach.

Every agile approach requires that the team learn how to manage their work and their interactions. The team decides how to solve problems. The team decides what, when, and how to deliver (guided by customer value decisions for the when).

That's a cultural change to self-managing teams. That's why we need managers to understand how to create and cultivate an agile culture.

Managers Create and Refine the Culture

When I talk about culture, I mean the ideas from Edgar Schein's work about organizational culture and leadership:

  • How we treat each other
  • What we can discuss
  • What and how we reward people

(Schein goes into more detail and if you're interested in management, I encourage you to read his work.)

The more management wants to standardize on any agile approach, or add control or synchronization points, or require another group/team to deploy, the more management creates local optimization. And, the more management removes the possibility of self-management. Local optimizations create bottlenecks and prevent fast change.

(Aside: I wonder if any management team that wants to standardize actually needs an agile approach? I suspect they don't have problems that require an agile approach.)

Instead of local optimization, we need global optimization: How can we decrease the time of all the various feedback loops?

The biggest problem I see in feedback loops is when managers think in resource efficiency instead of flow efficiency.

Flow Efficiency Changes the Culture

When I work with managers and executive teams, they often ask me about how to help the teams be more agile.

I ask them these questions:

  • When do you need to exchange information with your peers so the teams can succeed?
  • What is your decision cycle time?
  • What is each team's cycle time? Does their cycle time increase or decrease the various feedback loop times?

Too many managers don't know the answers to these questions. These questions aren't specific to any given team's agile approach. These questions are about collaboration across and up/down the organization.

When we work in flow efficiency at all levels, we decrease bottlenecks, decrease decision time, and increase the resilience of the organization. (If you haven't read the flow efficiency series, start with Part 1.)

When managers encourage teamwork, the managers encourage a corporate (or division-wide) optimization. Not person-based optimization, but optimization for the products/services that the organization needs.

Now, imagine that every level of the organization acts as a team. What might happen to the various cycle times? Managers make decisions faster. Everyone's cycle time decreases. The feedback loops get shorter. The organization creates resilience because there's less waiting everywhere.

When we think in flow efficiency, we change what we discuss, how we treat each other, and especially, what the organization rewards.

When managers create and refine an agile culture, they stop thinking about people-as-resources and divide-and-conquer for the people and the team. And, they stop thinking that inventory is a good idea.

How Do Your Managers Act?

Cultural change does not arise from a change of beliefs. Cultural change arises from changed actions.

If your managers still manage via Theory X (McGregor), instead of Theory Y, you cannot create an agile transformation and have it stick. It doesn't matter which agile approach. If you manage via Theory X, no agile approach will stick over the long term.

This table contrasting Theory X and Theory Y shows the difference between the management assumptions. Management assumptions drive actions.

This is why managers need to decide what they want. If they want the benefits of a collaborative, flow-based approach where everyone can use an agile approach, they need to act as if they believe in Theory Y. (They don't have to believe to start. They need to act as if they believe in Y.) If they act according to Theory X, any agile approach will not work.

That why this question matters for managers:

How much resilience do you need in the organization?

There is no one right answer. I have found this continuum helpful to guide my thinking.

If you don't need a lot of resilience, and if you don't have problems that require a lot of innovation, you can continue to use Theory X behaviors. The more Theory X behaviors I see, the less transformation I see. It's possible you are different.

However, if you require product innovation and you need resilience in the organization so you can change more often, you need Theory Y behaviors.

What Agile Managers Might Do

Here are actions you might consider:

  • Talk about people instead of resources. Too many managers have been trained to talk about “resources” instead of humans.  That's wrong. It's always been wrong. If you persist in using “resource” instead of humans, you allow the language of the balance sheet to drive your management decisions.  People are not resources.
  • Remove yourself from the actual technical work of the team and take a more strategic view of the team: What bottlenecks does the team have? Does anyone need training? Do people need coaching in how to work as a team with those difficult-to-master interpersonal skills? Can you make your job be more about coaching and enabling the team, rather than doing?
  • How can you coach your team/teams to discover their flow, to find their best cycle time, to work with technical excellence to reduce the need to fix things after the team thinks they are done? (Yes, I suggest that managers act as agile coaches.)
  • Consider what you reward and when. The more you reward individual work, the less likely you will have a successful agile culture. Why would people work towards a greater good when you reward individuals?

When managers realize their job is to coach the team as a whole and the people individually, they optimize up for the organization. That means the manager—if they understand flow—can coach the team.

What about if a manager needs something faster? And, the team has already accomplished its best cycle time? You could be honest with the team and the PO/Customer rep.

For example, it's fine to ask, “Is there another way to find the information you need in less time? I have pressure from X client.” Or, “Is there something smaller we could offer the market? I have pressure from Z marketplace.” When you are clear about the pressures you have as a manager, and you explain the pressures to the people who manage the backlog, you might realize you can get some of what you want, when you want it—without fake commitments.

A Manager's Job is to Build Resilience

When I ask my clients why they want an agile approach, I hear all kinds of answers. They all say something like this:

We need resilience in product development and delivery. We need to release something more often and gather feedback faster.

If you need resilience in product development, you might need resilience in:

  • How you recruit and hire
  • How you build succession plans
  • Your approach to organizational strategy. (Even if your strategy doesn't change that often, the mix of products and services might change fairly often.)
  • How you build products and services that meet the strategic needs.

You might need other forms of resilience.

All managers create and refine their organizational culture. The managers decide if an agile culture will stick. It's all in their hands with what people discuss, how we treat each other, and what we reward. The more we reward managers for doing technical work and reward individuals for their work, the less likely an agile approach will stick.

The entire series:

3 Replies to “Where I Think “Agile” is Headed, Part 2: Where Does Management Fit?”

  1. On “people vs resources”, amen sister. AMEN. I’ve been preaching this for years. I sometimes get flippant with people who say something like “we need more resources” and respond with “more computers?”

    On removal from technical work: I agree. I’m seeking a position and find management, even director postings that request experience in Java, Javascript, and/or various other technologies. I have a significant amount of programming experience: degree in CS, 16 years as a software engineer at IBM (languages most wouldn’t know, C++), a few at Dell (C++), and some C#/Javascript at my initial agile consulting position. I’ve been playing in the Ruby space lately.

    In an agile management position, I agree that a technical background is a plus. Specific technical skills, in my opinion, is not. If you want to talk SOLID or design patterns, OK. If you want 2 years of xyz technology and 8 years of abc technology, you’re not seeking an agile leader.

    I have striven to keep out of my agile teams’ code bases, but I participate, when asked. I remember attending a code review at a client. Code was in Java (I have not done Java). Still, I recognize anti patterns and pointed them out. Key was – I was invited to participate; I didn’t stick my nose in.

    I was flown to NYC once to interview for a VP position. I had a 2-hour grilling on Java details. I told them in advance I had never used Java (I avoided it when it became popular because I had an aversion to garbage collection … another subject). They wanted a code sample in advance and I gave them one. It was good. Java isn’t that hard. (Its ecosystem is more difficult). In the end, they cited my lack of Java experience to reject me… for a VP of software development position. Really?

    In order to keep my technical chops, I have to spend my own time.

    On managers acting as agile coaches, another “amen”. I’ve been asked on interviews about how many years of experience I have as an “agile coach” . I’ve been agile for 14 years. How many years as a scrum master? I’ve taught and coached scrum masters for years; how do you count that? I’ve been agile for 14 years, as a consultant, as a manager, as a developer, as a product owner, teaching, coaching. Really … you want a number for agile coaching years?

    On rewarding individuals, I’d suggest that rewarding individuals for the behaviors you are trying to promote is useful. Rewards, in my view, take many forms. “Thank you” is sometimes a sufficient reward. Sometimes taking someone out to lunch. In my experience, rewarding someone for behavior you promote is simply recognizing it. When you recognize the behavior, you promote its continuance.

    Hey … that’s just my opinion. Thanks again for making me think 🙂

    1. Adrian, yes, your experience mirrors mine, even as a consultant. “Do you have xx programming language knowledge?” Of course not! I am an “old” programmer. However, I suggested I understood the issues in how do they managed the code, compile, build, and release.

      As for rewards, yes, I often separate recognition from rewards. Maybe I shouldn’t. Thank you for helping me think.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.