One of the challenges I see in organizations is how managers can use agile approaches. One of the biggest problems is that the entire organization is organized for resource efficiency (think silos of functional experts). Agile approaches use flow efficiency. Thinking in flow efficiency changes everything.
Many people in organizations believe that dividing up the work among specialists will get the work done faster. That’s the case in manufacturing. (Think piece work.) Manufacturing processes use resource efficiency to reasonable effect. However, manufacturing does not account for innovation or learning. (Design of manufacturing processes is innovative and requires learning. That’s why manufacturing processes often prototype (iterate on their work) when they develop the process.)
Organizations who need to optimize for innovation or learning realize that the people work collaboratively. Collaborative work—including management work—demands flow efficiency instead of resource efficiency.
Flow efficiency helps people optimize “up” for lack of a better term. (If you have not yet read This is Lean: Resolving the Efficiency Paradox, I recommend you do so.)
Once you start to think about flow efficiency, you might start to think about throughput (and maybe cycle time and cumulative flow). That changes the data the managers need to make decisions.
Now, it doesn’t matter what anyone’s utilization is. What matters is the Cost of Delay (or Cost of Delay/Duration). It might even matter where the bottlenecks are and who can unwedge those bottlenecks.
An organization might still need to track the run rate for a project, program, or even a workgroup such as Customer Support. Run rate might not mean as much when you can measure revenue, customer acquisition and retention, and how often you can get the customer to return and buy more. (The more often you deliver value, the more you can acquire customers who pay.)
One manager learned about flow efficiency. She was managing the team working on the “most important” project in the company. She decided to stop tracking utilization. She told her team, “I want to track your throughput as a team. I want to know what I can do improve the flow of work through your team. Please bring me your impediments to flow and I’ll address them.”
The team told her about build time (too slow), insufficient test automation (not enough and too slow). She built the case using Cost of Delay/Duration to get other teams to help this team reduce build time and increase test automation.
The teams together took eight weeks to make what they called infrastructure improvements. After the first two of those eight weeks, the team finished twice as many stories (2 instead of 1) as they had before all the improvements started. The team continued to increase their throughput. By the end of the eight weeks, the team was able to finish anywhere from 8-12 stories. The team continued their now-higher level of throughput. After three months, the organization had attracted many more customers. They decided to move to a subscription model for their product, and recognize much more revenue.
Yes, a team’s ability to deliver value fast created feedback loops for management: product management, project portfolio management.
(I’m still reading about agile-useful metrics, so I’m sure there is more here.)
If managers worry about flow efficiency, they ask the teams, “What can I do to help your throughput?” The managers manage the project portfolio. Work flows through teams, not through people.
That changes what managers do. Top-level managers (and maybe product managers) define the strategy and talk to customers to see what customers need so they can refine the strategy. Top managers also consider new options for entirely new products—changes in strategy.
Middle managers plan and replan the project portfolio to implement the strategy. First-level managers remove impediments to collaboration.
Let me summarize a little:
Agile managers have a very different role than more traditional managers. They manage differently. Agile managers might use the two pillars of lean: respect for people and continuous improvement as a basis for their management style. To me, that means building relationships with each person the manager “manages,” the willingness to question all assumptions, and to look at the whole: what does it take for us to succeed as an organization. The idea of one function succeeding instead of all of us vanishes.
Flow efficiency changes the corporate culture: managers change what they discuss. Managers change what they reward. Managers change how they treat people and how they expect people to be treated, because it’s not about the individual “resource.” It’s about the system of work.
The posts so far aside from this post:
- Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams
- Defining “Scaling” Agile, Part 2: Program Management for Product Development
- Defining “Scaling” Agile, Part 3: Creating Agile Product Development Capabilities
- Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development
- Defining “Scaling” Agile, Part 4A: Sharing Agile Outside of Product Development
I’m quite sure this post is not perfect, but I have other writing to do. I expect to have one more summary post.
| Reference: | Defining “Scaling” Agile, Part 5: Agile Management from our JCG partner Johanna Rothman at the Managing Product Development blog. |
