How can I increase the productivity of my agile team? -- you're asking the wrong question

I get a lot of questions about productivity.  What's the best measure of productivity? Is it velocity for scrum teams?  What about number of stories?  How do we increase productivity?  My answer is usually met with a bit of shock:

"I don't care about productivity, and neither should you"

What!? yes you read that correctly.  Here's why: we don't need to deliver more features, we need to deliver the right features. This is one of my all time favorite charts:

Usage of features and functions in a typical system
Source: Standish Group

What this tells me is that 20% of the time we're on target, 64% is a total miss, and 19% is 'Meh'.  That's pretty bad. Do we really need to deliver more of that 64%?  

Here's an example I like to use.  Imagine a bomb.  To destroy a single target we had to do something called carpet bombing.  We had to saturate an area with bombs hoping to hit the thing we intended.  For a while we focused on getting more bombs on the planes and getting more planes in the air until someone invented the smart bomb. We now replaced hundreds of these:

with one of these:

What a smart bomb does differently is that it is constantly making course corrections.  Before there was a lot of technology invested into figuring out when to drop the bombs, now that's not even an issue, you pretty much just have to be in the right zip code and roughly the right general direction. Is a smart bomb more expensive than a regular old bomb?  Sure, but you have to buy, fly, and drop a whole lot more of the old bombs to get the same effect.

So what does that have to do with productivity?  Well, if the bombs are our features we need to stop worrying about how many bombs we can get on the plane, or how many features our teams can load into a release. We need to start worrying about how we hit the target. At the end of the day there are problems we're solving. If we don't solve a problem no one will use our features.  In military terms the problem was destroying a target, and that's what's important.  For an agile team it's not about productivity or how much stuff we get done. It's about actually solving the problem; did we meet the need.

Rather than asking about productivity we should be asking these questions:  Do we understand the customer's problem?  Are we getting feedback often and early?  Are we making course corrections? Are we like a smart bomb, constantly adjusting course and honing in on our target? Are we doing too much?  You don't need to drop a 30,000 lb bunker busting bomb to destroy a truck.

So is productivity important?  Is it important to deliver more features? Not nearly as important as delivering the right features.  If we focus too much on productivity we might find ourselves outdated carpet bombing features to the market while our competitors use a smart bomb to deliver the knock out blow.

The Requirements Document is today's Alchemy

Have you ever heard someone say this? "If only we had better requirements"

For a large portion of human history people kept trying to turn something heavy and not super valuable:

Lead

Into something much more valuable:

Gold

They didn't have a lot of success, and not for lack of trying. Once we discovered the nature of atoms we realized that they are actually two different elements and you can't actually make lead into gold.  

In modern software development people are still trying to do something similar, we're trying to turn these:

Business Requirements Document

Into these:

Happy Customers

Unfortunately, like a lot of alchemists of old, we're not having a lot of success. It's not for a lack of trying either.  The good news is that just like Alchemy was the precursor to modern Chemistry, software development is in the process of evolving into something better.  We've started to learn why it's so hard to take a business requirements document and turn it into something that actually makes customers happy.

Here are a couple of the issues that make it challenging:

First off, we know that only small portion of communication is actually written, but let's pretend that we had technology that would allow us to convey our intent perfectly.  We would still never have a perfect document simply because one person can't think of everything. One person can't predict all of the possible outcomes, or what we might learn as we develop something.  Requirements documents are flawed because they imply a hand-off.  We'll never be able to write something, hand it off, and expect it to get done the way we want.

Second, we're fighting human nature. Everyone at some point has been absolutely convinced that they need something, it will make their life easier, it will solve a problem, or will just be the greatest thing since sliced bread. Well, we get said item and after trying it out we say something to the effect of "Huh", and it ends up in storage, the garbage, donated, or turns into a white elephant gift.

What we really need to make happy customers is collaboration and feedback.  It's okay to have a statement of intent, or even better to define the problem, but what we really need is that collaboration throughout the development process.  We need the customer, or someone that understands the customer needs like a product owner, to be involved.  Help the delivery team define the problem and the solution, do it together. 

Lastly, get things to the customer early and often so that you can get feedback.  We want customers to play with it, try it out.  Tell us what actually works and what doesn't and why.  Take that feedback and use it to make your product better.  In Agile software development everything is pushing us to deliver large functionality in small batches.  One of the great advantages to doing things this way is that we can actually get things out to customers to play with before we finish everything.  We can and should change course while we're developing large functionality based on customer feedback.

There's nothing wrong with the mistakes we've made as long as we learn from them.  True, ancient alchemists never did learn to turn lead into gold, but they did learn a lot of other things that gave us our modern day understanding of chemistry. Likewise we may not have learned to create the perfect requirements document, but in the process we're learning why it doesn't work and better ways to do things.  So let's make sure those hard lessons on requirements documents don;t go to waste, and let's make happy customers!

And the next time you hear someone say "If only we had better requirements" you can answer "yeah, probably not"