Does the Agile Manifesto "forbid" writing down requirements?

Hey, CMMI Appraiser – I’m a member of an an agile team for a Maryland contractor to the National Institutes of Health. We just started designing a fairly complex financial system for NIH, but one of my teammates is adamantly against writing down changes to the requirements. He says the Agile Manifesto forbids it – but our boss clearly thinks it’s important. Does the Agile Manifesto really forbid writing down the requirements? ~ Carol W.

Carol, I had the same conversation with an XP team a couple of weeks ago. They said, “We don’t see any value in writing down the changes to the requirements. Business value is in our software, not in documents.”

Suffering through unclear requirements is not a question of "if" but "when" on any project team.  In my experience, anyone who says that has never suffered from the confusion and chaos that inevitably occurs when a team loses track of the current state of requirements (just ask any tester or customer).  In the case of your colleague, I strongly suspect he is mistaking the Agile Manifesto, a very well thought out, disciplined set of guidelines, for the "Lazy Manifesto."  Only one of those approaches is going to help make your company great (hint: it's not the Lazy Manifesto).  Let's take a look at what the Agile Manifesto actually says (with compliments to Sutherland, Jeffries, Beck, Schwaber, Beedle,  Cockburn, et al):

No doubt you've seen this before.  At this point, the Agile Manifesto is so familiar that a mythology has been built up around it. After listening to so many people talk about it I get this mental image of a gang of brainy geeks climbing up a mountain-side, complete with crampons and ice picks, setting up a smoke lodge, and sitting there on the mountaintop for a couple days. Smoke fills the teepee, and on the last day, out comes a puff of white smoke along with the Agile Manifesto, along with a torrent of hundreds of conferences and books!  Everyone in the teepee goes on to become a superstar and software is defect free and on-time forever!  Did I mention the rainbows and unicorns?

It turns out these folks got many things right … and one thing REALLY right.  Collaboration and communication  (and the structure to encourage them) are pivotal for creating great software.

They were also smart enough, as the founding fathers and mothers of "Agile," to say about the stuff on the right: “This stuff is important too.”

But somewhere along the way, too many people took a paper cutter to this document, and focused only on the stuff on the left.  This may be why your colleague is confused.  This is where comments like "business value only exists in code" came from.  That is ONE of the places business value exists, perhaps the most important, but not the only place.

So, IMHO, it is important to write down requirements.  Does it have to be a huge, heavy specification?  No, it can be as simple as sticky notes or maybe in a tool like iScrum or Process Focus.  Applying discipline to your Agile methods will help your team, customer, and boss understand the business issues at stake. This will help make your team more successful and put you in position to take on larger, more complex projects.

To be clear, when I say "apply discipline," I don't mean rigidity and useless documentation.  Of course we care more about the stuff on the left.  Just remember the stuff on the right is really important too.

Sounds like your colleague is about to get his first experience with that.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about running a successful CMMI program.