Involving Other Teams
You might need to get other teams on board to help your team succeed. Set up meetings; find ways to communicate as much as possible. Use a Scrum of Scrums to keep multiple teams coordinated, or just get involved with the other teams. If you have to bring in an expert to help with security testing, pair with that expert and learn as much as you can, and help them learn about your project.
If teams are scattered in different locations and time zones, figure out how to get as much direct communication as possible. Maybe representatives from each team can adjust their hours once or twice a week so that they can teleconference once a week. Make a phone call instead of sending an email whenever possible. Lisa’s team adjusted its planning meeting times to include a remote team member who works late at night. They schedule meetings for a time where his day overlaps with the rest of the team’s day.
Chapter 9, “Toolkit for Business-Facing Tests that Support the Team,” gives examples of tools that help remote teams collaborate.
Every Team Member Has Equal Value
Every team member has equal value to the team. If testers or any other team members feel left out or less valued, the whole-team approach is doomed. Make sure testers are invited to all meetings. If you’re a tester and someone forgets to invite you to a meeting, invite yourself. Nontechnical testers might think they’ll be out of place or overwhelmed at a design meeting, but sometimes they ask good questions that the techies didn’t think of.
Testers have a right to ask for and get help. If you’re a tester stuck on an automation problem, have the courage to ask a team member for help. That person might be busy right now, but he or she must commit to helping you in a reasonable amount of time. If you’re a manager or leader on your team, make sure this is happening, and raise the issue to the team if it’s not.
Performance and Rewards
Measuring and rating performance on an individual basis risks undermining team collaboration. We don’t want a programmer to feel she shouldn’t take on a testing task because she’s rated on delivering production code. We don’t want a system administrator to be so busy making sure her individual goals are met that she can’t help with a test environment problem.
Conversely, a good performer who was trying to work well with the team shouldn’t be knocked because the rest of the team didn’t pull together. This is a time when a manager needs to step up and help the team find its way. If major bugs made it to production, nobody should blame the testers. Instead, the whole team should analyze what happened and start taking steps to prevent a recurrence.
The development team needs to keep the business needs in mind. Set goals that serve the business, increase profitability, and make the customers happier. Work closely with the business so that your successes help the whole company succeed.
As we mentioned in Chapter 3, “Cultural Challenges,” celebrate every success, however small. A celebration might be a high-five, a company-provided lunch, or maybe just leaving work early to socialize a bit. The ScrumMaster on Lisa’s team hands out gold stars at stand-up meetings for special accomplishments. Acknowledge the people who help you and your team.
Teams can find novel ways to recognize each other’s contributions. Iteration review and demonstration meetings, where both the development team and customer team are present, are a good setting for recognizing both individual and team achievements.
Read about the “Shout-Out Shoebox” idea in Chapter 19, “Wrap Up the Iteration.”
What Can You Do?
If you’re a new tester on an agile team, especially a new agile team, what can you do to help the team overcome organizational challenges and succeed? How can you fit in with the team and contribute your particular skills and experience?
Put the ten principles we described in Chapter 2 to work. Courage is especially important. Get up and go talk to people; ask how you can help. Reach out to team members and other teams with direct communication. Notice impediments and ask the team to help remove them.
Agile development works because it gets obstacles out of our path and lets us do our best work. We can feel proud and satisfied, individually and as a team. When we follow agile principles, we collaborate well, use feedback to help improve how we work, and always look for new and better ways to accomplish our goals. All this means we can continually improve the quality of our product.
Summary
In this chapter, we looked at ways to build a team and a structure for successful agile testing and development.
Chapter 5 Transitioning Typical Processes
There are many processes in a traditional project that don’t transition well to agile because they require heavyweight documentation or are an inherent part of the phased and gated process and require sign-offs at the end of each stage.
Like anything else, there are no hard and fast rules for transitioning your processes to a more agile or lightweight process. In this chapter, we discuss a few of those processes, and give you alternatives and guidance on how to work with them in an agile project. You’ll find more examples and details about these alternatives in Parts III, IV, and V.
Seeking Lightweight Processes
When teams are learning how to use agile processes, some of the more traditional processes can be lost in the shuffle. Most testers who are used to working with traditional phased and gated development methodologies are accustomed to producing and using metrics, recording defects in a formal defect tracking system, and writing detailed test plans. Where do those fit in agile development?