Requirements: The next challenge for Agile

Continuing my follow up to my latest tell of the Alignment Trap in the Agile Journal and on InfoQ.

Lets get one thing straight: I’m not saying requirements don’t matter.

What I’m saying it: when the context is a broken development organization the most important thing is fixing the delivery process.

In which case, you can, and should, take liberties with the requirements process. Then, when delivery shapes up you should come back and fix the requirements issues. Because requirements is where the long term gain is.

Anyone who thinks I don’t value requirements should look at all the postings on this blog about the importance of Product Managers. The requirements is also where the long term future of Agile is.

Look again at those 4 quadrants:
• Maintenance zone: this segment explains why so many of my friends work at dysfunctional IT shops.
• Alignment trap zone: this explains the traditional approach has failed so badly; companies tie themselves in knots trying to do the right thing when they can’t actually do very much.
• Well oiled IT: this is where Agile takes you. But it leaves you there.
• IT Enabled growth: where we all want to be.

Most companies are currently stuck in the maintenance zone. There are three types of company here:
• those who are happy in the mud; i.e. those who lack the will to do something about it, those who believe IT is always like this, those who earn so much money elsewhere it doesn’t matter.
• those who are trying to move to the Alignment Trap; many will still be drinking “do the right thing” cool aid and are making it worse for themselves
• those who are trying to get to the Well Oiled IT, probably via Agile development

The downturn will finish off many of the companies in the first two groups. Those in Well Oiled will probably be OK, and those who can move quickly will hopefully survive. Still, too many companies will survive despite being stuck in the Maintenance Zone.

There is a whole Agile industry (including me!) helping companies make this shift. To be honest, I’ve come to the conclusion that this is the easy bit. (Don’t believe me? Call me.)

But, what do you do once you get to Well Oiled?

The problem is that while Agile as we know it will get you there it won’t take you any further. It runs out of ideas.

Companies could happily stay in Well Oiled, its a (relatively) nice place to be. And you will probably out compete your competitors. But some of the companies that make it - and those who are already there - will look to go further.

This is where Chris Matt’s point on the Agile Journal site are relevant. Agile as we know it, has largely ignored the Business Analyst and Product Manager roles.

The onsite-customer in XP lacks any kind of strategic view. It worked for the C3 team but they were just replacing an existing system, not inventing a new product or doing great innovation. Even so, the original customer nearly had a breakdown.

Scrum is slightly better, it has a full Product Owner role, but it says nothing about how this role is undertaken. It only speaks about the Product Owner in the Scrum process.

And Chris is right about “user stories.” They are a simple tool for communication with developers. They are not sufficient. To make matters worse most teams use them isolation, they do no adopt scenarios, actors or personas.

How do we fix the problem?

Here are three steps to get started:
1. Recognise the importance of the Product Owner role and staff it properly. You need 1 Product Owner for every 3 to 7 Developers. The newer and more innovative your product the more you need. If you have an older less innovative product you might have 7 developers to 1 Product Owner.
2. Stop looking to Project Managers to fill the Product Owner role. They are not Product Owners and their training is very different.
3. Decide whether Product Owners in your company are Business Analysts or Product Managers. If you develop software for your own internal use (or one client) then they are BAs. If you sell your software (shrink wrap or online) they are Product Managers.

If we are to move beyond Agile software development and build Agile companies it is essential we respect requirements. So far our success has all been based on shifting out the maintenance zone, the next challenge is to move on up.