HomeIndustry Commentary

Business Agility

Like Tweet Pin it Share Share Email

You have to read this book.

If you lead an IT organization, or part of an IT organization, you have to read it. I didn’t even write the sucker and I’m saying this — what does that tell you?

The book is Business Agility: Sustainable Prosperity in a Relentlessly Competitive World (Wiley, 2009). Its author, Michael Hugos, is a working Chief Information Officer turned consultant (and who needs this kind of competition — get back into the saddle, Michael, and leave the consulting to those of us who prefer to avoid productive employment!).

Here’s what I like about this book: Nearly everything. It agrees with just about all of my own biases. For example:

Hugos recognizes the importance of delivering business change and not just “software that meets the specifications.” His preferred methodology includes business process mapping as the driver for everything that happens.

He also recognizes the value of the “good enough now beats perfect too late” principle, advocating 80 percent technology solutions that deliver 1.0 releases fast, and let business stakeholders queue up enhancements after that to build out functionality. This provides maximum value in minimum time.

Specifically, Hugos describes his preferred variant of Agile systems development: Define/Design/Build. He allows two to six weeks for definition, one to three months for design, and two to six months for building the solution. It works out to a delivery cycle that averages seven months in length.

Hugos thinks in terms of organizational dynamics, describing a three-feedback-loop enterprise. The first is the OODA (Observe, Orient, Decide, Act) loop, which drives strategy (see “Wrestling, Pandas, Ethics and OODA,KJR, 10/25/2004 for more on OODA). OODA sets the direction and keeps it pointed in competitively fruitful directions. Hugos calls this Awareness.

The second loop, which he calls Agility, is about spotting new threats and opportunities and responding to them quickly. (More evidence that Hugos and I are kindred spirits: In “Leading from in front,” (KJR, 10/6/2003) I recommended re-spelling the traditional SWOT analysis (strengths, weaknesses, opportunities and threats) as TOWS, because internal strengths and weaknesses are only relevant in the context of external threats and opportunities.) Agility is what lets business capture opportunities instead of wishing for them.

The third loop, Balance, recognizes the importance of becoming excellent at the responses first implemented through the Agility loop, once they prove themselves. The Balance loop is where continuous improvement happens.

More organizational dynamics: Hugos is eloquent in his insistence that an agile business has to eliminate hierarchical decision-making and replace it with peer-level decision networks, similar to last week’s discussion (“Higher hierarchies,” KJR, 6/15/2009), which was, in part, stimulated by Business Agility.

This is not a utopian book. Hugos makes trade-offs clear — for example, the trade-off between efficiency and responsiveness. I’m not sure I agree with his conclusion that responsiveness is the right answer for all businesses, because “always” is an accurate conclusion only rarely. The world is too contextual for always to be a credible assertion.

On the other hand, Hugos offers a strong reason for choosing responsiveness over efficiency, namely, Alpha.

Alpha is Hugos’s big idea, providing the rationale for all the rest. For those of you who aren’t students of investment management, Alpha is the level of return on an investment that exceeds what you would expect for a given level of risk. IT, says Hugos, can increase a business’s Alpha by turning products … which by themselves generally become commodities in short order … into product/service bundles supported by the ability to leverage information and technology.

Hugos asserts that properly deployed IT can enable an additional four percent Alpha for businesses that pursue an agile business strategy.

This isn’t a purely theoretical discussion, either. Hugos illustrates it with an example taken from his personal history: Paper coffee cups, which his employer sold to restaurants and other bulk purchasers. First, and perhaps most important, Hugos joined the sales team in its discussions with customers. Do you? If you don’t, it’s time to start.

By participating in sales meetings, Hugos met a customer that bought holiday-season cups and found itself with expensive excess inventory in January ($600,000 — a lot of paper cups). Its new purchasing manager was determined to cut this number in half.

So Hugos led a team to develop a good-enough solution in 90 days. The solution beat the target, cutting the customer’s excess inventory by two-thirds. In exchange, the customer was willing to spend a bit more per cup.

And everybody won.

Comments (3)

  • “Specifically, Hugos describes his preferred variant of Agile systems development: Define/Design/Build. He allows two to six weeks for definition, one to three months for design, and two to six months for building the solution. It works out to a delivery cycle that averages seven months in length.”

    I would not describe a seven month delivery cycle in any way “agile”. I would say that cycle time should be a SINGLE month.

    Additonally, anything that comes in Define/Design/Build steps is also not Agile. Agile methods nearly always conflate the design and build stages into short – usually around two week – iterations.

    The above steps (seven months to delivery) mean you can still waste seven months effort because you deliver the wrong thing. Asking business to “sign off” on design is pointless because they don’t know what they are signing most of the time. By pushing your cycle time to two weeks, and making sure that there is a business representative full time on the team, at *worst* you waste two weeks before someone sees a result and says “that’s not what is needed”, or “business conditions have changed and so must the design”.

    The whole point of agility is to get rid of useless steps like “design” where you design the wrong thing really well. This is not to say that design is not done or that it is useless. It’s just that ALL of steps are compressed into small cycles of two week to one months worth of “define-design-build-test-deliver” by the one team working toward the single goal.

    Last week I came across a vendor calling their heavyweight SOA software solution “agile” and it made be think that “agile” is dead because now it means just about whatever you want it mean. And this is another datapoint for me in that line of thinking. Seven months is not agile. Seven months is waterfall (apparently without any testing either).

    Apart from that I usuall enjoy your column!


Comments are closed.