One of Agile’s most appealing attributes is that it’s … well, it’s agile. As in nimble. Flexible. Able to change direction without causing back spasms.

There’s a second that’s less-often recognized, and it’s one reason to approach Scaled Agile cautiously: Agile is a deeply entrepreneurial way of doing things. Scaled Agile is not.

Most forms of Agile are built around a team to-do list called a backlog, which has a lot in common with an enhancements queue. It’s up to the product owner to decide which items in the backlog should be turned into reality and in what sequence.

Backlog management is why Agile eliminates the need for scope management: Requested scope changes are added to the backlog, then managed as part of the backlog. They aren’t a change to project scope because Agile projects don’t have scope in the traditional sense of the word.

It’s what makes Agile entrepreneurial: Agile teams can recognize and take advantage of opportunities as they arise.

Scaled Agile can’t do this. For that matter, Scaled Agile shouldn’t do this. The reasons are intrinsic to program-scale development.

In case you aren’t familiar with the vocabulary, programs implement strategy. A program is composed of multiple initiatives, each of which achieves a specific business outcome and/or implements a major software module. Initiatives are made up of multiple projects, each of which delivers clearly defined work products which, when assembled, achieve the goals of the initiative, which in turn, when assembled, achieve the program’s strategic intent.

Regular old Agile (RoA?) doesn’t easily lend itself to initiative or program-level change. The reason: Product owners or product steering committees set an Agile team’s priorities, through the straightforward expedient of reevaluating the backlog on a regular basis.

But with a multi-project initiative or multi-initiative program, some project teams depend on other project teams to build things they need, which means project teams’ priorities have to be coordinated.

The bigger the effort, the greater the ripple effect of re-prioritized change, and so the more central coordination is required.

It isn’t just priorities. Agile’s usual dynamic, iterative figuring out how things should work also has a ripple effect in initiative and program-scale change. When one team expects a service that’s a different team’s responsibility to work in a particular way when it shows up, and that service works in a different way when it appears, bad things can happen — bad things like re-work, and like the team on the receiving end screaming in rage at the team that’s on the giving end.

When the goal is large-scale strategic change there’s no easy alternative: Some form of central coordination for goal-setting, scheduling, architecture, and scope management, can’t be avoided.

Businesses, it appears, need Scaled Agile for this sort of situation, unless they want to devolve back to the bad old days of waterfall.

Except … I wonder if we aren’t looking at the wrong end of this particular horse.

COTS (Commercial Off-The-Shelf software) is one reason.

The most labor-intensive part of most business change efforts is implementing the software needed to support the business change.

But more often than not, businesses can buy software that will, with some configuration and construction of satellite systems, do the job that needs to get done. COTS solutions take care of most of the technological interdependencies among program-scale projects, especially if a company settles on an ERP-scale package that pre-integrates a wide variety of modules that deliver much of what the various functional parts of the business need to do.

If that’s the case, COTS implementations can give project teams a much greater level of independence than large-scale development efforts. This is especially true if the teams rely on an Agile variant like Conference Room Pilot (CRP) that’s designed for package implementations and co-designing business changes, instead of force-fitting a methodology like Scrum that’s designed for new application development.

COTS plus CRP can improve the balance between central program overhead and getting-the-job-done project teams, but they can’t eliminate it, not should they.

What can eliminate it is an idea mentioned previously in this space, in one of my favorites from the archives: “Fruitful business change” (KJR, 5/26/2008): Instead of making software implementation less agile, make business change more agile.

Another view of Scaled Agile’s problems is that it tries to connect iterative and incremental development to centrally designed and directed business change. It’s a square peg/round hole situation.

Instead trying to solve this by making Agile more strategy-driven, it might make more sense for business change planning to look more like Agile.

It might, that is, be time to figure out how to get entrepreneurship to scale.

* * *

Next week: What Scaled Entrepreneurship might look like.