Calculating QA Costs – Agile Anarchy Method (AAM)

Continuing the theme of QA costing methodologies, Just Test Something (JTS) and Backing In Costing (BIC), Service Planning Costing (SPC). The intent here is not to claim one model as king, but rather to evaluate the potential benefits and pitfalls of relying on one model exclusively.  My hope being that by sharing these approaches, QA organizations will evaluate their current models and perhaps find room to tune them for greater excellence.

Let me start by saying, Agile Anarchy Method of COSTING is not the full Agile methodology. Agile Anarchy Method (AAM) is about focusing on maintaining a certain agility (anarchy) in order NOT to be tied to fixed costs.

It’s about the bleeding costs of Agile, selectively applying only parts of Agile methodologies to development process. AAM is usually used in organizations were there are frequent changes to environment, QA scope or the software being tested. It can even be found in organizations following a more traditional waterfall process for development. Its also common in rapidly growing or newly founded organizations, where immature process and reactive planning is sometimes dressed up by calling it Agile, vs having to admit that its really just Anarchy. 

AAM Inc is growing fast, in the last 12 months the company has doubled in size and acquired a second company of nearly equal size effectively quadrupling.  The new CIO is currently structuring a integrated organization, and charged with integrating the back-office of both companies. The newly amalgamated development organization is working in Agile teams, working in 2 week sprints, while the integration project is still being scoped. QA is not currently a independently managed group, and each development team is responsible for doing their own QA. Each team develop determines their own test plan, tools and process. There is no integration, automation or cross team testing / regression/ performance testing being done. The costs of QA are calculated by each team estimating the % time spent on QA activities.

It’s unplanned, unstructured, reactive and subjective. One engineer team may see QA very differently than the next, listing time spent on QA anything from 10% to 70% of their time. In newly minted, and unknown environments, there may be little choice at first, but sometimes, for some reason or simply lack of desire to correct it,  this anarchy can last indefinitely.

Advantages

  1. Works in environments were requirements are yet to be defined and in severe turmoil. It allows for “hitting the ground running” without having to consider test times, process and other planning.
  2. Default in environments were developer and the tester is the same person with multiple hats and supports very small teams well.
  3. Can become structured by overlaying a QA team, doing final integration, regression and performance testing.
  4. Can allow for certain cost centre manipulation, since the amounts and time spent is subjective.
  5. As long as there is money….

Disadvantages

  1. It Bleeds money, with no real control. If more QA is “needed” it is “taken”. There is no understanding of true QA costs
  2. No final QA can leave integration, regression, performance, security and other aspects untested
  3. Quality can be inconsistent, and with little understanding as to which team or Sprint did what. Missed defects becoming deeply buried.
  4. Tools are often haphazard, selected by the developer/tester personally, leaving no ability to consolidate it later on or automate.
  5. Often there is little incentive to improve quality, improve process, or skills. The focus firmly placed on code generation vs. quality.

CONCLUSION

Again, I do wish to stress the difference between Agile and Agile Anarchy. Agile Anarchy selectively picks Agile ideas, without following the full methodology.  It appeals to rebel, wanting no structure or constraints. The result however is the same for the Quality and the cost.