Crispin, Lisa - Agile Testing - A Practical Guide for Testers and Agile Teams

Iteration Demo

One of the pleasures of agile development is the chance to show completed stories to customers at the end of each iteration. Customers get to see a real, live, working application. They get to ask questions and give feedback. Everyone involved in the project, from both the business and technical sides, gets to enjoy a sense of accomplishment.

On Lisa’s team, the testers conduct the iteration review. Among all the team members, they’ve usually worked on the most stories. They have a natural role as information providers, and they have a good idea what the customers need to know about the new functionality. Having testers show off the deliverables is a common practice, although there is no hard and fast rule. The business experts on the team are a good choice for conducting the demo too, because they have the best understanding of how the software meets the business needs and they’ll feel greater ownership of the product. The ScrumMaster, a programmer, or a business analyst could demonstrate the new features and often does. Janet encourages rotating this honor.

Listening to the Customers

Pierre Veragen explains how his team uses iteration demonstrations.

“We shut up and listen to our customers. It’s all about the chemistry of the group’s presentation. Somehow, sharing the moment brings brains together—we look at things from a different perspective. The event gives birth to ideas and concepts. Some die as the next person speaks; some live on and become that great idea that differentiates the product.”

The demo is a chance to show off the new stories, but the feedback customers provide is the biggest reason to do them.

Anyone may note the comments made by customers as they participate in the demo, but testers are good candidates. They may notice previously undetected inconsistencies as the demo progresses. As questions come up, customers might decide they want to change something minor, such as help text, or something bigger, such as how a feature behaves. Minor changes can usually be made into tasks and dealt with in the next iteration, but some changes are big enough to turn into stories to plan into future releases.

Iteration demos (called sprint reviews in the Scrum world) are a super opportunity to get everyone talking and thinking about the application. Take advantage of it. Review meetings are usually short and can be under half an hour. If there’s time left over after demonstrating new stories, ask customers if they’ve experienced any problems with the previous release that they haven’t reported. Do they have any general concerns, do they need help understanding how to use a feature, or have any new issues arisen? Of course, you can talk to customers anytime, but having most of the stakeholders in the room with the development team can lead to interesting ideas.

Retrospectives

Agile development means continually improving the way you work, and retrospectives are an excellent place to start identifying what and how you can do better. We recommend taking time at the end of each iteration and release cycle to look back and talk about what went well, what didn’t, and what you might like to try in the next iteration. There are different approaches for conducting retrospective sessions. No matter what approach you use, it’s key that each team member feels safe, everyone is respected, and there’s no finger-pointing or blame.

The whole idea is to make the process better, one baby step at a time.

Start, Stop, Continue

One common exercise used in iteration retrospectives is “start, stop, continue.” The team asks itself: “What went well during this past iteration? What happened that shouldn’t happen again? What can we start doing to help with things that didn’t go well?” Each team member can suggest things to start doing to improve, things to stop doing that weren’t working, and things that are helping that should be continued. A facilitator or ScrumMaster lists them on a whiteboard or big piece of paper. Post them in a location where everyone can read them again during the iteration. Figure 19-1 shows a “stop, start, and continue” retrospective in progress. The ScrumMaster (standing) is writing stop, start, and continue suggestions on the big piece of paper on the story board.

Figure 19-1 A retrospective in progress. Used with permission of Mike Thomas. Copyright 2008.

Agile Retrospectives: Making Good Teams Great [2006] has imaginative ideas for making retrospectives more productive (see the bibliography).

Some teams start this process ahead of time. All team members write “start,” “stop,” and “continue” items on sticky notes, and then during the retrospective meeting they put the stickies on the board and group them by topic. “Start, stop, continue” is just one example of the terms you might use. Some other ideas are: “Things that went well,” “Things to improve,” “Enjoyable,” “Frustrating,” and “To Try.” Use whatever names that work for you. It can be hard to remember the past two weeks, much less an entire release, if that’s what your retrospective covers. Research different creative approaches to reflecting on your team’s experiences.

Here’s a sample “stop, start, continue” list from Lisa’s team:

Start:

Sending out next sprint’s stories to us earlier.

Don’t do lazy, single-record processing. Think of every service call as a remote call.

Communicate any database changes to everyone.

Stop:

Accepting stories without complete requirements.

Continue:

Running FitNesse tests for the code you’re working on.

Documenting what came up in meeting or informal discussions.

Communicating better with each other.

Showing mock-ups early.

Doing FitNesse driven development.

If the list of “start, stop, continue” items is long, it’s a good idea to choose one or two to focus on for the new iteration. To prioritize the items, give each team member “n” votes they can assign to items. The ten people on Lisa’s team each get three votes, and they can apply them all to one item if they feel that’s most important, or they can vote for two or three different items. The items with the most votes are noted as the focus items. Janet has had success with this way of prioritizing as well.

In addition to “start, stop, continue” items, the team may simply write task cards for actions to be undertaken the next iteration. For example, if the ongoing build is too slow, write a card to “get ongoing build under ten minutes.”

In the next iteration, take some time to look at the one or two focus items you wanted to improve. At the end of that iteration, take a checkpoint to see if you improved. If not, ask why. Should you try something different? Is it still important? It could be it has dropped in importance or really wasn’t important in the big picture. If you thought you improved on a problem area and it resurfaces, you’ll have to decide to do something about it or else quit talking about it.