Project Management – Page 18 – IS Survivor Publishing

Battle of the change methodologies

If you want technology changes to be successful you need an effective change management process. If you want a business change to be successful you need organizational change management.

For years, this similarity of names for very different processes was confusing.

Now it’s a good idea.

ITIL, in case you’ve never run across it, provides a comprehensive framework for understanding IT’s moving parts, how they fit together, and how IT management should handle them.

In the land of ITIL, change management is how IT operations takes the finished modules produced by dev teams and moves them to the test environment where software quality assurance can have its way with them, and from there into production.

Meanwhile, in another part of town, the folks responsible for OCM have been making sure the business areas that will be affected by the new software are properly prepared and ready to embrace the coming change.

The point of ITIL change management is to make sure software changes don’t blow up the IT production environment. The point of organizational change management is to make sure process changes that are the reason for software changes don’t blow up the business production environment.

They’re different things. One is about IT. The other is about the business. What could possibly go wrong?

Once upon a time, the answer was, not all that much. So long as the end-user training schedule coordinated so it preceded software’s move into production but not by much, there wasn’t much harm in considering these to be independent responsibilities.

But now we have DevOps, with its delivery model of continuous integration and continuous delivery — in some cases dozens of changes every day. As applied to a company’s internal systems, we’re talking about a potential mess, and not a small one.

The core of the problem is that DevOps as usually described is only appropriate for software companies and B2C eCommerce systems. These are the situations where software delivery is the same thing as business change.

For software companies it’s the same as business change because the direct result is an improved product, and the desired business change is the improved product.

Software delivery is the business change for B2C eCommerce systems, too. The purpose is to get the cash register to go ching more often and with more in the shopping cart. Yes, shoppers might get a slightly different experience each time they visit Amazon, ThinkGeek, or pick-your-shopping-site, but so what? On-line shoppers expect this and don’t get thrown by it.

The rest of the time, software delivery enables but doesn’t accomplish the desired business change. It’s a necessary but not sufficient condition for the change to happen.

If the difference isn’t clear, imagine you’re a sales rep. IT in your company has embraced DevOps, including continuous integration and delivery throughout the applications portfolio.

You use the company’s CRM system to keep track of which customers you need to contact, when, and about what. Only with DevOps everywhere, every time you open the CRM system you see a different screen layout.

Not what you’d call a dynamite productivity enhancer. Also not something you’ll find discussed very often in the DevOps literature. (I haven’t seen it discussed at all, but I’m sure I just missed it.)

The fact of the matter is, different business areas have different natural change cadences. All aspects of business change have to be orchestrated to match that cadence, from process redesign, to metrics redefinition, to deploying new equipment, to training, and to putting new and changed software into production.

And oh, by the way, even what sounds like the same old stuff really isn’t, because back when the theory for all this was being developed, work was performed by employees sitting at desks in cubicles at a company facility.

In the increasingly permeable enterprise, some affected employees work remotely, some remote and on-site workers aren’t employees at all, and some work has been shifted out of the business entirely. It’s been turned into customer self-service processes, and believe me, the folks who work in what used to be called Purchasing but is now Supply Chain Management aren’t going to have a lot of patience when the screens they use change without warning or preparation.

And so, a modest proposal: Get rid of most of the superstructure. Define projects and initiatives in terms of the desired business change, include coordinated work streams that cover all aspects of putting the change in question into production, and instead of yet another committee to speed things up (yes, the irony was intentional) just incorporate whatever the Change Advisory Board would otherwise do into project governance instead.

Simpler is, after all, usually better.

Lao Tse vs waterfall

Does Agile speed things up?

As we discussed last week, when it comes to IT App Dev, just defining what “speed things up” means is a non-trivial task.

And then there’s the definition of “agile,” which isn’t about speed in the first place. If we use automobiles as a metaphor, agility has more to do with a car’s suspension, steering and brakes than with the drive train.

If the question is whether Agile makes IT more agile, the answer is an unequivocal “Yes,” because with Agile, requested changes go into the backlog with no muss and no fuss, where with waterfall they’re submitted to the project steering committee as part of standard project governance.

A process step that doesn’t involve a committee is always more agile than one that does. Q. E. D.

There’s another way to answer the question, which leads to an even more emphatic affirmative. As pointed out last week, according to the Standish Group’s annual Chaos Study, across application development projects of all sizes, Agile methodologies yield higher success rates and lower failure rates than the waterfall alternative.

How does this translate to speed?

For a change of pace, this one is easy. If by speed you mean throughput, failed projects have no throughput. They deliver zero requirements — aka user stories — per month. And if by speed you mean cycle time, for failed projects the cycle time for delivering a user story is infinitely, or at least indefinitely long.

It’s Q. E. D. all over again.

But (you knew “but” was the next word, didn’t you?) …

There’s no such thing as an IT project, so whether you measure throughput or cycle time, if the units being delivered are software features you’re measuring what amounts to the production of work in progress, not finished goods, the finished goods being the intended business changes.

And it isn’t true that if you speed up the creation of work in progress you automatically speed up the process as a whole. For example:

Imagine a team of process re-engineering consultants has marched through a business, completely redesigning one of its core processes. Almost certainly a process change of this magnitude will require radically different or completely new enabling software.

Now it gets complicated, because to make sure the new software will properly support a process that’s been completely defined from one end to the other, for all major branches and contingencies, there’s no alternative than to design the software from one end to the other and for all major branches as well.

This is what waterfall does. To get Agile to do the same thing a business has to adopt what’s becoming known as “scaled Agile,” which defines software in terms, not only of user stories that are small and self-contained, but also in terms of “epics” that are, as the name implies, large and expansive.

You start with the epics, decomposing them into release trains, and release trains into user stories. Voila! You’ve turned Agile into waterfall, except for the design of user interface details and perhaps some underlying algorithms.

Which leads to the question, when it comes to large-scale business change is scaled Agile a necessary evil or a self-inflicted wound whose root cause is a failed change in culture — the retention of waterfall mental habits that relegate Agile techniques to the trivial.

I think the answer is, neither of the above. The view from here is that the root cause was the decision to re-engineer a process in the first place. Once a business decides to design and implement a large-scale process change in one big bite, there’s little point trying to build the supporting software in small increments.

Instead, businesses need to adopt the mental habit of incrementalism — to make a continuous stream of small changes the centerpiece of its management culture.

Because as Lao Tse once said, a journey of a thousand miles starts with a single step. What he didn’t explain is what IT and its business counterparts need to understand the most: Those who undertake journeys of a thousand miles and fail are the ones that, after they take the first step, try to cover the rest of the distance with one giant leap.

Those who succeed don’t take journeys of a thousand miles in the first place.

They take journeys of 2,100,000 steps, which they cover by walking briskly.