All Posts in Organizational Design

|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:

The subject: Bimodal (or trimodal, or agile, or high-speed) IT. The challenge: Culture. Culture is a challenge to IT agility. It’s a challenge if you buy into the bimodal model, where systems of engagement need to change and adapt at lightspeed while systems of record need accuracy and stability above all else. It’s just as big a challenge if you embrace the trimodal model described here last week.

Culture is a challenge because it means “how we do things around here.” It’s the set of shared assumptions that let people work together efficiently. Think of culture as an organization’s cognitive infrastructure — a foundation everyone builds their thinking on, confident that if they do, everyone else is likely to agree with their conclusions.

Start with the six dimensions of optimization: Fixed cost, incremental cost, cycle time, throughput, quality, and excellence.

With bimodal IT, systems-of-record employees assume quality, throughput, and incremental cost are what matter most, while systems-of-engagement employees are equally sure cycle time, excellence, and fixed cost are what deserve the most attention.

It’s a recipe for conflict. Now add this: Systems of record are part of the business infrastructure. They’re necessary but not strategic. Businesses invest in them to preserve the value they’ve been delivering for quite a long time.

Systems of engagement are strategic. Businesses invest in them to get new value. One way or another, directly or indirectly, systems of engagement are part of how businesses get the cash register to go ching!

Which means fast-mode IT projects get better and easier funding, and the IT professionals who staff then get more … and more career-enhancing … attention.

The trimodal analysis is a bit different. Understanding its built-in conflicts starts with another property of culture — it’s a big part of how employees define identity, affinity, and, as a natural byproduct, ownership.

The trimodal model isn’t built around the systems of engagement vs systems of record model. It’s built around a progression, from prototype to production-grade, and then from production-grade to part of the core architecture.

In Simon Wardley’s version, described here last week, the progression is managed through a process of theft — “settlers” steal “pioneers'” prototypes to make them production grade; “town planners” steal settler’s production-grade systems to make them suitable for inclusion in the core architecture.

Think pioneers are going to thank the settlers who take over control of their creations and impose strict new rules for their evolution? Think the settlers, who have carefully adapted their systems to support their part of the business, will be delighted when town planners take them over and generalize them so they support the whole enterprise better by imposing one-size-fits-nobody design compromises?

Think again. No matter how what system of governance IT and the rest of the business impose to regulate this process, it’s still going to feel like kleptocracy to those on the receiving end of it.

You’re the CIO. One way or another you need to keep the lid on conflicts within IT. So you instituted DevOps, not only to help speed things up but also to reduce the usual and natural conflicts between Development and Operations. But DevOps exacerbates conflicts between the high-speed culture that uses it and the low-speed one that avoids it.

You’ve already instituted some form of Agile Enterprise Technical Architecture Management (ETAM). (Haven’t you?) With some trepidation you incorporate the kleptocratic town-planner function into it. But you recognize the resentment it will create, and want to minimize it.

What’s the plan?

There are no best practices for this. Not that there ever are, but some fields at least have proven, tested practices. Here, the best we can do is apply what we know to what we don’t know. Three suggestions:

  • Avoid false dichotomies. System of record vs system of engagement is one. These aren’t opposites. They’re the poles of a continuum. System-level governance should establish the proper trade-offs between system-of-record-ness and system-of-engagement-ness for every system IT manages.
  • Rotate staff. No, don’t have them spin in circles. With some exceptions — your deep system mavens who like being deep system mavens — move applications staff from one system to another, and in and out of your ETAM function. Move operations staff from one DevOps team to another, and through ETAM as well. Resenting them is harder when they become we unpredictably and often.
  • Promote “Form Follows Function.” As the first rule of design it’s already at the heart of your architecture (isn’t it?). Those who embrace it are more likely to assume those who do things differently are dealing with different circumstances.

Making it part of how we do things around here will reduce cultural conflict.

And happily enough, it will also improve design.

Comments