All Posts in Project Management

|In: Industry Commentary|Last Updated:

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.

Comments

|In: Industry Commentary|Last Updated:

Google “Scaled Agile” and among the 148,000 or so results (148,001 including this article) you’ll find several claiming to provide best practice.

Here’s the problem: The first mention of Scaled Agile was in or around 2008.

Sacrifice the first three years to just selling the idea to a few adventurous clients willing to try a new, untested approach to things and you’re left with just four years in which to try it in enough environments to even call it a well-tested practice. Proven practice? I don’t think so. Best practice? Not a chance.

But what I just said was wrong. I said, “Here’s the problem,” when I should have said, “Here’s just one of the problems.” The Scaled Agile frameworks I’ve read about or seen put into practice have problems far worse than semantic puffery.

Even if you aren’t a student of Agile you’ve seen its four core principles:

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

You know what’s coming.

Look at your typical Scaled Agile framework (pick one from your Google search). You’ll find it has more moving parts than an F-22, and if that’s an exaggeration you’ll find it does have as many moving parts as most depictions of waterfall software development.

Scaled Agile violates the first principle of Agile — it emphasizes processes and tools over individuals and interactions.

It also violates the fourth principle — not intentionally but because of what most Scaled Agile frameworks exist to accomplish. In theory their purpose is to scale Agile up so it can take on the big problems. But taking on big problems presupposes you think in terms of big problems in the first place — in terms, that is, of taking a big problem and, through a process of successive decomposition, creating a detailed enough view of its components that everyone’s work will come together into a coherent solution.

Create a detailed view like this and everyone involved in its creation will do what they can to avoid making adjustments to it, for the simple reason that it’s hard enough to create a big plan in the first place. Fiddling with it means tracking down all the ripple effects of the proposed change, which is hard, skull-busting work.

Thanks very much for your brilliant idea. We’ll take it under advisement.

And then, as the famous Sidney Harris cartoon has it, a miracle occurs: Scaled Agile calls for a multi-day meeting that includes all members of all teams working on a release — easily 50 or more participants. Think “participant” is an accurate description of most people attending a meeting that big? “Audience” is more likely. Conducting an effective multi-day meeting with that many participants would take a miracle.

One more gripe before coming to grips: Based, at least, on my unscientific sample, if you squint at your average Scaled Agile framework you’ll find one or more committees lurking in the shadows.

It isn’t that committees aren’t sometimes necessary. It’s that “committee” and “agile” are organizational opposites. Committees meet on a defined schedule. That schedule acts as a sort of “governance governor.” It establishes the pace of change over whatever it is they govern.

Based on the companies my colleagues and I have looked at, Scaled Agile generally turns out to be, not only not Agile, but slower and less flexible than its waterfall alternatives.

Let’s reel all this back in and start over. Agile got its start because it faced a reality of business that conflicted with waterfall’s most important hidden assumption — that detailed specifications will still be relevant when they’re turned into code.

But more often than not, for a big piece of software, by the time this happens through waterfall’s feasibility/requirements/specifications/coding/testing/deployment cycle, the business marketplace will have changed. The software solves a problem that no longer exists while failing to solve the new problems that do.

Agile’s primary virtue is that it stops the pretending. Like waterfall it breaks big problems into small ones, but it solves them now, one or a few at a time, in order of their current business priority.

Did priorities change since the last look at the list of small problems? Discard the ones that aren’t relevant any more, add whatever new ones have been discovered, and return to solving today’s problems right now.

Have a problem big and complex enough to require Scaled Agile? Waterfall is probably a better choice.

But a change in business attitude would be better yet. Very often, solving today’s problem today followed by a fresh reconnoiter is just what the strategy doctor ordered.

Or should have.

Comments