One of the corner-stones of the way we do things is our weekly project demo.
The production of a weekly live system establishes a natural rhythm that keeps the project on track. It creates a natural focus for activities and keeps everybody honest. It also means that you have a working system at all times that you can use for your own demos.
We do things this way to avoid common failure scenarios for software projects. In the classical project management approach, the written specification is supposed to describe the system that is to be built. In practice, the developers disappear for a period of time, and then reappear with something that is an approximation of the specification. If you’re lucky, it isn’t too bad, but you’ll still have a mountain of bugs and changes. If you’re unlucky, it’s very far from the mark, and the schedule has just been blown out of the water.
In both cases, you end up fighting with the developers about what was or was not originally in the specification. If the consulting company has been around the block a few times, you’ll be filling out change request forms (and paying for them) all day long. The outcome is deeply unsatisfactory.
This scenario can happen to any project. It is particularly likely to happen to innovative rapid-delivery projects, the ones we build. Any element of the unknown, and the risk grows exponentially.
The weekly project demo goes right to the heart of this problem.
The goal is to shine a spotlight on misunderstandings and misconceptions as quickly as possible. You are able to say directly, on the call, “Guys, this is not right, I need you to do it this way.” Because these course corrections happen week in, week out, the project never strays too far from the target, and there are no nasty surprises. It’s hard to go too far wrong in the space of week.
Many project methodologies insist on regular meetings. Some even require daily “standup” meetings for the entire team. This style of meeting degenerates into going round the houses asking each person for a status update. It is only human nature that team members will embellish progress and downplay issues, so as not to fall behind their peers. The very structure of such meetings makes them fail.
Meetings that are based on a physical demo have a much more dynamic and practical feel to them.
The physical reality of the demo drives the discussion and keeps everybody focused on moving things forward. Because the opportunity to hide behind process has been removed, team members feel much safer discussing risks and challenges. Process-based project management is easy to game, and developers are nothing if not capable of bending systems to their will.
The final trap to avoid is the use of smoke and mirrors. Our demos are live. That means they are deployed to a server in the cloud, just as the live system will be. They are not run from developer machines. You can press the buttons, turn the dials, and break stuff. And after the meeting, the demo is left running. You can refer back to it anytime you like.
We’ve found that these demos are essential to successful project delivery. They provide a quick turnaround feedback mechanism. This keeps things correct and focused. Problems are uncovered directly and clearly and visible to all. It gives you the chance to reformulate strategy and change tactics as needed. It provides a clear and true measurement of project progress.
Richard Feynman, the Nobel physicist who worked out why the Challenger space shuttle exploded, put it best:
“For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.”