Scaling, Small Batches and Asymmetry
How making the problem smaller is the option you ought to consider
Forget Scaling Agile: Break Down Your Problems Instead
The siren song of "Scaled Agile" is alluring. As companies grow, they often feel the need to scale their agile practices, leading them down the path of frameworks like SAFe. But what if instead of scaling agile, we focused on decomposing our problems?
This post explores an alternative to traditional scaling, inspired by Donald Reinertsen's principles of product development flow, lean manufacturing, and the concept of marginal gains, all while keeping a keen eye on cost of delay and maximizing total profit contribution.
The Problem with Scaling
Scaling agile often results in:
● Increased complexity: More roles, processes, and meetings.
● Slower decision-making: Layers of hierarchy hinder agility.
● Reduced autonomy: Teams become cogs in a larger machine.
● Communication breakdowns: Information gets lost in the noise.
Instead of battling this complexity, what if we focused on simplifying the work itself?
Reinertsen's Flow: Small Batches, Big Impact
Donald Reinertsen, in his book "The Principles of Product Development Flow," highlights the power of small batch sizes. Smaller batches lead to:
● Reduced cycle times: Work moves faster through the system.
● Faster feedback: Identify and address issues quicker.
● Increased flexibility: Adapt to change more easily.
● Lower risk: Smaller investments in each batch.
Think of it like this: it's easier to steer a small boat than a giant ship. Small batches allow for quicker course correction and smoother sailing. This also means reducing the cost of delay, as smaller batches deliver value faster and allow for quicker adaptation to market changes.
Lean Thinking: Incremental Improvement
Lean manufacturing emphasizes continuous improvement through small, incremental changes. This aligns perfectly with the marginal gains theory, where small improvements accumulate to create significant overall gains.
Instead of massive overhauls, focus on making small, targeted changes to your product and process. These incremental improvements, when applied consistently, can lead to dramatic results over time. Each small release contributes to the total profit, and by focusing on continuous flow, we maximize the value delivered over time.
Shrinking the Problem, Not the Team
The key takeaway? Focus on making the problems and product features smaller, not the organization.
● Break down large features into smaller, independent deliverables that can be released quickly. This allows for better understanding of each feature's contribution to the overall profit and prioritization based on value and cost of delay.
● Prioritize ruthlessly and focus on delivering value quickly (see Cost of Delay (CD3) and Weighted Shortest Job First). Avoid using proxy variables like capacity, development costs and/or cycle time; instead, prioritize based on the economic value of each feature. Use Return On Investment in the Product Backlog to stack rank scheduled work.
● Empower small, cross-functional teams to own their work. This fosters autonomy and accountability, leading to faster decision-making and quicker delivery of value. It’s elusive to create self organizing teams, especially in a big organization but it is worth it. Team Topologies, among others, has excellent guidance.
● Minimize dependencies and handoffs between teams. This reduces waiting time and improves flow, ultimately minimizing the cost of delay. Use agreed to heuristics to make economic decisions that promote innovation, autonomy and return on investment.
By shrinking the work itself, we can avoid the overhead and complexity of scaling agile frameworks. This approach allows us to maintain agility, speed, and responsiveness, even as the organization grows.
Conclusion
Scaling agile is often a solution to a problem that can be avoided altogether. By embracing Reinertsen's flow principles, lean thinking, and the power of asymetry through small changes, while focusing on cost of delay and profit contribution, we can achieve remarkable results without adding unnecessary complexity.
Instead of scaling your organization, shrink your problems. You might be surprised at the impact it can have on your product development flow and your bottom line.
References:
Please look into each of these author’s and their books. I am grateful for their work and insights.
Allen Downey
You Are Probably Overthinking It
Donald Reinersten
Craig Larman
Agile and Iterative Development