What does being agile really mean? When we talk about agile, we often talk about unit testing, stand up meetings, collective ownership, etc. These are very important and valuable practices, no doubt. In fact, these are important implements. But, that can't be what agility is all about.

In addition to these general good practices, we often are given other recommendations like keep the iteration short, demo your application to the customer representatives at the end of iteration.

The Agile Manifesto says that we must value

"Working Software over Comprehensive Documentation."

There is one important 'r' word that still needs to be emphasized. Without it, that is not much use doing any of these. That word is 'Relevant.' Is the software you're developing relevant?does it serve the purpose.

In "Agile and Iterative Development: A Manager's Guide", Craig Larman presents this grim picture of the actual usage of requested features:




This shows that only about 20% of what is developed on projects actually get used. About 65% is waste. What does that mean? We're working very hard to build not capability, but unnecessary complexity into applications.

It's not important to only build the software right, we need to ask if we are building the right software. Does the software we build actually solve the problems for our users. One way to achieve this is to constantly check with our customers to see if they find what we are building relevant.

When we were writing the "Practices of an Agile Developer," (PAD) Andy and I discussed about the Rhythm in developing software and what goes on at the end of iteration. We felt that something was missing in most recommendations that suggest demo at the end of iteration. Demo is nice, but often does not bring out the in depth discussion and focus that is needed to see if the software actually solves the actual problems as the understanding of it changes.

We asked ourselves what gave us the most success. Having the key customers and domain experts (those who feed us with input and provide us feedback) actually exercise the application helps us a great deal. So, in PAD we presented this picture in the practice entitled "Use Short Iterations, and Release in Increments":




Have your customer representatives and domain experts exercise your application from day 1.

Yes, from day 1. You may not have significant functionality on day 1. However, I am amazed at the quality of feedback I receive when they actually exercise the application. For instance, feedback like "Hey what unit of measure are you using, do you know we need to be switch between Metric and English?" have been very valuable and I have gotten these in the first few days of projects when the customers started working with the application being created.

Constantly seek answer to the question "Are you developing a relevant application?" Do not only focus on developing the software right. Focus on developing the right software as well.

The goal is not just to develop working software. It must be to