Agile - Working Software

Agile – Working Software

This is part 2 of 4 of my continuing series that looks at each of the high-level principles from the Agile Manifesto, today we tackle the concept of valuing working software over comprehensive documentation. I’ll admit that this one was tough for me initially.  I love documentation, and when I was in IT Operations, I used to say that I could tell the level of quality of an IT department by the quality, completeness and accuracy of their documentation. 

In software or product development, it can be helpful to put some things on paper to get organized and communicate what we are trying to accomplish.  I believe the authors of the Agile Manifesto were attempting to address the tradition of spending weeks, or even months, trying to think of every detail of the design and requirements and document them all before starting development.  I saw a news item the other day that Boeing was contracted to spend $170M of taxpayer money to “determine the capabilities” of the new Air Force One planes.  The actual development of the planes will likely be in the billions of dollars.  Spending $170M on comprehensive documentation is so crazy it is hard to grasp.

Agile software development suggests a different approach.  Do only enough documentation to get started. Depending on the complexity of the project, that may be very little documentation, or it could be a relatively detailed systems architecture design to make sure that all parties understand the constraints and overall system design.  There is no “one size fits all” answer to how much documentation is needed.  I mention constraints here because this is one aspect that I do believe should be clearly stated up front and well understood by all involved.  If we know we have specific budget, regulatory, technical, or time constraints for a project, they should be documented and communicated, with context, to the team before development begins.  This is a good time for some documentation.  Describe the constraints and the impact those constraints may have on the approach the team will take to achieving the desired outcome(s).

It is also appropriate here to talk about the definition of done (DoD).  To conclude at some point that we have successfully created working software we must have a clear understanding of what we are trying to deliver.  This leads a little bit into the next article, which will talk about customer collaboration being valued over contract negotiation, but it is important to note that we may need to write down the definition of done (acceptance criteria) so there is agreement before we build something.  This reduces the amount of rework and dissatisfaction with deliverables. So, again, this agile principle should not be interpreted as we don’t need any documentation.

So, what do we mean by “working software”.  This means that every development iteration needs to deliver value as demonstrated by working software and value as understood by the stakeholders.  That doesn’t mean the software must be perfect, or fully functional (although we should always try to hit that level of quality), but it should be working well enough to demonstrate to stakeholders.  In the very first iteration the working software may look like a simple “Hello World” app to stake holders but it still demonstrates that the development environment is setup and the pipelines to compile or otherwise deliver working software are in place.  You might call that “Sprint 0” so there isn’t confusion about the development velocity. I’ll note that some recent articles have also described having a design sprint called “Sprint 0”. I would say my use of Sprint 0 to setup the development environment is not incompatible with a design sprint approach. You should make sure you have time to do both within the time allocated for that sprint. 

The importance of this ability to demonstrate working software to stakeholders with each iteration cannot be understated.  It is absolutely core to being Agile.  When we demonstrate working software to stakeholders there is an opportunity for feedback.  At every iteration, we challenge our previous decisions and expose what we have learned so far.  Did you read my first Agile article, Agile – Chasing a Moving Target?  When we are developing software, we are chasing a moving target and each iteration is our opportunity to reflect, observe, and adjust as necessary.  We need to have working software so we can get that feedback that will tell us if our previous assumptions about the design or requirements hold up.  Finding out quickly that something we thought would be good, isn’t that great, isn’t failure, it is invaluable information.  Fail fast and fail cheap.  If you are spending time on something that isn’t good or isn’t going to lead to the desired outcome, you want to find out as quickly as possible.  Deliver working software at every iteration so you can get feedback and adjust to it.