Product Demos – Not Just for the Customer Anymore? Part 2

In the first installment of this blog entry, we laid out a scenario which portrays an unhappy software development team. It has become obvious that developers are wasting time fixing and re-fixing bugs (and in many cases, becoming increasingly frustrated) and not contributing to the team’s true velocity. Testers are also becoming frustrated as they are seemingly wasting time retesting and tracking easily identifiable defects, therefore increasing risk by minimizing the time they have to test more complex code and scenarios.

At this point, if they haven’t already, the daily stand-up meetings and/or retrospectives, have most likely taken an on an ornery tone. It’s become obvious that time is being wasted and team members are unhappy.

One potential solution? The post-deployment demo.
I have seen in MANY cases that a significant amount of these issues can be identified up-front – before the retesting effort even begins – by simply scheduling an informal “post-deployment demo”. The format is similar to the aforementioned sprint demo, yet in this case, the “presenter” of this demo is the developer(s) who have worked on the fixes, and the “customer(s)” are the testers actually testing the fixes. The goal of the demo is simple and also similar to the sprint demo – the “customer” should leave the demo confident that the foundation of work which was completed to fix each defect is complete and satisfactory.

Basically, we can attempt to answer two important questions – first, “have we truly fixed what we said we’ve fixed? Second, “have we fixed what actually needed to be fixed and not clearly broken something else in the process?” The second question is obviously a lot more difficult to answer.

It’s important to keep the deployment demo as informal and efficient as possible, yet consistent. Ideally, if accepted by the team as a valuable practice, it should become a team norm, thereby making it repeatable. Usually, QA deployments are on a set schedule; in this case, the demos should adhere to that schedule. Demos should not be considered “painful” because over the course of a project, significant time and effort is saved when issues are uncovered and agreed on between testers and developers before the issues are even retested. Here are some helpful hints and ideas to get started:

• Keep things as simple and efficient as possible – no PowerPoint slides or agenda needed. All the demo requires is a meeting room, a laptop (or even better, a projector), a listing of defect fixes (along with high-level descriptions) and the essential team members.
• Include essential team members (ideally, those developers and testers associated with the functionality contained within the deployment) as often as possible. My teams have referred to this meeting in the past as a “DAT Session”. “DAT”, you may ask? Developer, Analyst, Tester. (Sometimes, it really is that simple.)
  • If applicable, why not include Business Analysts for clarification or feedback?
  • Even better, if you have an eager and co-located customer or client (i.e. Product Owner), why not solicit his or her feedback to save time? Non-complex scenarios or questions can be answered directly, saving even more time (and helping to avoid additional subsequent time-consuming meetings!)
  • Again, while the goal is to keep this as efficient a meeting as possible, at the same time, the possibilities really are endless. A forum for direct, face-to-face collaboration goes a long way and the team should take advantage of the opportunity.
  • Similar to another oft-practiced Agile concept – the “daily stand-up meeting” – try to “time box” the demo as much as possible, stick to topic and do not attempt to resolve issues. This is not a requirements meeting or a story-writing workshop. Yes, simple questions or clarification points can be agreed on and action taken. But if requirements are questioned or further clarification is needed, take it offline. The demo is not the forum for solving these issues.
  • Obviously, not every defect/fix needs to be demoed – usually, high-level demonstrations of simple functionality are adequate, and you’ll find they can uncover numerous issues before they are moved over to “ready to test”, which saves valuable time over the life of a project.

The Post-Deployment Demo – Team Acceptance
One final point – the first few iterations of a deployment demo can potentially have a risk of morphing into a “he said, she said” (or, more to point, “Testers” vs. “Developers”) conflict within the team. Employing this type of feedback session in practice poses a bit more risk to newly-formed teams who are unfamiliar with each other and still striving to progress through the “Forming and Storming” stage of “Tuckman’s Stages of Group Development”.

The reality is that in this forum, names are tied to tasks (in this case, names are tied to bugs) and people’s work is more times than not questioned (and sometimes indirectly criticized). Every effort should be made to avoid being overly critical when addressing issues when one person thinks something has been fixed while another person believes the functionality is still incorrect. Remember, it’s a team effort and everyone is in this together with a common goal of team and project success. I feel this simple yet valuable practice is a great tool to help get you there!