Adapt agile to build a better business

Agile development holds clues for business management, too

As we discussed last week, when it comes to project portfolio management, the best approach is to get rid of the project governance process entirely. How? By eliminating projects as a class of activity altogether.

Instead, next-generation IT organizations should manage all activities as an ongoing stream of releases, doing so by embracing the agile variant scrum (last week's topic) -- with additional wrinkles (this week's topic).

[ Find out the 10 business skills every IT pro must master, beware the 9 warning signs of bad IT architecture, and steer clear of the 12 "best practices" IT should avoid at all costs. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]

And by "embrace," I mean adapt scrum to deliver business change, not just software that "meets requirements." Because as regular Advice Line readers know, everything is about improving the business, or there's simply no point. But how do you go about it? That's where Goldratt's theory of constraints (TOC) comes in. Eventually.

Delivering business change with scrum

Scrum works as a project-management alternative to the extent that you can break down software design into a collection of more or less independent features (now called "user stories"). Once you've done this, they are added to the enhancements queue -- renamed "the backlog" -- and are incorporated into releases (sprints) according to business-established priorities.

Business change, however, involves more than just dumping a new piece of software into the system and hoping everyone figures out how to use it to improve the business. It involves additional tasks such as designing improvements to business processes and practices, training, communication, making accounting changes, redefining performance metrics, and a bunch of other stuff.

Organizations that want to use scrum to manage business change will have to add all these tasks to the backlog, right alongside software features. This is a perfectly reasonable thing to do. In many cases, it will mean that user stories -- use cases with almost all the detail left out -- will become, well, use cases with almost all the detail left out.

Remember: Use cases are more than just descriptions of how software is supposed to behave. Done well, they describe how work gets done using the new software, which is just what the doctor ordered.

When the time comes to work on a user story, aspects that have nothing to do with software will be assigned to appropriately qualified business staff, who, in addition to working directly with the developer assigned to the user story, will have responsibilities of their own.

For example: "Educate users in the new process and software." This will go into the backlog, managed just like every other user story.

So far, so good, except something is missing: how to decide what constitutes a desirable business change in the first place. Without that, figuring out what to work on will be little more than moving from one whim to the next.

Eliminating business bottlenecks

Enter Goldratt. Stripped to its essentials (management-speak for "this is all I know about the subject"), TOC works by establishing a clear goal -- for examples, reduce incremental cost; shorten cycle time; increase process capacity. It then identifies the single biggest barrier to achieving that goal. This is the bottleneck -- the constraint. Get rid of it and you're closer to achieving your goal.

Next, identify the biggest remaining constraint, and get rid of it. I'd say "rinse and repeat," if it hadn't become such a cliché. Sounds pretty agile, doesn't it? It's an iterative approach to business improvement of all kinds.

Look at it this way: Traditional scrum is about creating releasable software builds -- assuming scrum has been around long enough to have traditions. TOC is about defining "releases" of business change. Add TOC to scrum and what you have is a way to organize your releasable software builds and your nonsoftware backlog items into a release plan that culminates in the elimination of a business bottleneck.

And if the business changes direction, thereby changing goals, and with them their constraints? No problemo. Choose new bottlenecks to fix based on the revised set of business goals, redeploy staff based on which release teams are now most important, create new release plans, and away you go.

Sounds like an excellent description of a highly desirable target for most businesses these days -- making them agile enterprises. Because what makes an enterprise agile is the ability to design, plan, and achieve intentional change, rapidly and reliably. All we need now is an acronym, so in hopes of achieving immortality, here's my suggestion:

Business agility = Technology incremental change + theory of constraints

Or: Business agility = TIC TOC.

If that doesn't earn me immortality, could I at least get my 15 minutes out of the deal?

This story, "Adapt agile to build a better business," was originally published at InfoWorld.com. Read more of Bob Lewis' Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

This story, "Adapt agile to build a better business" was originally published by InfoWorld.

Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more