Several mobile phones. (Image via Wikipedia)

Do you remember this situation? You made some plans with friends, got to the meeting place, and they weren’t there. You hung around waiting, they never show, having gotten a better offer (“party with Bono, dude!”). Or they show up an hour later (“had a flat tire, dude!”). Or I don’t show up (“got in a fight with my girlfriend, dude!”). In any case, the plan breaks down and the whole thing goes off the rails.

Well, this rarely happens today. I would have called them, or they would have called me, and the whole experience would be back on track. In fact, with cell phones, our plan for the evening would be completely different to start with. It wouldn’t even be a plan – it would be a series of checkpoints. We’d review where we were and then make decisions about where to go next. Obviously, the overall goal would remain the same, but getting to that goal becomes a matter of coordinating.

This came to mind when listening to a 2005 Clay Shirky talk on the (awesome!) TEDTalks series. He said that with the cell phone revolution:

We stopped making plans – you say ‘I’ll call you when I get there.’ There’s a general replacement of planning with coordination.

We’ve all experienced the fragility of these plans – whether in our personal lives as in my story above, or at work, where we usually call it “the waterfall methodology” in software development. Once something goes wrong – or not according to plan – it can be extremely difficult to get the plan back on track.

And isn’t that just what “agile” does – replace step-by-step planning with a process of coordinating to achieve a goal? At every point everyone is in touch (if necessary) to get clarification, to make sure progress is being made toward the goal, and to ensure that indeed the final goal is worthwhile arriving at. When circumstances change (“Bono wants the product with feature X instead of feature Y, dude!”) we can adapt because we’re coordinated.

Comments?

Yes, Agile can speed up the development and improve the quality of small features.  But it’s too often at the expense of the Big Important Work — the heavy lifting, multi-month market analysis and architectural work that lead to REAL customer value and REAL competitive differentiation.

I magnanimously offered my perspective on agile, boiling it down to the key points of:

• Do the most important things first
• Be prepared to reprioritize on a regular basis as the environment changes

Or, “spend your resources on the 20% of capabilities that will get you the best return.”

So far, so good. Can’t argue with that as an approach, not just for developing software, but for living life itself. And for the self-help industry, which generates tens of thousands of pages on the Pareto Principle every year. And I’m sure CPM, as we call her, is super-happy that I clarified that.

In contrast, the old way (aka “waterfall”) is more like:

1. Figure out what you want to accomplish
2. Determine the most efficient way to accomplish it

It’s easy to see waterfall’s problems when characterized this way:
a. You have to know up-front what your end game is – which makes it hard to respond to market changes
b. The most efficient way of building the full product is not necessarily the one that front-loads the value, so often low-value items are completed and high-value items end up deferred
c. You do a lot of work up-front to document things that the developers never get to

Notice that’s not how agile talks about itself. The agile manifesto talks about working code vs. documents, and interactions over tools (it does cover “responding to change”). In fact, agile, as far the methodologies and manifesto go, is solely focused on programming. (This is changing some – I just listened to Kent Beck’s talk at the Ruby On Rails conference last year, and he’s come up with a very different characterization of the goals of agile: it provides accountability, responsibility, and traceability.)

Now, given my characterization of agile’s – indeed, life’s – key goals, you can then look at agile  methodologies simply as one way to accomplish those goals. But what if, as CPM fears, the most important capability (call it The Big Dog) takes longer to deliver than a sprint or two, and requires visits to lots of customers to understand their problems, and lots of reviews with customers to see if we’re solving their problem?

Clearly, you still have to do the Big Dog. CPM should be able to tell you why. And if the methodology doesn’t give you a way to do it, then the methodology won’t work for that product.

But chances are the 80/20 rule applies to the Big Dog, just as it applies to everything else. And this large monolithic capability can be broken down sensibly into multiple passes through the “smallest thing that could possibly work” approach. Does this require the PM to keep ahead of the development organization? Yes. Is that any different from the old days? Yes and no. The PM needs to figure out the most important part of the Big Dog (the 20%), and make sure it’s understood, there are good user stories, it’s designed, architected, etc., extremely well. After all, that’s where most of the value is going to come from.

But the PM doesn’t need to document the rest of the 80% until later – if at all. In fact, it’s likely that finishing the 20% of the Big Dog prioritized to the top of the project leaves something else – the Medium Kahuna – as the next important item to accomplish. There may be some additional Big Dog-related capabilities that are “nice to have” – and they’ll be prioritized into the rest of the project, if there’s time after getting the Medium Kahuna delivering its value.

“Now wait,” you (or the CPM) say, “I can’t live with only 20% of the Big Dog – I need 100% of it – or at least 80%” And I say this is where the beauty of the agile mindset comes into play. If you’ve completed 20% of the Big Dog, and have the rest of the Big Dog as well as the Medium Kahuna in your backlog, at this point you can decide which is more important, and decide which one to do. You’re already delivering 80% of the value of the Big Dog – now you can decide if you really need to take that up to 90%, and leave the Medium Kahuna on the table, or vice versa. You have control.

Agile is not a silver bullet, and it’s hard to get right, but if it helps you focus on putting first things first and executing on the 80/20 rule, it’s done its job.