Brad Appleton’s series of posts on What Is Agility? bring up the right questions, but they don’t dive into the muck, like a BBQ eater in a white suit.  Muck diving is right up my alley, as the stuff I find interesting is usually at the bottom of the pile.

There are several fundamental problems to be solved, but the most interesting, by which I mean really hard, problem is understanding what is the most important thing to do next.

In The Agility Cycle, Brad quotes a host of luminaries, including himself, in defining what that thing is.   I like Gartner’s the best, and here I’ll have to quote Brad, as Gartner won’t let me read their original:

1. Sense the need for change in the environment (includes the proactive initiation of change)
2. Strategize the available options and develop alternatives
3. Decide which path to take and commit to the approach
4. Communicate internally and externally to everyone who needs to know
5. Act to produce results and follow-through efficiently

1. Sensing the Need for Change in the Environment

Let’s start with “Sense the need for change in the environment”.  Beware of management aphorisms that sound like something you’d hear at a Yoga workshop!

Not only is it hard to tell what the need for change is, it’s as hard to agree on it as it is to get two people to agree to toppings on a pizza.  By the time your company has it’s second employee, you’re in trouble.  When you get your second customer, it’s pretty much over.

Practically speaking, there are four avenues in which we business people “Sense the need for change in the environment”:

1. Strategic Pressure.  “The future is in Cloud Computing on the i-Phone.  Get me there in six months.”  Most engineering organizations are willing to set fire to the old application and do a little resume polishing on the new one.  Nothing like starting from scratch, unless you actually want to make money.

2. Competitive Pressure.  “Your App needs to do foobar, just like that other app does.”  Now that’s going to happen every day after you ship version 0.9.  It’s unlikely that any one request requires real change, but maybe that sound you hear is an out of control semi, and it might be nice to change direction before slamming into the grill of the truck.

3. Customer Pressure.  “I’m not loading any more of your crappy releases until the .2 version, at least.”  Hey, you Windows XP users, you know who you are.  And who I am.

4. Financial Pressure.  Sales drop.  New Account sales drop.  The CFO takes away our CapEx budget.  We have to reduce headcount [or "Free people to pursue other opportunities" as they say in Hollywood], reduce hours, reduce pay.  Doesn’t take a highly developed set of Senses to know things have changed.  But what do we do about it?

It’s relatively easy to deal with Strategic Pressure: unless the pressure is coming from your CEO’s who’s an ex-Marine Karate instructor with a Meth habit: slow down amigo, and study it. Engineering is a discipline where things take time.  The worst thing we can do is change priorities faster than we can get them to market.  Change needs to require a good case.

Market of any size don’t have windows that  close in six months.  More likely people will learn that Prolog wasn’t really all that valuable, or you could like without a MS-Bob plug-in.  SOAs and the ASP business model have been around for ten years.  Before you imagine yourself as the next “i-Fart” author, ask yourself, what percentage of the apps on the i-Phone have made over $100K in revenue?

Competitive Pressure and Customer Pressure are not the same.  Competitive pressure shows up when your organization is losing business to a competitor.  Real Customer Pressure is when you can’t live up to your value proposition without making changes.  These two are the realm of Product Management.

The difference between a great product manager and all the rest is whether they can determine which customer or sales requests require change, versus the ones that go to triage and get prioritized with all the others.  Signals that you might have to really change what you’re doing are when you get demands for 10x performance improvements, or to support workflows that just don’t fit.  Patches (“now 30% faster!”) just aren’t going to make those requirements go away.  Now you’re going to have to think about how to address a new market environment.

Finally, Financial Pressure is the easiest to sense, and the least likely to activate change.  Financial Pressure tends to make organizations to freeze up.  Whether the reason was lack of product competitiveness, global recession, or a controller with a cocaine problem, the result is the same competitive and customer pressure, fewer resources to deal with it, and (unless you’ve been investing in those employee meditation session) lower morale.

Two mistakes managers typically make: trying to use the same development process, and freezing CapEx.

Improving the development process is your way out of this mess, not something you can’t afford to do.  That’s like the teenager who knows he’s going the wrong way, so he drives faster.  And, if you have the cash (or if the government is giving it out like candy on Halloween), Capital Expenditure is the cheapest way to get onto a better process.

Lorne Cooper