Note
Product Manager, Whole Team
We keep it real.
An XP team produces working software every week, starting with the very first week.
Sound impossible? It’s not. It’s merely difficult. It takes a lot of discipline to keep that pace. Programmers need discipline to keep the code clean so they can continue to make progress. Customers need discipline to fully understand and communicate one set of features before starting another. Testers need discipline to work on software that changes daily.
The rewards for this hard work are significantly reduced risk, a lot of energy and fun, and the satisfaction of doing great work and seeing progress. The biggest challenge is keeping your momentum.
The iteration demo is a powerful way to do so. First, it’s a concrete demonstration of the team’s progress. The team is proud to show off its work, and stakeholders are happy to see progress.
Important
Iteration demos help keep the team honest.
Second, the demos help the team be honest about its progress. Iteration demos are open to all stakeholders, and some companies even invite external customers to attend. It’s harder to succumb to the temptation to push an iteration deadline “just one day” when stakeholders expect a demo.
Finally, the demo is an opportunity to solicit regular feedback from the customers. Nothing speaks more clearly to stakeholders than working, usable software. Demonstrating your project makes it and your progress immediately visible and concrete. It gives stakeholders an opportunity to understand what they’re getting and to change direction if they need to.
Regular delivery is central to successful XP. The iteration demo is a concrete indication of that progress. When schedule problems occur (they always do), an iteration demo makes it harder to avoid reality—and facing reality gives you the opportunity to manage it.
Anybody on the team can conduct the iteration demo, but I recommend that the product manager do so. He has the best understanding of the stakeholders’ point of view and speaks their language. His leadership also emphasizes the role of the product manager in steering the product.
Invite anybody who’s interested. The whole team, key stakeholders, and the executive sponsor should attend as often as possible. Include real customers when appropriate. Other teams working nearby and people who are curious about the XP process are welcome as well. If you can’t get everyone in a room, use a teleconference and desktop-sharing software.
Note
If you have a particularly large audience, you may need to set some ground rules about questions and interruptions to prevent the demo from taking too long. I tell attendees that the product manager will be available for further discussion after the meeting.
The entire demo should take about 10 minutes. (After all, it’s only been a week since the last one.) If it runs long, I look for ways to bring it to a close before it reaches half an hour.
Because this meeting is so short, I highly recommend starting on time, even if some people aren’t present. This will send the message that you value attendees’ time as well as the available time to work on the project. Both the product manager and the demo should be available for further discussion and exploration after the meeting.
Important
Calmly describe problems and how you handled them.
Once everyone is together, briefly describe the features scheduled for the iteration and their value to the project. If the plan changed during the middle of the iteration, explain what happened. Don’t sugarcoat or gloss over problems. Full disclosure will raise your credibility. By neither simplifying nor exaggerating problems, you demonstrate your team’s ability to deal with problems professionally. Here is an example:
Last week, we scheduled five stories in the area of online bookings. These stories revolved around adding polish to our flight reservation system. That system was already functionally complete, but we want it to be more impressive and usable for our customers.
We finished all the stories we had planned, but we had to change the itinerary story, as I’ll show you in a moment. It turned out to have some performance problems, so we had to find another solution. It’s not exactly what we had planned, but we’re happy with the result and we don’t intend to spend any more time on it.
Important
After your introduction, go through the list of stories one at a time. Read the story, add any necessary explanation, and demonstrate that the story is finished. Use customer tests to demonstrate stories without a user interface:
Demonstrator: Our first story was to automatically fill in the user’s billing information if they put in their frequent flyer number. First, I’ll bring up the front page... click “reservations”... type in our test frequent flyer number... and there, you can see that the billing information fills in automatically.
Audience member: What if they fill in the billing information first?
Demonstrator: In that case, the billing information is left unchanged. [Demonstrates.]
If you come to a story that didn’t work out as planned, provide a straightforward explanation. Don’t be defensive; simply explain what happened:
Demonstrator: Our next story involves the itinerary. As I mentioned, we had to change this story. You may remember that our original story was to show flight segments on an animated globe. The programmers had some concerns about performance, so they did a test and it turned out that rendering the globe would double our datacenter costs.
Audience member: Why is it so expensive?
Programmer: Many animations are unique, and we have to render them on the server. As a result, the server has to render a custom animated .GIF for each person. Because it’s 3-D, it takes a lot of CPU, which means we would need more powerful hardware in the datacenter. We might be able to cache some of the .GIFs, but we’d need to take a close look at usage stats before we could say whether that would work.
Demonstrator: We didn’t want to spend time on performance optimizations, and the increased hardware cost wasn’t worth it. None of our competitors have a map of flight segments at all, so we decided a simpler 2-D map would be good enough. We had already used up some of our time for this story, though, and we didn’t have enough time left to animate the map. After seeing the result [demonstrates] we decided it was good enough for now. We intend to move on to new features rather than spending more time on the itinerary.
Once the demo is complete, tell stakeholders how they can run the software themselves. Make an installer available on the network, or provide a server for stakeholder use, or something similar. You can also cut short side discussions by directing people to the sample installation.
At the end of the demo, ask your executive sponsor two key questions:[20]
Is our work to date satisfactory?
May we continue?
These questions help keep the project on track and remind your sponsor to speak up if she’s unhappy. You should be communicating well enough with your sponsor that her answers are never a surprise.
Note
Your sponsor isn’t likely to attend all the demos, although that’s preferable. You can increase the likelihood of her attending by keeping the demo short. If she doesn’t come at all, the product manager should conduct a private demo—and ask the two key questions—at least once per month.
Sometimes, she may answer “no” to the first question, or she may answer “yes” but be clearly reluctant. These are early indicators that something is going wrong. After the demo, talk with your sponsor and find out what she’s unhappy about. Take immediate action to correct the problem.
Note
Sometimes your sponsor will be unhappy because she wants the team to go faster. See Estimating” in Chapter 8 for a discussion of how to improve your velocity. Risk Management,” also in Chapter 8, has a discussion of what to do when you can’t meet your sponsor’s expectations.
In rare cases, the executive sponsor will answer “no” to the second question. You should never hear this answer—it indicates a serious breakdown in communication.
If you do hear this answer, you’re done. Meet with your sponsor after the demo and confirm that she wants the team to stop. Let her know that you’re prepared to ship what was demonstrated today and you’d like one final week to wrap things up. Try to find out what went wrong, and include your sponsor in the project retrospective, if possible.
The iteration demo isn’t just a dog and pony show; it’s a way to prove that you’re making real progress every iteration. Always provide an actual release that stakeholders can try for themselves after the demo. Even if they are not interested in trying a demo release, create it anyway; with a good automated build, it takes only a moment. If you can’t create a release, your project may be in trouble.
One of the biggest schedule risks in software is the hidden time between “we’re done” and “we’ve shipped.” Teams often have to spend several extra weeks (or months) after the end of the planned schedule to make their product buildable and shippable. Releasing a usable demo every iteration mitigates this risk.
If you’re starting a new codebase, be sure that the code is deployable every iteration. This will help stave off technical debt. The weekly rhythm of iteration demos and stakeholder releases is an excellent way to keep the code releasable. Chapter 7 describes how to do so.
If you’re working on a legacy codebase, weekly deployment may not yet be possible. Your build system may be incomplete, you may not have an adequate demo environment, or the installer may not yet be written. If so, this indicates a large chunk of technical debt. See Applying XP to an Existing Project” in Chapter 4 for suggestions on how to address this problem while continuing to satisfy stakeholders.
What do we do if the stakeholders keep interrupting and asking questions during the demo?
A certain number of questions is normal, particularly when you start giving demos. Over time, as stakeholders adapt to the weekly rhythm, you should see fewer interruptions.
For the first month or so, you can establish goodwill by ignoring the half-hour guideline and answering every question. After the first month, the product manager can politely ask stakeholders to direct further questions to him after the meeting.
What do we do if stakeholders keep nitpicking our choices?
Nitpicking is also normal, particularly in the beginning. It’s usually a sign of genuine interest in the product, so don’t take it too personally. Write the ideas down on cards, as with any story, and have the product manager prioritize them after the meeting. Resist the temptation to address, prioritize, or begin designing solutions in the meeting. Not only does this extend the meeting, it reduces the discipline of the normal planning practices.
Important
If nitpicking continues after the first month, it may be a sign that the on-site customers are missing something. Take a closer look at the complaints to see if there’s a deeper problem. Root-cause analysis may help.
The stakeholders are excited by what they see and want to add a bunch of features. They’re good ideas, but we don’t have time for them—we need to move on to another part of the product. What should we do?
Don’t say “no” during the iteration demo. Don’t say “yes,” either. Simply thank the stakeholders for their suggestions, and write them down as stories. After the demo is over, the product manager should take a close look at the suggestions and their value relative to the overall vision. If they don’t fit into the schedule, she should make that decision and communicate it to the stakeholders.
We completely blew this iteration and don’t have anything to show. What do we do?
It will be hard, but you need to be honest about what happened. Take responsibility as a team (rather than blaming individuals or functional groups), try not to be defensive, and let stakeholders know what you’re doing to prevent the same thing from happening again. Here is an example:
This week, I’m afraid we have nothing to show. We planned to work on flight tracking this week, but we underestimated the difficulty of interfacing with the backend airline systems. We discovered that we need our own test environment for the systems because our suppliers’ systems are unreliable.
We identified this problem early in the iteration, and we thought we could work around it. We did, but not in time to finish any stories. We should have replanned the iteration and created smaller stories that we could finish as soon as we encountered this issue. Now we know, and we’ll be more proactive about replanning next time.
The problems with interfacing with the airlines’ systems will affect many of our stories. To prevent further surprises, we’ve revised our estimates. This pushes our best-case release date out by three weeks, which uses up most of our risk buffer. We’re still on target for our scheduled release, but we’ll have to cut features if we encounter any other major problems between now and then.
I’m sorry for the bad news and welcome any suggestions. We can take a few questions now, and I’ll be available for further discussion after we finish planning the upcoming iteration.
When you conduct a weekly iteration demo and demo release, you instill trust in stakeholders, and the team is confident in its ability to deliver. You share problems forthrightly, which allows you to manage them and helps prevent them from ballooning out of control.
Because the iteration demo is highly visible, you may be tempted to fake a demo. You might show a user interface that doesn’t have any logic behind it, or purposefully avoid showing an action that has a significant defect.
Important
Inability to demo is a clear danger sign.
Instead, be clear about the software’s limitations and what you intend to do about them. Faking progress leads stakeholders to believe that you have greater capacity than you actually do. They’ll expect you to continue at the inflated rate, and you’ll steadily fall behind. For more on the dangers of overpromoting, see Organizational Strategy #6: Be Honest,” earlier in this chapter.
If you can’t demonstrate progress weekly, it’s a clear sign that your project is in trouble. Slow down for a week, and figure out what’s going wrong. Ask your mentor for help. The problem may be as simple as trying to do too much work.
Some teams hold a demo every week but can’t actually deploy software for stakeholder use every week. This is a common indicator of technical debt. It reflects a deficiency in the team’s build process and its ability to get stories “done done.”
The iteration demo is a clear indication of your ability to deliver: either you have the ability to demonstrate new features every week, or you don’t. Your executive sponsor either gives you permission to continue, or he doesn’t. I’m not aware of any alternatives that provide such valuable feedback.
Some teams conduct real releases at the end of each iteration rather than a demo. This is a great addition to the practice, if you can do it.