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 series so far:
- Where I Think “Agile” is Headed, Part 1: Do You Need an Agile Approach?
- Where I Think “Agile” is Headed, Part 2: Where Does Management Fit?
- Where I Think “Agile” is Headed, Part 3: What Is The Recipe, The Right Answer?
- Where I Think “Agile” is Headed, Part 4: What Does “Agile” Mean?
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Where I Think “Agile” is Headed, Part 2: Where Does Management Fit? Opinions expressed by Java Code Geeks contributors are their own. |
