A Second Look at "Requirements Come Second"


and XP. Evo, for example, does consider requirements in more depth but few teams use Evo. On the whole the requirements side of the equation is absent from the popular Agile practices.

There is work, good work, on the requirements discovery process from people like Chris Matts, Luke Hohmann , Mike Cohn and even a little from myself. Several comments on the February's piece pointed to this work.

The important thing here is that this work falls outside the mainstream Agile methods; too many teams that have adopted Agile have deficient requirements processes.

Requirements more important than ever
The truth, as usual, is more complicated than it first appears. Some people have interpreted "Requirements Come Second" as a call to ignore requirements. In fact the opposite is the case: business alignment is more important than ever.

Consider a company that is initially stuck in the maintenance zone with falling sales. They adopt Agile and their sales improve by 13% on Bain's figures. Agile has done a great job!

Now if they can stay effective and get aligned sales will improve by 24% more. Being aligned with good requirements has real benefit. Ultimately it generates more value than simply becoming effective alone.  

Achieving alignment
While many companies will continue to struggle with IT some will, by adopting Agile and other techniques, succeed in creating effective IT groups. Of these some will take the next challenge and improve the alignment with business need and strategy.

Managers need to lay the foundations of improved alignment even as they start the Agile transition while taking care to avoid the alignment trap. Its as if the first runner in the relay race has started and the second must be ready to pick up the baton. This means building a corps of skilled Product Owners.

We need to move beyond talking about the Product Owner in terms of the Agile cycle. Backlog management, user stories and such is all-necessary but does not go far enough, there is much more to being a Product Owner than is commonly recognised.

Product Owners need to look deeper into the application domain, understand users and the business, then have the vision to create roadmaps. However the skills needed differ depending on nature of the organization.

In companies that create software products - ISVs and others who generate revenue from the sale of software to multiple customers - the Product Owner roles need to be staffed by Product Managers.

Conversely, in corporate IT departments and service providers - companies which create software for their own use or for the use by a single client - the same role needs to be staffed by Business Analysts.

The Product Owner role is actually two different roles that present the same interface to an Agile process. Correctly staffing the Product Owner role to match corporate need is the first step in aligning Agile teams with business needs.


Original Agile Journal article , Requirements Come Second

Further reading

Original publication in "Avoiding the Alignment Trap" in MIT Sloan Management Review, October 2007.

User Stories Applied, Mike Cohn, 2004, Addison-Wesley

Innovation Games, Luke Hohmann , 2006, Addison-Wesley

About the Author

Allan Kelly is a London-based consultant and interim manager specializing in Agile adoption. His first book, Changing Software Development: Learning to be Agile  was recently published by John Wiley and Sons. He is a qualified Product Manager and Project Manager, and holds a BSc in computing and an MBA in management.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.