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

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.

I once wanted to invent an exercise machine that plugs into a standard video game port. The idea was to transform the fundamentally boring process of working out into utter absorption: When Pacman won’t move unless you’re pedal, it’s exercycle or be eaten.

Sadly, the Patent Office has already awarded a patent for this idea. Meanwhile, the intranet has recently rendered the only other invention I’ve ever wanted to build … the PrinterShredder! … obsolete.

The PrinterShredder!, like most brilliant concepts, is obvious once stated: Since most printouts are recycled without anyone ever looking at them, businesses could save a lot of money by eliminating the wasted steps, immediately recycling the output as soon as it is created. (Not to mention the PrinterShredder!’s impact on security — valuable company secrets would never leave the data center.)

But now we have the ability to publish print jobs as HTML directly onto our intranets, where everyone can ignore them at the speed of electricity (about 33% of the speed of light … but I digress).

It has been common practice for budget-driven data center managers to turn off suspect print jobs periodically, turning them back on only if someone complains. Often, this is the only way to find out if a job is needed. But as storage drops below a penny per megabyte, it is now less trouble to just dump everything out there.

This is the same thinking that lead to the Lincoln Navigator. When any resource is overly plentiful, we get sloppy in how we use it, whether it’s gasoline leading to over-sized, inefficient cars, the immensity of the sky leading to atmospheric pollution, or cheap processor cycles and storage leading to “kitchen sink” intranets and Web sites.

When we get sloppy we face unintended consequences. Fuel-inefficient cars increase demand for fuel so gas prices rise … but we still own the Navigator. Atmospheric pollution leads to global warming, ozone depletion, and pulmonary disorders … but our whole economy rests on the processes that generate pollution. And when you just dump reports onto your intranet, you make it that much harder to find anything useful, because you’ve made the signal-to-noise ratio worse … and you probably create new jobs for analysts to sort through the muck.

The problem is that cheap storage is the wrong focal point for our attention. We should be taking advantage of our intranets’ real-time processing and highly visual nature to create “dashboard reports”.

As with so many user-interface issues, your daily driving experience tells you most of what you need to know to understand dashboard reporting. What, after all, does your dashboard display? Exactly what you need to know to drive safely without damaging your car. It isn’t just exceptions, nor is it only summary data. It’s neither entirely graphical nor entirely textual. Nor is it uniform: Some dashboards are designed for more sophisticated drivers than others, presenting both more and more detailed information.

But it’s always what the driver needs to know, while driving, designed for easy interpretation at a glance.

Which leads us to the tough part. Over a span of nearly a century we’ve learned what drivers need to know at a glance, filtered by what we can build into automotive dashboard displays. No such consensus exists for a business dashboard, so you get to figure it out.

Next week’s column will give you some help.

ManagementSpeak: More later.

Translation: I don’t consider you worthy of the conversation in the first place, and I have no intention of carrying it on with you in the future.

Paul Novelli joins the KJR Club with this worthy translation.