When facing an Agile transition, QA managers get worried. They don’t see a job description for a “QA manager” in...
the new Agile organization. The testers that worked for them are farmed out to cross-functional teams. Both the manager and the testers risk losing their identity and sense of value. Indeed, the development and product managers often don’t understand what testers contribute, nor do they value that contribution.
Too often, the resulting Scrum teams become silos, replacing the old development/testing /business analysis silos. They get focused on delivering code, and development degenerates quickly into mini-waterfalls where testing gets short shrift – just as it did in traditional waterfall!
Companies have been transitioning to Agile for more than ten years now. Why does this keep happening? What should and can we do about it?
The value of quality
Testers often end up reporting to development managers who see testers as “second class citizens.” Lack of attention to testers and testing activities is a symptom of the company undervaluing product quality. Many executives see “Agile” as a way to make teams “hyper-productive,” cranking new features out fast and furious. They don’t provide teams slack time to experiment with ways to improve their process or product.
When management doesn’t value quality, testers don’t stand a chance. As my colleague Janet Gregory notes, organizations who forget how to learn and grow will stagnate, and potential improvements that could come from moving to Agile development will be lost. Teams that don’t give testing the same attention as coding will pile up so much technical debt, they’ll slow down and possibly fail over the long term.
Let’s look at some reasons why companies shouldn’t eliminate the QA department without giving thought to how their development organization can maximize the value their testers can contribute.
If your company is planning a transition to Agile development, get all the development and QA/Test managers together to decide what they will do in the new Agile organization. Having testers integrated into cross-functional teams which take a “whole-team approach” to quality, works best. Plan time and training to help the entire team take responsibility for quality and testing and to embrace the whole-team approach.
Some organizations, especially large ones, may still benefit from having a separate system test team that makes sure different parts of the product work well together. If your company produces embedded software, or has many large systems that must integrate, you might need a full-time team focused on testing the integration between systems or between software and hardware. They’ll still work closely with development teams, and in most cases, the development teams should still include professional testers.
Create a testing Community of Practice (CoP) to support everyone doing testing activities, across the organization. Practice leaders can help nurture a learning culture, making sure teams have time to share ideas and try new experiments to improve software quality. When I led a testing CoP in a sizeable development organization, I created a wiki space where different testers and teams could ask questions, have a dialog, share ideas, post links to blog posts and more information. We held lunchtime meetings twice a month during which someone demonstrated their automated tests, continuous integration, exploratory testing ideas, anything related to testing. Interestingly, the community attracted programmers, business analysts and product owners as well as testers. It helped break down the “Scrum team silos.”
The Testing Practice Manager can also make sure testers get the training they need. A transition to Agile development is hard, and on top of that, we have advances in testing and test automation every day. Though the whole team is responsible for these activities, testers need to be up to speed with the latest skills and technology in order to help ensure testing “keeps up” with coding on their teams.
Demonstrating the value of testers
It’s our responsibility to educate the rest of the company about how testers add value. And if we’re transitioning to Agile, we have the opportunity to make sure every team understands and adopts the “whole-team approach” to software development.
One skill that testers possess is exploratory testing. Experienced exploratory testers aim to learn more about desired and undesired behaviors of the system. They aren’t just looking for what doesn’t work, they’re alert for missing features, and they’re applying critical thinking to many aspects of quality, not only functionality. Educate your development organization on the benefits of exploratory testing. One good way to do this is to have programmers pair with testers to try out some exploratory testing.
Another area where testers excel is domain knowledge. Programmers have to maintain a narrow focus, so they can complete specific coding tasks. Testers maintain a “big picture” perspective. Given a particular user story, testers think about the business problem being solved, the potential technical implementation, and whether that implementation will really solve the problem. Teams won’t succeed in the long run without good domain knowledge. Try budgeting some time for the team to learn more about some area of the domain. The testers will get a chance to lead the way.
Raising consciousness about quality
Lack of attention to quality and undervaluing testing isn’t unique to Agile companies, of course. We’ve battled these problems for decades. If you’re willing to take on the role of change agent in your organization, I highly recommend trying the patterns in Fearless Change (Manns and Rising, 2003).
Back in the DotCom boom, I was the first tester hired by a fast-growing Internet startup. Nobody in the company really thought about quality. I decided to try to educate everyone in the company about why paying attention to quality would help the company. One way I did this was to get the company to buy pizza, and I gave a lunchtime introduction to quality and testing. People from both the engineering and business sides of the company showed up, and showed an interest. Though I didn’t know it then, this is the Brown Bag pattern in Fearless Change: “Use the time when people normally eat lunch to provide a convenient and relaxed setting for hearing about the new idea.”
I also simply tried to earn my credibility. I worked closely with the product managers and the developers. When I found issues, we discussed them together. I knew my efforts were paying off when the developers asked me to come in and help them one weekend when they wanted to put in extra time on a project.
It’s tough to change a culture, and if you can’t identify the right pain points, you might not be able to instigate much passion about quality. Still, it’s usually worth a try. Find some creative ways to demonstrate the contributions of testers to your company.
Take time to experiment
Approach your Agile transition as a series of small experiments (a term I borrow from Linda Rising). Try integrating all the testers into cross-functional teams, while maintaining a testing Community of Practice. Use retrospectives to see how that works. Are teams allowed to manage their workload so that they can finish all testing activities for all user stories during each iteration? Are different teams checking in code that breaks functionality used in code other teams are developing? Is everyone struggling with load or security testing? Perhaps more training is in order, or maybe you need to try setting up some specialist teams to take on activities such as performance testing or system integration testing.
QA managers are needed to help these testers get the time, training and support they need. Make sure the testing community is represented in discussions of how to maintain and improve software quality. We don’t get high-quality software without a team that is diverse in skills and viewpoint. Make sure each role in your cross-functional teams is represented and supported at a high level. Use the Agile Testing Quadrants as a tool to discuss all the different testing activities needed, and make sure the right people are available to ensure they get done.
Above all, realize that successful Agile transitions don’t happen overnight. It takes years for the new teams to jell, for communication and collaboration among different roles and specialties to develop. It takes practice to keep teams and roles from becoming silos. Aim for baby steps, and celebrate every small success. Even if the old “QA Team” is history, you can still grow a vibrant testing community, which can help teams produce a high-quality product.