In Chapter 1, The Software Industry and the Agile Manifesto, we discussed the Agile values and principles. One principle, in particular, has relevance:

Deliver working software frequently, every couple of weeks to every couple of months, with a preference for the shorter timescale.

Working software is a term we use to describe software that is working as it was intended, that is, it has met all of its acceptance criteria and our Definition of Done (DoD) and is either waiting to be shipped or already has been. The concept of working software is intended to solve several problems we often run into in the software industry:

• It moves the focus from documentation and other non-functional deliverables to what we're being paid for, software. The intention of the Agile value working with software over comprehensive documentation isn't to say documentation isn't needed; it's just about maintaining the right balance. We are, after all, a software product development team, not a documentation team.

To illustrate this, if we deliver technical design documentation to our client, it will probably make little sense to them. And unless they are technical, it won't give them any understanding of how their product is evolving. Working software, however, is tangible, much nearer to its final state, and will provide them with a real sense of progress. 

• We want to deliver increments of working software so that we build up the product as we go. If we do it smartly, parts of the product can be put to use before the rest becomes fully functional. 
• It emphasizes working software because it lets our client preview how things could be and gives them an opportunity to provide relevant feedback based on the real product.

To give you an analogy, imagine we are considering a new kitchen for our house or apartment. We might look in brochures or go to a kitchen showroom to see examples of kitchens we like. We might work with a designer to establish the important key attributes that we're looking for. They might create a computer-generated concept drawing of how our kitchen might look once it's finished. It might even be rendered in 3D, and we might be lucky enough to get to walk around it in a virtual reality environment.

However, until our new kitchen is installed in our space, we won't know if it works how we hoped it would. The only way we'll find out is by using it. The design steps employed by the kitchen designer and our imagination are done to help us envisage any potential problems, but until we're hands-on with our kitchen, we won't know if it's right for us.

If it isn't, then it might be quite costly to fix a finished kitchen. The same goes for software; correcting it can be quite expensive. The later we leave it, the more expensive it becomes.

However, with the right software delivery approach, we can reduce the risk of this happening. To do this, we have to think beyond just using iterations; we have to put some thought into how we slice up our product for delivery.

For instance, just completing part of the data layer of an application, without any implementation of the user interface elements that a user will interact with, doesn't deliver anything of real use for our business. Without a technical understanding of how software is built, our customer will find it impossible to imagine how the software might look in its final state and will be unable to give any real feedback. 

The sooner we can deliver usable software, the sooner we can get feedback on whether it is useful. This is what we mean by tightening feedback loops. Let's look at how to do this.