One of the most challenging facets of building software is determining where to spend our time. Demos and walk-throughs are one of those areas that can be overlooked in the chase to save time. However, they are essential in communicating progress and gathering feedback. These require time and attention from everyone on the team, so let’s look at ways to ensure we get the most out of this investment.
Demos and Walk-Throughs Are Not Optional
We can start by agreeing that every project requires this activity at least once. While one can build a solution and “throw it over the wall” to the customer, I do not know anyone who accepts that approach. There are too many details, and custom software is too expensive. No one buys a house without a walk-through, and software should not be any different. A big cost equals a big investment. Therefore, we want to review the results before signing off on them. That can be accomplished without a demo, but it can be time-consuming and confusing to jump into a system and try to use it. We need context to help us assess a solution, and that is where demos and walk-throughs fit into the process.
Your Definition, My Words
An excellent way to be clear when we are communicating is to have someone say back to us what we told them but in their words. The same exercise can be done through a walk-through of a solution. The project starts with requirements and a solution specification to ensure everyone is on the same page. However, there can be design drift and miscommunicated goals that cause a solution to vary from the specification in subtle yet critical ways. A demo helps us detect drift sooner and possibly avoid these issues. At the very least, this helps us reduce the cost of correcting drift. The implementors explain how the solution works while showing it in action. That provides a perfect starting point for concrete discussions and feedback about the solution.
Assumptions and Details
When we describe a process or problem, it is easy to incorporate assumptions and gloss over details. For example, think about explaining how to tie a shoe. Write down the steps you need to take and then follow them explicitly. Most people will fail to tie their shoes. The details and assumptions hidden in the process steps do not become apparent until you test the steps by applying them.
Modern software is highly complex and detailed. Thus, we need to test the steps and requirements we start with through regular demos and walk-throughs that explicitly follow the implemented solution. This provides us more confidence with each successful journey through a feature while also making it easy to see exactly what is being built. That reduces confusion and invites feedback to correct any drift or misunderstandings. The cost-savings and improvement of the success rate from these activities alone make them essential in any project.
Trust and Teamwork
The above reasons should be enough to convince anyone that demos and walk-throughs must be a part of every project. However, many more benefits come out of those meetings. The most valuable of them are trust and teamwork. A demo that includes feedback and discussion is, almost by definition, teamwork. The participants work together toward a common goal. These interactions also build trust and relationships that are essential for a strong team. Projects often hit rough patches and introduce stress into the team dynamic. When we have trust and solid relationships, these bumpy periods are easier to navigate. A lack of trust in any group or relationship will almost always make the hard times harder.
Transparency
We get a form of transparency as well as clarity through regular demos. The progress made and how it looks is available to all via these meetings, and that drives dialog which drives understanding. However, these benefits are not a given. Here are some things that need to be a part of the agenda to make the best use of this investment in time.
- Have an agenda. This seems redundant, but every demo should have a plan. We want to ensure good discussion and avoid too much time spent on distractions or minor features.
- Include regular set-asides for Q&A. Make it clear that feedback and discussion are a part of the plan and schedule time for it.
- Provide a reason or story. A good solution will point back to the requirements and the problem definition. Each demo should be a step in the story from the whiteboard to solving the problem as defined at the beginning of the project.
- Include more action and fewer screenshots in a demo. There should be almost no “talking through” steps and instead show the steps with inputs and outputs. This avoids possible confusion and ensures the resulting solution is a reality rather than smoke and mirrors.
- Provide for an expanded discussion where needed. Some problems and challenges can take a lot of time to work through. A demo highlighting an issue should not be ignored or discussion constrained. Instead, provide a platform for full discussion and the best decisions to be made.
- Avoid the firehose approach. Sometimes a lot of progress is made from one demo to the next. That can lead to information overload. Set the pace and volume of a demo so the audience can digest what they are seeing and provide timely feedback. A demo that is overwhelming in scope is more likely to miss details through sheer overwhelm.
Remember The “Why”
There are many benefits to these investments of time. However, we need to ensure we keep the reason for them in mind. Our goal is to show off progress and gather feedback. Thus, when we forget to make these a part of each meeting, we fall short of our goal. That limits our ROI and increases our chances for mistakes and even failure. Avoid this misstep and keep the team focused on what is expected of each meeting. The Agile Manifesto says it best when it points to the utmost goal of software should be to satisfy the customer. Use these tools to help ensure that remains the primary goal.
Next Steps
Feel free to schedule a time to discuss your next project with us. Every project we work on includes demos and similar discussionns on a regular basis. Often every two weeks and those include a release our customers can use to further test the features and get comfortable with the solution. We are happy to help you with investing in requirements and improving the overall success rate of software projects.
Our experience has taught us a lot about the pitfalls and challenges of custom software. Likewise, we have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We will add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.