Agile vs. The “Big Dog” Feature

(First published back in 2010, this article is still apropos and I thought it was time to revive it.)

Managing big features using agile

This post originated as a comment on the Cranky Product Manager’s blog, responding to her post on agile methodologies. She said

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, was super-happy that I clarified that.

How waterfall falls down

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:

• You have to know up-front what your end game is – which makes it hard to respond to market changes
• 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
• 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.)

How agile lets you tame the big dog

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 can’t solve every problem, but can tame a lot of big dogs

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.

Your thoughts?