Frequently Asked Questions: When Can I Demo Work That Isn’t Done

Sometimes no is the right answer and sometimes it is not!

I have been asked many times whether it is “ok” to include work that is not complete in a demonstration/sprint review.  The simple answer is that is a bad idea 95% of the time. If the answer is no most of the time, what would the default answer to “yes”?  The only good reason to demonstrate an incomplete user story is when feedback is needed or desired to allow the team to progress and the people participating in the demo are the right people.  Allowing the team to progress is not the same demonstrating progress …we have discussed the definition of bad. Occasionally I have seen the need to show progress for reasons of organizational politics.  Not a great reason, but sometimes you have to do what is necessary to stay employed. Both of these reasons should be RARE. I have a rule: I do not spend money that is older than I am — demo’ing incomplete stories should be at least that rare.  An unasked question that is even more important when the “can I demo incomplete work” question is asked, is how can you demo incomplete work items and stay safe. (Note – Generally when people ask if they can demo incomplete items they already have or are going to do it anyway and are looking for absolution.)  

Demo’ing Incomplete Story Safety Checklist

 

SPaMCAST 339 – Demonstrations, Microservices

http://www.spamcast.net

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 339 features our essay on demonstrations and a new Form Follows Function column from Gene Hughson.

Demonstrations are a tool to generate conversations about what is being delivered.  Because a demonstration occurs at the end of every sprint the team will continually be demonstrating the value they are delivering, which reinforces confidence and motivation. The act of demonstrating value provides the team with a platform for collecting feedback that will help them stay on track and focused on delivering what has the most value to the business.

Gene continues his theme of microservices.  This week we tackle, “Microservices, SOA, and EITA: Where To Draw the Line? Why to Draw the Line?” Gene says, “we recognize lines to prevent needless conflict and waste.”

Two special notes:

Jo Ann Sweeny of the Explaining Change column is running her annual Worth Working Summit.  Please visit http://www.worthworkingsummit.com/

Jeremy Berriault will be joining the SPaMCAST family.  Jeremy will be focusing on testing and the lessons testing can provide to a team and organization.

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21^nd. The Goal has been hugely influential because it introduced the Theory of Constraints which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

I am beginning to think of which book will be next. Do you have any ideas?

Upcoming Events

CMMI Institute Global Congress
May 12-13 Seattle, WA, USA
My topic – Agile Risk Management
http://cmmiconferences.com/

DCG will also have a booth!

Next SPaMCast

The next Software Process and Measurement Cast will feature our interview with Tom Howlett.  Tom is the author of the Diary of a Scrummaster and is a Scrum Master’s Scrum Master. Tom and I talked Agile and being Agile outside of the classic software development environments.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

Demonstrations

Demonstrations aren’t presentations, they require bi-directional conversation.

Demonstrations, also known as demos, are Agile’s mechanism to share what the team has been accomplished during the current sprint. At root, the demo is a show and tell that provides the team with a platform to describe what has been accomplished. Demos build confidence and customer satisfaction. They can be done using a simple, repeatable process that straight forward and to the point.  By making sure the process is interactive and the material concise, all of the participants will find the demo engaging and focused. Demonstrations deliver fast feedback, but only if they happen and only if they are engineered to facilitate a bi-directional exchange of information.

The basic mechanism of a demo is simple. Show stakeholders the completed work, let them interact with it and actively solicit feedback. I once heard someone describe this as running toward criticism. Where variations do happen they tend to be driven by scope, which implies different audiences, or by the geography of the team and stakeholders.  The variations in demonstration techniques are less about the goal of gathering feedback than about audiences and enabling the audience to provide the feedback.

Demonstrations occur on the last day of every sprint. They show the stakeholders what has been accomplished during the current sprint. The goal is for the team to gather feedback from the stakeholders so that they build what is needed and what the team committed to at the beginning of the iteration. The transparency created when the team shares its performance allows the team to rush toward feedback, while selling progress. Good demos include stakeholders interacting with the software so that everyone understands exactly what has been developed.

Demonstrations are the team’s mechanism to gather feedback and to ensure they are delivering value. I believe that demos have two currencies. The first is working software and the second is feedback. Teams build cache when they say what they are going to do, do what they say and listen to how their stakeholders feel about what they deliver.

 

Demonstrations in Distributed Teams

The demonstration needs to work for everyone, no matter where in the world you are.

