Imagine that you are sat down in a restaurant waiting for your meal to be served. Now imagine that the chefs bring your meal out to your table & proceed to eat it in front of you, describing the meal as they do so. What would you do? What kind of things would they be saying about the meal?
Aside from getting upset that your meal is being eaten in front of you, what kind of message would the chefs being sending about their dish?
Do you think the sous chef will be talking about the overly-bitter, burnt tasting sauce? Or the grill chef will be pointing out the poor quality of the meat? Unlikely.
Now bring this idea into the development context – only you’re now one of the chefs, the customer is the business stakeholder & you’re delivering software, not food. How do you think your stakeholder would appreciate not being able to get their hands on the software that they’ve ordered?
Typically, in an agile development cycle, the development team are looking to deliver small pieces of functionality to the stakeholders in order to get feedback on code they have already written.
This feedback takes the form of a demo (or showcase) of the functionality developed so far. It helps all the stakeholders involved in the development see if we’re still building the right thing.
For me, the importance of this demo is to let the stakeholder get hold of the software. Actually using the software fires off different thought processes, different questions & ultimately is more likely to get us to the holy grail of the stakeholder saying “that’s not what I want”. This is great, because the next words out of their mouth generally are what they want.
Well, is that the purpose of a demo in this context? Should we wait until the software has been released into the Production environment to find out that this software isn’t what was asked for? Or would we rather find out now, in the relative safety of our office that the software we have delivered isn’t what the stakeholder wanted?
Even better, why not invite the customer into the kitchen (or take the kitchen out to them) so they can see their dish being prepared?
If your stakeholders are available and willing, why wait for the formal showcase at the end of an iteration? Get them involved sooner so they get more opportunities say “that’s not what I want”.
Agreed, my restaurant metaphor can only go so far, but for the purposes of this post it demonstrates the fact that stakeholders should get the chance to try out the software so that they can make their own judgements about its suitability.
Let the stakeholders eat their meal, don’t eat it for them!
