Lisa Crispin

Agile teams are best suited for organizations that allow independent thinking

For example, if a company has a hierarchical structure and encourages a directive management style for all its projects, agile teams will probably struggle

Consider an organization’s quality philosophy in terms of how it determines the acceptable level of software quality

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

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

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

If your organization focuses on learning, it will encourage continual process improvement

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