Requirements Come Second


This move itself is a significant benefit to an organization and may be enough to justify the Agile change alone.

This shift was possible because many of the practices and processes advocated by the early Agile methods can be adopted by developers without significant management involvement. Coders can simply start writing unit tests first, they can start refactoring they can set up a continuous integration server. Little management involvement or approval is needed for these changes.

As a result the early Agile successes have been bottom-up successes. Developers just do it. Conversely there is little managers can do to impose many of these activities: only developers known when refactoring is appropriate, forcing TDD can lead to meaningless tests producing evergreen test bars, and how is a manager to know when a design is the simplest possible and when it is not?

Neither is it possible for an organization to transition to Scrum by edict. No manager can force a team to be self-organizing simply issuing an instruction that a team will henceforth be organizing themselves.

So teams can adopt Agile practices and improve their performance, even move themselves to the "well oiled" quadrant. But addressing the requirements flow requires management authority and support.

For an organization transitioning to Agile development requirements present a paradox. To be truly Agile, and to learn from Lean, requirements must be arranged so that those with the greatest value, those which will actually be used, are developed. Yet addressing this issue at the start of the change to Agile risks making the overall position worse.

Resolving this conundrum is a matter of sequencing. At the start of any transition the focus needs to be on the development teams and practices, initially the requirements process should be left as it.

This means adopting engineering practices, routines and organizational structures which allow requirements requests to flow smoothly through the system. Requirements go in, working software comes out.

The first benefit of improving the effectiveness of development first is to build trust. Seeing working software delivered they will involve themselves less with how IT works.

Once trust is established more benefits flow. When customers can discuss requirements not just in terms of what they want but relative priorities. Conversations can move on from "When will it be delivered?" and "Why isn't it working?" to those that matter, about what is required and when it is needed by.

From here it becomes possible to fix the alignment issue and move from "well oiled" to "IT-enabled growth." As Bain says: "Contrary to conventional wisdom, the path to IT-powered growth lies first in building high effectiveness and only then ensuring that IT projects are highly aligned with the business."

What next?
So the message is clear: The first step in Agile adoption must be the fix the delivery machine. Improve the effectiveness of the development group.

As effectiveness improves focus can switch from how to what. The changes required here are if anything more far reaching. They are also more long-lasting.

To date Agile methods have had relatively little to say about requirements and business alignment. The current crop of Agile methods largely focuses on development and project management practices. As more companies adopt Agile - and become well oiled - we should expect to see a renewed focus on requirements discovery and business alignment.

[1] Implementing Lean Software Development, Poppendieck amp; Poppendieck, 2007

[2] Avoiding the Alignment Trap in Information Technology, Shpilberg, D. et al, MIT Sloan Management Review, Fall 2007.

About the Author

Allan Kelly is a London-based consultant and interim manager specializing in Agile adoption. His


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.