Demonstrations are an important tool for teams to gather feedback to shape the value they deliver.  Demonstrations provide a platform for the team to show the stories that have been completed so the stakeholders can interact with the solution.  The feedback a team receives not only ensures that the solution delivered meets the needs but also generates new insights and lets the team know they are on track.  Demonstrations should provide value to everyone involved. Given the breadth of participation in a demo, the chance of a distributed meeting is even more likely.  Techniques that support distributed demonstrations include:

1. More written documentation: Teams, especially long-established teams, often develop shorthand expressions that convey meaning fall short before a broader audience. Written communication can be more effective at conveying meaning where body language can’t be read and eye contact can’t be made. Publish an agenda to guide the meeting; this will help everyone stay on track or get back on track when the phone line drops. Capture comments and ideas on paper where everyone can see them.  If using flip charts, use webcams to share the written notes.  Some collaboration tools provide a notepad feature that stays resident on the screen that can be used to capture notes that can be referenced by all sites.
2. Prepare and practice the demo. The risk that something will go wrong with the logistics of the meeting increase exponentially with the number of sites involved.  Have a plan for the demo and then practice the plan to reduce the risk that you have not forgotten something.  Practice will not eliminate all risk of an unforeseen problem, but it will help.
3. Replicate the demo in multiple locations. In scenarios with multiple locations with large or important stakeholder populations, consider running separate demonstrations.  Separate demonstrations will lose some of the interaction between sites and add some overhead but will reduce the logistical complications.
4. Record the demo. Some sites may not be able to participate in the demo live due to their time zones or other limitations. Recording the demo lets stakeholders that could not participate in the live demo hear and see what happened and provide feedback, albeit asynchronously.  Recording the demo will also give the team the ability to use the recording as documentation and reference material, which I strongly recommend.
5. Check the network(s)! Bandwidth is generally not your friend. Make sure the network at each location can support the tools you are going to use (video, audio or other collaboration tools) and then have a fallback plan. Fallback plans should be as low tech as practical.  One team I observed actually had to fall back to scribes in two locations who kept notes on flip charts by mirroring each-other (cell phones, bluetooth headphones and whispering were employed) when the audio service they were using went down.

Demonstrations typically involve stakeholders, management and others.  The team needs feedback, but also needs to ensure a successful demo to maintain credibility within the organization.  In order to get the most effective feedback in a demo everyone needs to be able to hear, see and get involved.  Distributed demos need to focus on facilitating interaction more than in-person demos. Otherwise, distributed demos risk not being effective.

 

Distributed Agile: Demonstrations

Demonstrations!

Demonstrations are an important tool for teams to gather feedback to shape the value they deliver.  Demonstrations provide a platform for the team to show the stories that have been completed so the stakeholders can interact with the solution.  The feedback a team receives not only ensures that the solution delivered meets the needs but also generates new insights and lets the team know they are on track.  Demonstrations should provide value to everyone involved. Given the breadth of participation in a demo, the chance of a distributed meeting is even more likely.  Techniques that support distributed demonstrations include:

1. More written documentation: Teams, especially long-established teams, often develop shorthand expressions that convey meaning fall short before a broader audience. Written communication can be more effective at conveying meaning where body language can’t be read and eye contact can’t be made. Publish an agenda to guide the meeting; this will help everyone stay on track or get back on track when the phone line drops. Capture comments and ideas on paper where everyone can see them.  If using flip charts, use webcams to share the written notes.  Some collaboration tools provide a notepad feature that stays resident on the screen that can be used to capture notes that can be referenced by all sites.
2. Prepare and practice the demo. The risk that something will go wrong with the logistics of the meeting increase exponentially with the number of sites involved.  Have a plan for the demo and then practice the plan to reduce the risk that you have not forgotten something.  Practice will not eliminate all risk of an unforeseen problem, but it will help.
3. Replicate the demo in multiple locations. In scenarios with multiple locations with large or important stakeholder populations, consider running separate demonstrations.  Separate demonstrations will lose some of the interaction between sites and add some overhead but will reduce the logistical complications.
4. Record the demo. Some sites may not be able to participate in the demo live due to their time zones or other limitations. Recording the demo lets stakeholders that could not participate in the live demo hear and see what happened and provide feedback, albeit asynchronously.  Recording the demo will also give the team the ability to use the recording as documentation and reference material, which I strongly recommend.
5. Check the network(s)! Bandwidth is generally not your friend. Make sure the network at each location can support the tools you are going to use (video, audio or other collaboration tools) and then have a fallback plan. Fallback plans should be as low tech as practical.  One team I observed actually had to fall back to scribes in two locations who kept notes on flip charts by mirroring each other (cell phones, bluetooth headphones and whispering were employed) when the audio service they were using went down.

