We’ll talk specifically about how organizational culture affects testers working in an agile environment. The bibliography contains resources that deal with other cultural aspects that may affect teams.
Quality Philosophy
Consider an organization’s quality philosophy in terms of how it determines the acceptable level of software quality. Does it tolerate poor quality? Does it take customers’ quality requirements into account, or is it just concerned with getting the product into the customers’ hands as fast as it can?
When an organization lacks an overall quality philosophy and pressures teams to get the product out without regard to quality, testers feel the pinch. A team that tries to use agile development in such an environment faces an uphill battle.
Some organizations have strong, independent test teams that wield a lot of power. These teams, and their managers, might perceive that agile development will take that power away. They might fear that agile runs contrary to their quality philosophy. Evaluate your organization’s quality philosophy and the philosophy of the teams that enforce it.
Periclass="underline" Quality Police Mentality
If an existing QA team has assumed the role of “Quality Police,” its members usually enforce quality by making sure code reviews are completed and bugs are religiously entered into the defect-tracking systems. They keep metrics about the number of bugs found, and then are charged with making the final decision as to whether to release the product.
We’ve talked to testers who brag about accomplishments such as going over a development manager’s head to force a programmer to follow coding standards. We’ve even heard of testers who spend their time writing bugs about requirements that aren’t up to their standards. This kind of attitude won’t fly on a collaborative agile team. It fosters antagonistic behavior.
Another risk of the “Quality Police” role is that the team doesn’t buy into the concept of building quality in, and the programmers start using testers as a safety net. The team starts communicating through the bug-tracking system, which isn’t a very effective means of communicating, so the team never “jells.”
Read on for ways to help avoid this peril.
Companies in which everyone values quality will have an easier time transitioning to agile. If any one group has assumed ownership of quality, they’ll have to learn to share that with everyone else on the team in order to succeed.
Whole-Team Ownership of Quality
In Chapter 1, “What Is Agile Testing, Anyway?,” we talked about the whole-team approach to quality. For many testers and QA teams, this means a mind shift from owning quality to having a participatory role in defining and maintaining quality. Such a drastic shift in attitude is difficult for many testers and QA teams.
Testers who have been working in a traditional setting might have a hard time adjusting to their new roles and activities. If they’ve come from an organization where development and QA have an adversarial relationship, it may be difficult to change from being an afterthought (if thought of at all) to being an integral part of the team. It can be difficult for both programmers and testers to learn to trust each other.
Skills and Adaptability
Much has been observed about programmers who can’t adapt to agile practices—but what about testers who are used to building test scripts according to a requirements document? Can they learn to ask the questions as the code is being built? Testers who don’t change their approach to testing have a hard time working closely with the rest of the development team.
Testers who are used to doing only manual testing through the user interface might not understand the automated approach that is intrinsic to agile development. These testers need a lot of courage in order to face their changing roles, because changing means developing new skill sets outside their comfort zones.
Factors that Help
Although there are many cultural issues to consider, most QA teams have a focus on process improvement, and agile projects encourage continuous improvements and adaptability through the use of tools like retrospectives. Most quality assurance professionals are eager to take what they’ve learned and make it better. These people are adaptable enough to not only survive, but to thrive in an agile project.
If your organization focuses on learning, it will encourage continual process improvement. It will likely adopt agile much more quickly than organizations that put more value on how they react to crises than on improving their processes.
If you are a tester in an organization that has no effective quality philosophy, you probably struggle to get quality practices accepted. The agile approach will provide you with a mechanism for introducing good quality-oriented practices.
Testers need time and training, just like everyone else who is learning to work on an agile project. If you’re managing a team that includes testers, be sure to give them plenty of support. Testers are often not brought in at the beginning of a greenfield project and are then expected to just fit into a team that has been working together for months. To help testers adjust, you may need to bring in an experienced agile testing coach. Hiring someone who has previously worked on an agile team and can serve as a mentor and teacher will help testers integrate with the new agile culture, whether they’re transitioning to agile along with an existing team or joining a new agile development team.
Sustainable Pace
Traditional test teams are accustomed to fast and furious testing at the end of a project, which translates into working weekends and evenings. During this end-of-project testing phase, some organizations regularly ask their teams to put in 50, 60, or more hours each week to try to meet a deadline. Organizations often look at overtime as a measure of an individual’s commitment. This conflicts with agile values that revolve around enabling people to do their best work all the time.
In agile projects, you are encouraged to work at a sustainable pace. This means that teams work at a consistent pace that sustains a constant velocity that permits maintaining a high-quality standard. New agile teams tend be overly optimistic about what they can accomplish and sign up for too much work. After an iteration or two, they learn to sign up for just enough work so no overtime is needed to complete their tasks. A 40-hour week is the normal sustainable pace for XP teams; it is the amount of effort that, if put in week in and week out, allows people to accomplish the most work over the long haul while delivering good value.
Teams might need to work for short bursts of unsustainable pace now and then, but it should be the exception, not the norm. If overtime is required for short periods, the whole team should be working extra hours. If it’s the last day of the sprint and some stories aren’t tested, the whole team should stay late to finish the testing, not just the testers. Use the practices and techniques recommended throughout this book to learn how to plan testing along with development and allow testing to “keep up” with coding. Until your team gets better at managing its workload and velocity, budget in extra time to help even out the pace.
Customer Relationships
In traditional software development, the relationship between the development teams and their customers is more like a vendor-supplier relationship. Even if the customer is internal, it can feel more like two separate companies than two teams working on a common goal of producing business value.