Read My Lips: Requirements Provide NO Value!

Written by Robert Galen on September 20, 2010. Posted in Articles.

I was telling a colleague the other day a coaching story that I found somewhat humorous. I was visiting a potential client not that long ago and my timing was just right. That day they were running their sprint reviews, so I asked if I could attend and they generously agreed.

I remember each of the teams showing PowerPoint presentations that represented the results of their 2-week long sprints. They had apparently spent hours on the slides, searching the web for interesting artwork and photos that somehow represented the features that they’d worked on. They worked incessantly to match their slide prose to the images and try to tell a very compelling and humorous story that captured their overall sprints efforts.

From my perspective, alarm bells went off after the first review that I attended. Something was amiss. It struck me that the team unfortunately didn’t understand the fundamental point of sprint reviews nor one of the core tenants of agility.

So what was missing you might ask?

They forgot the software in the sprint review. They literally had shown no working software-not one bit! You can show all sorts of things in a review, but the most important doesn’t revolve around PowerPoint or documents of any kind.

No! It’s in showing honest to goodness working software. Software that has been thoroughly tested, verified, and “accepted” by the customer. In other words, creating value by instantiating your requirements in software. That’s what its about and the Agile Manifesto thoughtfully reminds us of that in one of its four core tenets.

We Prefer Working Software over Comprehensive Documentation

It’s not to say that the team was entirely wasting its time. Sure, connecting with the audience was important-as as showing creativity and engagement with the project. However, the entire point of software development is producing software that has value in the eyes of the customer that is directed by the customer towards addressing their most pressing needs.

So as I was leaving the client, I shared this insight with their coaches. As time has passed, they’ve become much better at demonstrating working code and it’s made a huge difference in their customers’ perception of the value the team is delivering.

Nice Story, But What’s the Point?

Extending from the story, I think that we need to approach software project documentation (the wide variety of plans, status reports, regulatory checklists, and most importantly for this post – requirements) from the perspective that it serves no eventual purpose except delivering working software.

The documents have no value independent of the software…none!

So am implying that we don’t need any documentation? No, nothing could be further from my point. But we must stop producing documentation as if it’s a salient deliverable on its own. It’s not! Requirements are intended to drive the evolution of a product, nothing more and nothing less.

Can you sell them to a client? No! Are they tangible without the software? No! Do they usually stay current with the software’s evolution? I’d say quite rarely, so they can easily become dated and inconsistent.

So, What are Some of the Key Attributes of Working Software?

So if working software is our ultimate goal and value proposition, let me share a few key attributes that come to mind:

Working software drives feedback. Not by reviewing a document or diagram, but by observing the behavior within a running system. It exemplifies that old adage that a picture is worth a thousand words. Working software is worth immeasurable words.
Working software is the great equalizer. You’re not 90% done or “almost there”. You can either demonstrate the feature or you can’t. It works or it doesn’t. Usually in a more robust environment that is established and stable.
Working software doesn’t always have/need a UI. It does need some mechanism to share behavior and workflow in a fashion that can be exposed to and simply explained to your stakeholders, but don’t get caught up too heavily in UI exposure under all circumstances.
Working software is a confidence builder. First, with you stakeholders. It takes us from the normal hand-waving associated with documentation and requirements and brings us visually into focus for their perusal.
It also builds confidence inside the team. It should progress, in small chunks of understandable and simple functionality. It facilitates the team working together to deliver on a small and achievable goal. They inherently want to get to the next piece.
Working software focuses us on testing, making the feature work, checking design quality and exception handling. Checking acceptance criteria with our customer early in development; gaining their feedback and making adjustments.
Working software is done. Think of it as inventory. We should be able to put it on the shelf and declare this small section of the product complete fully ready for adding or integrating with other features. The customer is convinced that it meets their needs.
Working software includes all of the software. Unit tests and functional tests can be a part of the effort. If the software works-so do the tests.
Working software is continuously working; meaning it can’t regress. If we had it working once but now its broken, then making the software and the associated tests work becomes our highest priority.

Wrap-Up

The key discussion here isn’t about requirements. Nor is it about artifacts. It’s focused towards the BA’s role in guiding your products towards working software. I’d argue that the largest part of your value is here. Not in writing or reviewing or updating or interviewing or drawing, but in taking all of these activities and driving them into effective execution and articulation within your software. Making it work as viewed and assessed by your customer.

That’s where true value lies and I hope you start skewing your attention more and more in that direction.

Don’t forget to leave your comments below