Agile Quality Tip 2: Embrace Policy as a Team

Feb 10, 2011

Posted by Parasoft

As we wrote previously, our current series of posts is covering 10 brief quality tips designed to help you extend well-known agile quality practices to ensure that your software satisfies business needs—effectively and efficiently.

Tip #2 is "Embrace policy as a team."

Policy is not traditionally associated with agile development testing—and many pure Agilists worry that the whole notion of policy contradicts the collaborative, lightweight nature of agile processes. Yet we have found that many teams working with agile development methodologies actually appreciate having clear expectations regarding how code should be written and tested. With expectations clearly defined, the team does not need to waste time trying to figure out exactly what is expected when—or constantly reworking the code to remedy misunderstandings.

You can start off by implementing a policy that simply formalizes the coding and quality practices that the team is already following.  Then, working from that baseline, you can incrementally introduce new policies that the team has discussed and agreed to follow.

Possible policy modifications can then be discussed in daily stand-up meetings, or during code reviews. This allows team members to provide valuable feedback regarding policy refinements (e.g., fine-tuning a static analysis rule to allow certain exceptions) and extensions (e.g., requiring additional test coverage on a module that QA reports as being especially buggy).

In addition to ensuring that the entire team is on board, it's also essential to ensure that the policy enforcement serves as a guide, not an intrusion. Ideally, an automated infrastructure checks compliance automatically in the background and works invisibly unless the agreed-upon expectations are not met. At that point, it figures out which team member should be notified, and reminds him or her to perform the tasks required to meet the agreed-upon expectations.

Agile Team Policies

Essentially, the automated infrastructure operates like an EKG system that is hooked up to a hospital patient, constantly measuring electrical activity. If everything is fine, it runs inconspicuously in the background. But if the readings start to flatline, alarms are sounded and people understand that action is needed.



Want to learn more ways to control defects during development? Read about Parasoft's Development Testing platform.

New Call-to-action