Background
I have recently been in several situations at work as well as discussions with friends from different projects and companies which all echoed of the same problems. This led me to realize that the role of demos in agile development can be very tricky and very dangerous to the code quality when abused.
So, what are demo's purposes?
There are two main types of demos:- End of iteration demo / Real value demo - presenting what was actually completed.
The purpose in this case is showing real value to the customer, getting early feedback on actual features that were agreed upon, and not least important, as one of my managers recently realized - looking in the mirror and "facing the truth" about our real progress. - POCs - as suggested by the name, this kind of demo is usually only for proof of new concepts, usually implemented in the bare minimum way that allows the customer to receive some tangible idea of the features, but not more.
This is a very important phase as it allows for very early feedback and if used properly, can achieve great customer satisfaction (and developer too, because who doesn't like receiving good reactions to software he's written ;)
Both kinds have many advantages, and I believe that the more frequent the better (though they should be balanced carefully with the overhead they create).
I will not elaborate much on this as these are widely accepted and practiced notions.
Where it gets tricky
BUT - what happens when there is no or little distinguishing of the two?When it's not clear which one of them it is that you are working on, or even worse - when you’re expected to do "some of both"?
This seems to be a dangerous pitfall for teams to fall into, usually created by pressure from clients or upper management.
You start a new project and POCs of many ideas are required quickly for various good reasons - internal marketing, feedback collection etc.
But the project also has to get some real progress done quickly in order to.. well, show progress.
This is a real need that requires balance, which is hard to find.
As long as it at least realized that balance and distinction between the two are needed, it may be hard to do but it will still be possible to create a maintainable code base as you go.
When you first hear the words "of course a single iteration is not enough to build the feature properly, but can't you make sure that you demo the whole idea behind it and still write the code well and use it to continue building" - this is when you should get really worried.
This leads very quickly to hacks, patches, or simply lack of design that stay alive in the code base much longer than the developer would have ever imagined.
See phrases like "Coding Horror" and "Big Ball of Mud" to appreciate just how bad and demoralizing keeping throw-away code can be.
And then you find yourself, many iterations after the demo was shown, still working around bits of code you would have never considered to be worthy of checking in, wondering why..
A really good description from the above link of the dynamics of this happening:
"when you are prototyping a system, you are not usually concerned with how elegant or efficient your code is. You know that you will only use it to prove a concept. Once the prototype is done, the code will be thrown away and written properly. As the time nears to demonstrate the prototype, the temptation to load it with impressive but utterly inefficient realizations of the system’s expected eventual functionality can be hard to resist. Sometimes, this strategy can be a bit too successful. The client, rather than funding the next phase of the project, may slate the prototype itself for release. "
Possible solutions?
As I said, the balance is hard to find.Several ideas could be to:
- Decide in advance for each feature what the current iteration's purpose is.
If it's for a POC, realize you are writing throw-away code and don't even try to do anything more.
And be adamant about it being throw-away code.
If it's not - be as equally adamant about not adding any quick fixes just so the demo contains one more feature which isn't really a feature yet. This is the "looking in the mirror" part.
(and avoiding the "a bit too successful" danger) - Implement POCs separately - by different people on a separate branch, so there is no option for demo leakage to enter your real code.
- Decide that for some features it isn't necessary to have the feature integrated into the real product at all and display the ideas with some form of interactive mockups
I'm sure there are more options, and sometimes even having them all doesn't guarantee an easy solution.
The bottom line I guess is to be wary of demo leakage and consciously take measures to avoid it.
