How often do you demonstrate your development builds to your customers during development of a release? Unfortunately if you are like most agile teams that I encounter the answer is not very often, if ever. If you are practicing agile software development you know about the importance of working in short increments. But do you really extract all the value you can from your iteration? Let me elaborate with a real life example I encountered recently.
About a month ago I traveled to a customer site to discuss EAF’s future direction. After the meetings, we headed back to the airport for the return flight. I had been up since 4:00 A.M. and I couldn’t wait to get home. As I approached my gate, I learned that my plane had been delayed for maintenance issues. As I had just made the travel plans several days earlier, I knew that another airline had flight back to my hometown and that I could probably get a seat on that flight.
This is where my frustration began and the inspiration for today’s post. When I asked the gate attendant if the other flight had a seat available, here is what ensued:
Me: "I am pretty sure that American Flight 5455 is traveling to St. Louis in an hour. Can I get on that flight?"
Gate Attendant: "Sure let me check my computer…" click click click click click click click click click….
Five minutes later
…. click click click click click click click click click ….
"… hmmm… I forgot the sequence code. Oh yeah ‘next next list list’" (Don’t ask me what that meant.)
….click click click click click click click click click …
"… Why yes Mr. Groner, I can get you on that flight"
Not only was I tired and frustrated, you should have seen the impatient people behind me as they waited for my question to be answered. I kept thinking to myself… "This must be the most unfriendly user interface ever built. Couldn’t they have done something to make this smoother for the gate attendants?"
Every iteration should end with a demonstration to the customer
I’m sure that the attendant’s reservation system was built years ago with non-agile methods, but just think what could have been built if a real gate attendant would have gotten a chance to see the system every two weeks as new functionality was added. I’m sure early along the way an attendant would have said "You have got to be kidding me. I can’t be typing for minutes just to get someone’s flight switched. You have to re-architect this interface."
Admittedly, my gate attendant example is a bit contrived, but the take away is the same, regular and often demonstrations from developers to the user base is an essential agile practice.
Consider the benefits:
- Obviously, the immediate user feedback it essential to agile practices. How else are you going to course correct your development efforts from iteration to iteration if the customer doesn’t have a good sense of the work product as it grows?
- During iteration planning, developers know they have to focus on complete features as they are going to have to demonstrate them in a short time.
- Customers have the pressure of clearly articulating their user stories. It’s a very easy for developers to say "so really, in two weeks what are you expecting to see this application do?"
- In my opinion, demonstrations combat scope creep and pressure the team to get done on time. Knowing that you will have to get up in front of your customers at an established time in the future will keep your focus on the task at hand.
- Demonstrations promote the DONE=DONE mind set. At almost every end of iteration demonstration I go to I hear at least one user say "Can I have this build now? It is useful to me already". It’s hard to accomplish that with half completed stories.
- Finally, the demonstrations greatly improve communication paths and confidence between the business and engineering side of the house. See my post on regular, small releases as I go into detail on this.
It’s sad to me how many teams I encounter that consider themselves "agile" that don’t follow through on this practice. I find it essential and addictive. If you don’t do this in your organization try it, just once. At the end of your next iteration plan establish a time for the demonstration with the customer. Watch how it influences all members of the agile team. You will be glad you did.
{ 3 comments }
What we do which you might have eluded to is to have the customer as the final sign off for each story during the iteration. Once our QA individual verifies that all acceptance criteria for a story are complete – we put the story before the customer who verifies it as well (based on acceptance criteria which he/she specified). Only then is the story considered “DONE” and the points to be counted towards the velocity of that iteration.
I think the demonstration of the stories completed would be enlightening and motivating for the other stakeholders who attend our iteration planning meetings at the beginning of the next iteration.
I would go one step further – usually the contact with the customer is not a representative sample of the users – go straight to the users, whether or not they are part of the customer’s staff, or the customers of the customer.
Only then is the story considered “DONE” and the points to be counted towards the velocity of that iteration.
Comments on this entry are closed.