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.
Bob,
If you have not yet done so, please read “Agile!: The Good, the Hype and the Ugly” by Bertrand Meyer, who is a very big foot in the software world. His experience parallels mine.
I think there’s definitely merit to a more agile approach to business change. I wrote about this in an Ark Group publication a little while ago. Unfortunately I can’t share this here but anyone who’s interested can email me and I’ll send you a copy of my chapter.
The essence of the argument is that organisational multitasking suffers from context switching overhead, deadlock, and pre-emption just like a computer operating system. Above a certain level of multitasking, performance suffers as the overhead eats into productivity.
So just like an operation system, a smart algorithm (business process) will minimise the impact of these events occurring.
Adopting an agile approach to management means prioritising and only doing a certain number of changes every month or quarter (say 10). The same rules of agile apply, ie people must understand and sign off on the next iteration’s scope and the intent is for all scoped activities to be completed within that iteration.
All business units should continue to do their assigned business as usual activities, but otherwise should devote their efforts towards supporting the organisationally-agreed priorities.
Agile and Waterfall make two different promises. Waterfall promises a specific set of features (with a specific level of quality) on a specific date. It is not good at *keeping* that promise, which is why many projects see budget and schedule overruns.
Agile makes a different promise: the system will always work, with whatever features have been added, and the code will always be high quality.
The promises from Agile are not that helpful for enterprise development. A large-scale, multi-team development effort with several components must have some assurance that the components will at some (predictable) point come together and work together. An enterprise project must work within the company’s larger schedule for product and service delivery to customers. Agile cannot promise that coordination.
It seems that the developers of Scaled Agile want the best of both: the reliability of Agile and the predictability of Waterfall. We may someday have such a process, but I think we need more experience with Agile. After all, it took 40 years of Waterfall before we developed Agile.