Having trouble scaling agile? It might not be an “agile” problem.

Scaling agile shouldn’t be any more difficult than scaling any change across an enterprise, as long as your enterprise is structured for success.

If you’re having trouble getting agile to scale, you’re not alone. Many companies struggle to capture the benefits of agile (faster time to market, lower cost, happier teams) and still manage budgets and timelines that are essential to running a business.

A good agile process can actually produce better and more reliable metrics than traditional project management, and scaling the process doesn’t have to be painful.  However, if your organization isn’t structured to take advantage of the benefits of agile, scaling will be difficult or impossible.  You may end up in a worse place than you began.

Functional Structure vs. Agile

I was recently working with a large financial institution that had mandated agile for all of their software teams (yellow flag).  The teams were struggling to write user stories (brief descriptions of functionality written from the end user’s perspective) because their end users were not people, but other computer systems (another yellow flag). All of the user stories started with phrases like “As the payroll system, I want to….” or “The audit system shall…”

I realized that the tech organization was set up in functional silos, each with its own budget, vice-president, directors, managers and teams. Producing any end user value (and revenue) required coordinating across several functional divisions.  Each division had its own objectives and executive bonuses based on those objectives.  There was little incentive to cooperate.  Teams were unable to write a meaningful user story, let alone scale agile to the enterprise.

I’ve seen the same pattern many times, and you likely have too.  Attempting to scale an agile process before addressing this problem usually results in AINO (Agile in Name Only). Project managers are now called “scrum masters.” Functional specifications are now called “user stories.” More and heavier processes are required to manage projects across functional teams.  Teams work on multiple projects with no clear priority.  The teams ultimately abandon practices such as story point estimating, demos and retrospectives because they aren’t adding value. The resulting “agile process” (it will most often be called a “hybrid”) is usually more costly, more chaotic and less effective than the process it replaced.

An Easier Path

Changing a functional structure takes time and top-level executive commitment, and it can’t happen overnight, but to attempt to scale agile in a functionally based organization will almost certainly end in frustration.  Instead, consider starting with agile fundamentals. Focus on one of your key products and its customers. Build a real product backlog with customer-focused user stories. Set up a cross–functional, dedicated agile team with a product goal, a dedicated product owner and dedicated funding (to remove resource competition).  Now you’re ready to scale.  Add additional, separately funded product teams one at a time, each with its own product owner and product backlog.

Setting up a common organizational sprint cadence and a few other simple norms will allow you to scale fairly painlessly.  Your product backlogs will have all of the data you need to manage dates and budgets (likely more effectively than ever), and you’ll be scaling on a solid agile foundation.