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

Celebrate your individual successes, too. Congratulate your coworker for completing the project’s first performance test baseline. Give your DBA a gold star for implementing a production back-up system. Give yourself a treat for solving that hard test-automation problem. Bring cookies to your next meeting with the customers. Recognize the programmer who gave you a JavaScript harness that sped up testing of some GUI validations. Use your imagination.

The Shout-Out Shoebox

We love the celebration idea we got from Megan Sumrell, an agile trainer and coach. She shared this with an agile testing Open Space session at Agile 2007.

Celebrating accomplishments is something I am pretty passionate about on teams. On a recent project, we implemented the Shout-Out Shoebox. I took an old shoebox and decorated it. Then, I just cut a slit in the top of the lid so people could put their shout-outs in the box. The box is open to the entire team during the course of the sprint.

Anytime team members want to give a “shout-out” to another team member, they can write it on a card and put it in the box. They can range from someone helping you with a difficult task to someone going above and beyond the call of duty. If you have distributed team members, encourage them to email their shout-outs to your ScrumMaster who can then put them in the box as well.

At the end of our demo, someone from the team gets up and reads all of the cards out of the box. This is even better if you have other stakeholders at your demo. That way, folks on your team are getting public recognition for their work in front of a larger audience. You can also include small give-aways for folks, too.

It may be a cliché, but little things can mean a lot. The Shout-Out Shoebox is a great way to recognize the value different team members contribute.

Taking time to celebrate successes lets your team take a step back, get a fresh perspective, and renew its energy so it can keep improving your product. Give team members a chance to appreciate each other’s contributions. Don’t fall into a routine where everyone has their head down working all the time.

In agile development, we get a chance to stop and get a new perspective at the end of each short iteration. We can make minor course corrections, decide to try out a new test tool, think of better ways to elicit examples from customers, or identify the need for a particular type of testing expertise.

Summary

In this chapter, we looked at some activities to wrap up the iteration or release.

The iteration review is an excellent opportunity to get feedback and input from the customer team.

Retrospectives are a critical practice to help your team improve.

Look at all areas where the team can improve, but focus on one or two at a time.

Find a way to keep improvement items in mind during the iteration.

Celebrate both big and small successes, and recognize the contributions from different roles and activities.

Take advantage of the opportunity after each iteration to identify testing-related obstacles, and think of ways to overcome them.

Chapter 20 Successful Delivery

In this chapter, we share what you as a tester can do to help your team and your organization successfully deliver a high-quality product. The same process and tools can be used for shrink-wrapped products, customized solutions, or internal development products. Agile testers can make unique contributions that help both the customer and developer team define and produce the value that the business needs.

What Makes a Product?

Many of the books on agile development talk about the actual development cycle but neglect to talk about what makes a product and what it takes to successfully deliver that product. It’s not enough to just code, test, and say it’s done. It’s like buying something from a store: If there is great service to go with the purchase, how much more likely are you to go back and buy there again?

Janet’s Story

I was talking to my friend, Ron, who buys and sells coins. Over the years he has developed a very good reputation in the industry and has turned away prospective clients because he is so busy.

When I asked him his secret, he said, “It’s not a secret. I just work with my customers to make them feel comfortable and establish a trusting relationship with them. In the end, both I and my customer need to be happy with the deal. It only takes one unhappy customer to break my reputation.”

Agile teams can learn from Ron’s experience. If we treat our customers with respect and deliver a product they are happy with, we will have a good relationship with them, hopefully for many years.

—Janet

Our goal is to deliver value to the business in a timely manner. We don’t want just to meet requirements but also to delight our customers. Before we release, we want to make sure all of the deliverables are ready and polished up appropriately. Hopefully, you started planning early to meet not only the code requirements but to plan for training, documentation, and everything that goes into making a high-value product.

Fit and Finish

Coni Tartaglia, a software test manager with Primavera Systems, Inc., explains “fit and finish” deliverables.

It is helpful to have a “Fit and Finish” checklist. Sometimes fit and finish items aren’t ready to be included in the product until close to the end. It may be necessary to rebuild parts of the product to include items such as new artwork, license or legal agreements, digital signatures for executables, copyright dates, trademarks, and logos.

It is helpful to assemble these during the last full development iteration and incorporate them into the product while continuous integration build cycles are running so that extra builds are not needed later.

Business value is the goal of agile development. This can include lots beyond the production code. Teams need to plan for all aspects of product delivery.

Imagine yourself in the middle of getting your release ready for production. You’ve just finished your last iteration and are wrapping up your last story test. Your automated regression suite has been running on every new build, or at least on every nightly build. What you do now will depend on how disciplined your process has been. If you’ve been keeping to the “zero tolerance” for bugs, you’re probably in pretty good shape.

If you’re one of those teams that thinks you can leave bugs until the end to fix, you’re probably not in such good shape and may need to introduce an iteration for “hardening” or bug fixes. We don’t recommend this, but if your team has a lot of outstanding bugs that have been introduced during the development cycle, you need to get those addressed before you go into the end game. We find that new teams tend to fall into this trap.

In addition, there are lots of varied components to any release, some in the software, some not. You have customers who need to install and learn to use the new features. Think about all those elements that are critical to a successful release, because it’s time to wrap up all those loose ends and hone your product.