For web applications you simply get your build script to automatically deploy the build to an internet facing server and send the URL to your customer. For thick client applications you give VNC or RDC access to a demo PC, usually located in your corporate DMZ, and send your customer the connection details.
When you adopt this practice for the first time you must communicate to all stakeholders the following in relation to having direct access to the build:
- What you will see in the build is work in progress. It is normal for untested software that is in mid-development to crash or give unexpected results. Please do not log any calls or be alarmed if the software crashes or is partially unavailable or completely unavailable when you try to access it.
- You must not use the build for demonstration purposes within your organisation as it may change significantly before the final release and may not be available when you come to demonstrate it. You also run the risk of setting the wrong expectations should the software fail or change in the future.
- Placeholders will often be used where content or functionality is not yet available to provide “scaffold” for the application.
- What you see in the daily build does NOT constitute an official release.
- All previous data is removed each time the build is deployed.
Advantages of Continuous Transparency
- Builds an enormous amount of confidence with the customer and creates a very strong relationship as they can see tangible progress and feel constantly engaged.
- Enables you to share problems with the customer in real-time. The most common problem is having an overly optimistic (unachievable) schedule. The customer can usually gauge the overall progress of the development and realise that you can’t complete all functionality on time. They actively help you to de-scope the solution to hit their deadline.
- Focuses the developers’ minds when they know all stakeholders are watching their creations on a daily basis and improves quality upstream.
- Entirely removes the risk of any surprises to the customer when the first release is made, where they would have traditionally only seen the software after many months of development.
- Flushes out change requests or fundamental requirements issues earlier on in the development life cycle. Better to find out earlier before project budget is burnt.
- If your project has major resourcing issues (I’m not talking about the odd day of sickness or annual leave) then your customer will be able to see an unexplainable lack of progress.
I have operated Continuous Transparency on all projects I’ve run over the past 4 years and it’s always been a great success.
Everyone I’ve introduced it to automatically gives me a look of horror followed by "showing the customer untested software or airing our bugs in public is ridiculous", or "but doesn’t it give the customer a chance to sneak in changes?" But once they try it and reap the rewards of success they say they will never go back to how they used to do software. Most importantly though, is all my customers have said “why don’t all our suppliers operate like this.”
I’m interested to hear comments from anyone who’s already operating this approach or is concerned or sceptical about using it.
