The whole-team approach to Agile development: Examples and benefits

In my recent tip, Agile development: The whole-team approach, I described the concept of the “whole-team approach.” By every team member assuming responsibility for delivering high-quality software, the cross-functional team develops stronger communication and collaboration skills that are crucial to Agile teams. In this tip, I give real-life examples of how the whole-team approach has added value for my team and explain why this approach is beneficial to an organization.

Examples of how the whole-team approach works

My current team is typical of many Agile teams today.  We have a developer living in India, a DBA who works from home three days a week and system administrators who are pulled in multiple directions by business demands. Our small company is now owned by a large, geographically distributed one. There are always new problems to solve, and because we have “gelled” as a team after many years, we are up to the challenges.

We recently had a sprint where each of the two testers was on vacation for several days (fortunately, not at the same time). Testing fell behind. Nanda, the developer in India, stopped working on new code and took on the testing tasks for one of the stories. He let us know about some bugs first thing the next morning, so they could be fixed right away. Another developer, Mike B., pitched in to update some automated tests for a part of the UI that had been changed. The other two developers, Mike T. and Vince, did some general exploratory testing to verify that the new user stories hadn’t caused any unexpected system behavior. We were able to finish all the stories in time for the release.

Here’s another story of the whole-team approach in action. Last week, an operations manager told us she was getting unexpected emails that looked like production emails, but they were coming from one of our build machines. Our tests are supposed to override actual email addresses with a test distribution list, and the override had stopped working. Lori, the other tester on my team, did some detective work and determined that the emails were coming from a particular FitNesse suite. However, we couldn’t tell which test caused the problem, as many of the tests could generate emails.

Mike T. discussed the problem with Tony and Steve, the systems administrators. Nobody asked Mike to do that, and Tony and Steve didn’t say, “This isn’t our problem.” We had a problem, and they naturally wanted to solve it. Tony ran the FitNesse suite in the debugger and isolated the problematic test. Mike T. found some crazy code in a five-year-old FitNesse fixture that had started ignoring the email address override that tests are supposed to use, due to a refactoring of email code. He updated the fixture code, and the problem was solved.

Why the whole-team approach wins

Having a diversity of skills, experience and viewpoints is a giant advantage when you have tough problems to solve. New Agile teams face a lot of pain. For example, test automation is hard to master, yet we know our project can’t succeed in the long term without it. Using the whole-team approach, we are able to take advantage of a wide variety of skill sets to help find a successful automation strategy. Because everyone’s thinking about testing, it’s likely that the code will be designed to make testing easier. We can support each other as we overcome what Brian Marick calls the “hump of pain,” where at first, automation just adds to our work and doesn’t start delivering benefits until we achieve a critical mass of test code.

This team effort helps overcome the fear barrier. Knowing that our diverse co-workers are ready to help gives us courage and confidence. We may identify skills that are lacking on our team, and we can plan time to learn or bring in specialists to help. Even when we get outside help, though, the whole-team approach means that Agile teams take responsibility for making sure all testing activities are completed.

Does this mean we should never have separate test teams? No, there are valid reasons to have independent test teams that do specialized post-development testing. There may be firmware that has to be tested with external hardware, or perhaps someone needs to verify that large independently-developed systems work together. If there are separate test teams, they should work closely with each development team throughout the project, finding ways to improve quality and testing.

Adopting the whole-team approach takes time, experimentation and learning. Start by getting your team together to talk about your commitment to quality. Do you intend to deliver the best software you possibly can? If so, it’s time to make that commitment mean something. Don’t make excuses when you run into the inevitable obstacles. Work together to make progress in baby steps, overcome impediments and delight your customers.