An Agile Spree

At the heart of Agile is flexibility. This is designed into sprints that are intended to account for changes rolled into subsequent sprints.

But, think of an overall backlog. A high level estimation will yield a given number of sprints. This structure actually is not very flexible at all. Unless, of course, each sprint has time allocated for reviewing, testing, and bug fixing. This is a slippery slope; a more substantial change can really throw off a sprint. So, how do you address the issue of quality?

I have recently been reading a lot about corporations paying others to hunt bugs in their software (say, a contest to find the most glaring security issue in an application). This crowdsourcing model is extremely effective. I don't see why similar concepts can't be applied to an agile process?

I'd like to introduce the idea of an agile spree. The basic idea is to interject a smaller sprint or time at the end of a sprint dedicated only to identifying and fixing issues. This is a three-step process: 1. discovery, 2. review, 3. implementation.

1. Discovery

Take a day or so and have everyone you possibly can look at the application (developers, QA, technical architects, and someone totally non-technical but familiar with the project objectives). This should be an "all hands on deck" strategy, having as many people as possible review the system.

Nothing should be off of the table. For instance, developers should review the code and make recommendations for refactoring or code-level enhancements. Non-technical folks should review the implementation and identify their expectations when "something does not look right". 

Items should be recorded in a common log for the review phase. This crowdsourcing will likely yield a diverse set of issues raised. Additionally consider a reward to the individual that identifies the highest number or most glaring of mistakes.

2. Review

After the discovery, the backlog decision makers should sit down to reconcile. Review each item found, eliminate duplicates, and determine which items to address and how best to address them. These items should form the backlog for this spree and potentially provide clarity for backlog items in future sprints.

3. Implementation

The spree's backlog should be assigned to project team members to complete the identified tasks.

I personally believe having a combination of sprints and sprees limit project risks by identifying issues close to when they are introduced to a project. Some would argue that a spree would add time and cost on a project. While I agree, I believe that sprees reduces the potential for adding unknown costs into a project while the project is happening. The "change order" conversation is always awkward. I would argue that it's better you can tell your client you have quality control procedures already built into the contract.

Keep in mind, the focus is on quality. This quality can be addressed in a planned manner with a spree as opposed to being forced. Consider two different scenarios: one in which you dedicate time to quality improvements and one in which quality issues come up organically in demonstrations and no time is allocated to address them. The latter adds significant risk, usually adds stress to developers, and then needs to be squeezed into a future sprint that may or may not be at full capacity already.  

Like any good agile recipe, a spree should be structured to meet your needs. The frequency and duration of the spree should vary depending on the project complexity. And, this is intended to be agile, don't hesitate to adjust the frequency and/or duration to better meet the needs of the project.

Consider adding a spree and crowdsouring your quality control on a project!