Demonstrations typically involve stakeholders, management and others.  The team needs feedback, but also needs to ensure a successful demo to maintain credibility within the organization.  In order to get the most effective feedback in a demo everyone needs to be able to hear, see and get involved.  Distributed demos need to focus on facilitating interaction more than in-person demos. Otherwise, distributed demos risk not being effective.

 

Demonstrations: Involve Business and Technical Stakeholders

Business and Technical Stakeholders Must Both Be Involved In Demonstrations

In order to efficiently gather feedback and support, demos require broad involvement. Involvement must include the team and a cross section of relevant stakeholders. Stakeholders should span the interests of both the business and technical environments.

Business stakeholders include those representing product and back-office functionality. The stakeholders bring the understanding of market needs and wishes for both customer facing products as well as applications used within the organization to the sprint team and to other stakeholders.

Technical stakeholders include data and technical architects, process improvement personnel and DevOps teams that might need to provide guidance or direction to the sprint team. The technical feedback helps the team to stay within the environmental constraints of the organization.

The demonstrations bring the business and technical stakeholders together with the sprint team to generate feedback. The different perspectives that the business and technical stakeholders bring to the table extend the knowledge of the team. Teams that constrain participation in the demo rob themselves of significant input that may have to be “discovered” later in the project, which can generate customer dissatisfaction and rework.

 

Demonstrations: Variants

Sometimes some parts may need to be a little different.

Demonstrations can be done using a simple, repeatable process that straight forward and to the point.  By making sure the process is interactive and the material concise, all of the participants will find the demo engaging and focused. Demonstrations deliver fast feedback, but only if they happen and only if they are engineered to facilitate a bi-directional exchange of information. The classic mechanism of showing functional software to stakeholders, having them interact with the software and asking (and listening) to feedback is fairly difficult to improve upon. Perhaps that is why there are so few true variants of demonstrations. The variants that have shown traction are driven either by scope or team distribution.

Two variants of the classic demonstration by scope are SAFe’s (Scaled Agile Framework) System Demos. It provides a demonstration of all of the software delivered (a systems view). A Technical Demo focuses on units of work that by nature are not interpretive by typical business stakeholders. While the Technical Demo makes me nervous, I believe we have all seen a story or unit of work that relates to technical infrastructure or relates to a specific audience of stakeholder.   Each of these demos use slightly different techniques to engage different audiences. What they don’t do is stray from the principle of showing completed work and activity soliciting feedback.

Executing demos for distributed teams and distributed stakeholders has generated a wide range of variants. As with the scope variants, most of the different techniques are used to ensure that completed work is shown, interacted with and that feedback is collected.  Many of the variants are driven by the communication technology being used, such as teleconferencing or video conferencing. Each of these technologies requires the team to plan in more depth to ensure interactivity and feedback. One interesting variant is the use of satellite demos (if there are multiple concentrations of team members or stakeholders) with feedback being rolled up to a higher level demo (somewhat akin to a scrum or scrums).  The concepts used in the SAFe System Demo may well be useful in this type of a distributed environment.

The basic mechanism of a demo is simple. Show stakeholders the completed work, let them interact with it and actively solicit feedback. I once heard someone describe this as running toward criticism. Where variations do happen they tend to be driven by scope, which implies different audiences, or by the geography of the team and stakeholders.  The variations in demonstration techniques are less about the goal of gathering feedback than about audiences and enabling the audience to provide the feedback.

 

Demonstrations: How To Execute A Demo

Demonstrations come in many sizes and formats. Some are concise affairs while others are long and labored. Some are interactive and conversational while others are grand presentations with information being shared in one direction. The more complex and unidirectional the conversation the less interesting the demonstrations are for attendees. Interesting and focused demonstrations can be accomplished using a few basic techniques. Good demonstration requires context, preparation and execution.

Sprints begin with work being accepted by the team into the sprint. The work that the team accepts into the sprint provides the context of the demonstration. The goal of taking work into a sprint is to complete all of that work based on the overall definition of done and as proved by completing all acceptance criteria. Work that does not meet the definition of done should not be demonstrated. When not completed the team needs to communicate that they were not able to complete the work and return the unit of work to the backlog then move on to the units of work that were completed.

