Delivery At Scale 1: The Scaling Challenge

Summary

This post is part 1 of a 5-part series that discusses the challenges of scaled agile delivery. Non-proprietary solutions are proposed that emphasize simplification and minimizing  governance overhead.

Summary

Enterprise solution delivery requires multiple delivery teams to service large product backlogs. Proprietary scaling frameworks impose additional layers of governance which can severely impact delivery flow performance. Legacy organization structures make it difficult for team agile practices to work. Approaches should be pursued that emphasize scaling down the problem over scaling up the solution.

 

---

Scaling Agile Delivery – The Challenge

You build large systems to support your company’s business operations.  You have a large and rapidly evolving product backlog reflecting the demands of  customers, internal stakeholders and the hordes of competitors besieging your business. Your business leadership has staked out a strategy to stay ahead, but needs confirmation that solution delivery timelines and costs are achievable. The pressures on you and your team are unrelenting.

You have enthusiastically embraced the Agile Manifesto with its twelve timeless principles, and love the elegance and simplicity of Scrum. You see in all of this an answer to the quest for a rational approach to software development, and a ray of hope for embattled software teams. But, you still feel that more is needed to strengthen your delivery capabilities.

As a technology delivery leader, you need the capability of planning and executing with multiple agile teams while also maintaining the flexibility to adapt and respond quickly to rapid market changes. You need a simple framework that will support: Large, rapidly evolving backlogs, multiple delivery teams, multiple-sprint planning horizons, adaptable plans.

You search far and wide for solutions. One vendor has assured you it has the best scaling solution for your company, and that its 1,000-plus page framework is highly flexible, adaptable and non-prescriptive. But you note  that their approach to planning is a 2-day event with detailed step-by-step instructions, with tasks laid out by the hour. Further, to adopt their framework you would be required to get people in your organization trained and certified by them. Their framework covers not only product delivery, but also topics like portfolio management, budgeting/accounting, and competitive strategy.

These are all good things, but your responsibility is technology delivery, not business strategy, and you and your teams are accountable for delivery performance – goal achievement, speed, quality and predictability. Your leadership team includes a highly competent  group of business strategists, who have been successfully steering your business through accelerating change and disruption, and who you trust to ensure you are building the right solutions. Your primary concern is with scaling your technology delivery capabilities and improving operational agility.

The problem you want to solve looks like this:

The fundamental problem is twofold: how to service a large product backlog with multiple development teams, and, providing confidence that delivery timelines are rooted in reality. The teams are currently doing solid scrum and you want to preserve those capabilities. You acknowledge that you will need some additional governance for planning and coordination of the work for multiple teams, but you want to make sure this is minimal. The last thing you want is whole new layer of governance with additional roles, events and artifacts. In particular, you do not want to be locked into a large and complex framework, requiring extensive training and certifications.

You want the flexibility to evolve and adapt your delivery processes as the demands on your business change over time, while keeping them as simple and lightweight as possible. Your definition of lightweight is that anyone in your organization can understand it and can explain it to anyone else in minutes. You feel strongly that scaling down the problem is more in line with agile thinking than scaling up the solution. You want to remain independent of proprietary scaling frameworks, and seek an approach, requiring minimal additional governance, whose adoption does not rely on expert knowledge from outside the organization.

Basic Elements Of A Scaling Framework

Scrum is a team-based delivery framework where individual cross-functional teams translate product backlogs into release-ready product increments. The framework does not address how multiple teams might collaborate to address:

• Large, rapidly evolving backlogs reflecting the needs of multiple stakeholders and a fast-moving market environment, beyond the capacity of a single Product Owner.
• The need to service those backlogs with multiple development teams in order to keep pace with customer and market demand.
• The necessity of being able to plan beyond a single sprint, while preserving the ability to quickly adapt as circumstances change.

Four key elements are identified to support delivery at scale:

1. An organizational structure that enables agile delivery
2. A systematic workflow for Product Backlog creation
3. A system for planning with multiple delivery teams, and
4. An execution framework that is predictable and adaptable.

Each of these elements are explored in depth in subsequent posts.

Keep reading: Part 2 – Organizing for Scaled Delivery.