Ah Ha! Moments from the Great Requirements Showdown

By Chris Sims

Tonight, at the North Bay Agile meetup, I facilitated "The Great Requirements Showdown!"  It's an experiential exercise that pits traditional written requirements against the agile alternative: user stories and face-to-face communication. 

During the workshop, participants wrote down their 'Ah Ha!' moments and we shared and talked about them.  Here are they are:

• Too much detail is at least as bad as too little.  Time-boxed "good enough" requirements work better.
• One group (requirements writers, in this case), trying hard to do a good job, can actually cause harm by using up too much of the schedule.
• Teams working on the requirements (upstream process) used up most of the time, leaving the developers (downstream process) with little time to turn the requirements/specs into a product.  Great requirements are worthless if there is no chance to implement and ship.
• Late commitment resulted in poor deliverable.
• Integrating even small increments of work can be more difficult than it seems, and lead to a poor quality 'whole'.
• We wish we would have used continuous integration!
• What is important is not always obvious.
• We didn't have enough context or vision to know what really mattered and what didn't
• Optimize the process to focus on what is most important.
• Ask the customer!  Find out what matters most to the customer, don't assume!
• We never thought to consult with the customer!  Why is that?
• Face-to-face communication between the developers and the requirements team resulted in much higher product quality than using written communication.
• Feedback is a good!
• Feedback is everything
• Positive feedback, especially confirmation of "done" is important.
• Without feedback, the process and the results suffered
• Use all available means to communicate (In this case we wish we could have used drawing in our requirements).
• Precision in language is really important (and really elusive).
• Verbal instructions leave open ambiguity, which sometimes gets translated correctly.
• Sometimes set-based development (working on multiple solutions in parallel) is a good way to find the best possible solution.  Watch out for emotional reactions from the people whose solutions aren't chosen. 
• I hadn't ever thought about set-based development as an alternative to pair-programming.
• Serendipity!  Sometimes you just luck out and build it right.
• Sometimes the end product matches the requirements by accident!
• Good requirements speed up development, like a good road map.
• Requirements done quickly are ambiguous.
• Perspective matters!
• Simplicity!  Focusing too much on the details can distract you from the big picture.
• Pair-programming concepts can be applied to creating requirements documents.
• Communicating only in writing leads to 'us' and 'them', collaborating leads to 'just us.'

Have a comment or question about any of these?  Leave a comment and share your thoughts.

Cheers,

Chris

Comments

[Mr. Hericus]

I've run into at least 18 of those "ah ha!" moments with a customer, and just on the most recent project I consulted on :-)

It's important that everyone participates, has buy-in, and has the most effective communication means available.

Thanks for the post!

[Steve Bockman]

I attended this workshop and had a great time. The difference in personal involvement between "throw it over the wall" and collaborative development was obvious, the latter feeling much more rewarding. Gathering people's "Ah Ha's" was a nice touch.

[David Locke]

Face-to-face doesn't happen when coding for market segments. The only place where you get the face-to-face is in IT shops where you are coding something other than an integration application.

Integration applications are a FAIL. With integration applications, face-to-face fails, but it's more because the idea of an integration application is false.

The minute you prioritize users, fail to find their cognitive model, aggregate users, deliver averaged functionality, its a fail regardless of how the software comes into existence.