Preparing for a demonstration includes beginning with the end in mind. As units of work are accepted into the team should ensure that the acceptance criteria are written that so they can demonstrate the team met the definition of done. A second step in the preparation process is to have the team walk through the demo prior to do it live. I believe that the product owner should facilitate the demonstration, explaining how the team has solved the business problem and soliciting interaction and feedback. Therefore a bit of practice is always good idea to ensure the product owner is not caught flatfooted. Demonstrations in which the team fumbles around or solicits interaction and feedback and the software isn’t accessible is at best comedic and at worst gut-wrenching.

When it is time for the demo, execute according to the plan. I suggest beginning with a bit of preamble such as explaining what a demo is, for any new attendees, introduce the team and then let everyone know which units of work will be demo’ed and which won’t. Then demo the units of work one by one. Explain the unit of work, walk through an execution of the acceptance criteria, solicit interaction with the software (if appropriate) and finally ask for feedback. As noted before I have found that having the product owner facilitate the demo supported by the technical team is most effective for getting stakeholder involvement and feedback. Keep the process concise without being clipped or abrupt. At the end of demonstrating each unit of work it should be easy to determine if the stakeholders believe the units of work are complete, if there are issues that will require the unit of work to be returned to the backlog or if new backlog items have been identified.

Demonstrations can be done using a simple, repeatable process that straight forward and to the point. By making sure the process is interactive and the material concise all of the participants will find the demo engaging and focused.

 

Demonstrations: What to Demo

Demonstrations reflect the output of the team, i.e. the value they created during a sprint. Because of the pressure to “show” value there is a tendency for immature Agile teams to add all sorts of interim deliverables to the demo. Assuming that you are involved in a software project, an Agile demonstration would be based on working software. Lists of code, PowerPoint slides and status reports should be avoided.

The demonstration, led by the Product Owner, shows how the unit of work was completed. In the best case scenario, the stakeholders get to exercise the functionality. By seeing and exercising the software stakeholders are in a great position to provide feedback about what they need or don’t need and about new ideas that might have been triggered. Only the units of work (also known as stories) that are done should be included in the demonstration. The word “done” has a special meaning in Agile. Done is defined as the task required to make the software shippable/implementable. The definition of done usually includes design, coding, testing (various flavors) and documenting. These tasks are completed during the sprint.

Items such as code (the printed representation), status reports, graphs or PowerPoint slides do not represent progress. PowerPoint slides are very rarely installed in production as operational software. Anything that does not fall into the category of implementable software is not demonstrable. I have seen perfectly fine demos that begin with a a slide showing a list of stories that were in the sprint, a few minutes of a preamble describing how a demo works and a flip chart showing the burn-down chart for the sprint and the program.  While these are really barnacles (add-ons) attached to the demonstration they didn’t distract from the real measure of progress.

Demonstrations are a tool to solicit feedback by presenting working software (if this is a software project). Demonstrations are not status meetings or platforms for presentations or for reading code, showing PowerPoint slides or graphs as a proof that work has been accomplished. The point is to show what has been completed and could be implemented. That gives the stakeholders the best understanding of direction and allows them to supply targeted feedback based on knowledge.

 

Demonstrations: Why Hold a Demonstration?

The team shows what they have completed.

Demonstrations are a platform for an Agile team (or teams) to interact with stakeholders in order to solicit feedback and direction from a broader audience. A demonstration satisfies three primary goals: communication, risk mitigation and motivation.

The format of a demonstration varies from one implementation of Agile to another; however the basics always include the team communicating the work that was completed during the sprint. This allows the team to showcase the value they are delivering.  It facilities a discussion of needs, desires, risks and concerns between the stakeholders and the Agile team, which enriches the team’s knowledge.

Demonstrating how the team (scrum master, product owner and technical team members) developed the solution for the work units at the end of each sprint avoids many of the classic risks seen in waterfall projects.  One of risks the that a demonstration mitigates is the risk of surprising the stakeholders with a solution that does not fit their needs at the end of the project. Feedback helps the team and the organization avoid building throw away projects by continually validating the direction.

Demonstrations provide a vehicle to generate or reinforce team motivation. Demonstration allow the team to publicly showcase the work they have completed, which generates a sense of accomplishment.  A sense of accomplishment based on tangible results is a type of a feedback loop that helps build team confidence and while creating or reinforcing motivation. My professional observations of teams strongly suggests that motivation and confidence are directly related to productivity and quality.

Demonstrations are a tool to generate conversation about what is being delivered.  Because a demonstration occurs at the end of every sprint the team will continually be demonstrating the value they are delivering, which reinforces confidence and motivation. The act of demonstrating value provides the team with a platform for collecting feedback that will help them stay on track and focused on delivering what has the most value to the business.