It looks like nothing was found at this location. Maybe try a search or browse one of our posts below.

The comedian Steven Wright reported dreaming that everything he owned was stolen and replaced with an exact duplicate.

If you replace Windows with Linux as your organization’s preferred desktop operating system (last week’s column recommended that you carefully assess this option) your end-users just might feel like they’re trapped in Steven Wright’s dream, except the duplicates won’t be exact, and perhaps not quite as good, either.

The conundrum of Linux is that for the most part it’s a me-too operating system. Innovation happens elsewhere – on Windows and the Macintosh for desktop applications and OS enhancements; on Netware, Windows NT/2000, or a commercial Unix for servers – and someone says, “Hey, I can do that on Linux!” Then, through a quasi-Darwinian process, the open-source community quickly refines and debugs those applications and platform extensions it finds useful.

But can the open-source license model support true innovation, or is mimicry the best it can do? We don’t really know.

So long as Linux fails to gain dominant marketshare, this question is unimportant. But imagine for a moment that it succeeds. What then?

One school of thought says the innovative energy now directed at the Windows platform would switch to Linux, following the marketplace wherever it leads. This is a reasonable expectation for a free-market economy.

The distance from reasonable expectation to reality, however, can be pretty long, and another school of thought holds that in a mature marketplace like the personal computer, the open-source model doesn’t promise enough profit to support the risk of investing in truly innovative concepts. Of course, just because Linux is an open-source OS doesn’t mean applications that run on Linux have to be open source as well, but once you start buying non-open-source software for Linux you’re back where you started: MS Office XP for Linux, if it existed, would have licensing terms just as onerous and risky as does MS Office XP for Windows (and presumably for Macintosh).

When Adam Smith first wrote about market-based economics we were a nation of merchants and farmers. Affluence was the most anyone aspired to – the establishment of a wealth-based aristocracy was a century in the future.

The open-source movement is, in a sense, a return to this merchant-based economy (not a communistic plot, as its extreme detractors claim). The open (source) question is whether, in the 21st century, affluence is enough anymore.

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.