Client demo is so damn important that it’s hard to overstate it! Not presenting working software is a brilliant way to pile up problems in the project. Yet plenty of its benefits are subtle and easy to overlook. Do your project a favor and know what's to gain or loose here.

Note: This a 4th post in my series on keeping the benefits of Scrum even if you can't do it 100%. Previous ones were about:

  1. lack of retrospectives
  2. poor planning
  3. scope changes

Demos In Real World

Scrum requires us to do a demo of working chunk of software by the end of each sprint (1-4 week of work). In real world preparing a demo is be cumbersome. We sometimes skip it because it’s extra effort to deploy on demo server. Or it’s difficult to create a test build of an application and distribute it. Sometimes we skip it because the customer is too busy to look at the small increments of the project. We omit it because there are technical difficulties that make it “impossible” to demo.

Yup, those are all valid reasons excuses to skip it. And those are exactly the reasons why we should do the demos. Here's why.

Benefits Of Actually Doing a Demo

  1. Uncovering assumptions. Demo is stressful because it's an "a-ha!" moment for the client. That's when they see how their requirements have been understood. They no longer need to imagine, assume or guess how the software works. Their expectations are immediately validated by the working product. At the same time all the assumptions that the team has made are also becoming visible and can be discussed. This single point is worth all the extra Scrum effort. It's an antidote to the waterfall-style disasters.
  2. Putting pieces together. To present working software the team needs to go through the effort of integrating it. To check if the pieces work together and fill-in encountered gaps. This reveals problems and omitted parts. That's why it's often problematic. Moreover those gaps tend to accumulate over time and create a hidden bunch of work on integration the longer we go without a demo.
  3. Showing progress. We, humans are simple creatures. Things we don’t see are the things that don’t exist at subconscious level. You may think you can measure progress by tickets closed or code delivered. That’s bullshit. Until the client sees what’s been built and how it works they can’t feel the progress. You need to make your work tangible.
  4. Feedback. Working without external validation is like floating in space with no point of reference. Demo makes the product concrete and debatable. Everyone can give and receive feedback, which is crucial to building what’s actually needed and makes sense.
  5. Identifying gaps. There’s things the client forgot to mention or assumed. There’s things that development team has omitted. Thanks to demos you can catch them.
  6. Ownership. The demo should be conducted by the developer (someone on the development team). Why is that important? Because it creates the sense of ownership over the software being build. Team members start to feel the responsibility for what they build when they show it to the client.

Risks of Skipping Demos

Not doing demos is surefire way to generate some subset of these problems:

  • Unpleasant surprises. Especially towards the end of the project.
  • Virtual progress. The team cranks out tickets or features. So the progress looks fine on paper. In the mean time there's growing amount of hidden and unknown work with integrating all the modules.
  • Building the wrong thing. The longer team depends on documentation or spec, the further thy drift from what the client actually needs.
  • Inadequate quality. Quality is rarely defined explicitly - most of the time it's assumed to be "good". At the same time it has a huge impact on the architecture, tools and effort needed to build software. Demo is an opportunity to probe and feel the level of quality.
  • Lack of ownership. The team being moved away from doing demos, not seeing the client reaction can't fully appreciate client's position and requirements. They can't easily empathize with the customer and stop caring for the project.
  • Inability to course-correct. As long as the client assumes what they specified will be developed and the team assumes what they understood is to be built there's no real corrections possible to the scope, quality, features, etc.

Remedies

You may skip doing demos if you decide on some other way of making sure that the software is integrated, delivered to the customer and tested by them. This can be continuous integration to a test server or delivering nightly builds to the client’s inbox. You also need to make sure to gather feedback about the builds tested by the client and stakeholders.

Be sure to subscribe (RSS) or check back in a week for the next one.