QA Overload - Agile with a quality assurance perspective

Be sure to also read Mike's Personal Blog, Continual Improvement at http://www.mikelunt.com/blog/.

One of the places where teams struggle is how to handle skill set imbalances within an Agile team. Where I’ve seen this more often at BMC is with QA. My assumption about why this seems to happen at BMC more often than in the general Agileshpere is (1) BMC products typically require more integration with other internal and external products, (2) BMC products often have years of legacy code that must continue to progress, and lastly (3) BMC products often have cross platform requirements across many different OS’s. This additional integration and legacy code creates larger than normal numbers of QA tasks compared to the typical Agile team working on a first or second version product. To cope, here are some suggestions:

1. As hard as it may be, resist the temptation to out-code the team’s ability to test. This will almost certainly not result in a faster release date but will most likely create negative customer consequences. If adjusting the team’s resources is not an option, continue on to the following suggestions.
2. Use developers to help with the testing. While I’m hoping my office doesn’t get TP’ed tomorrow, here are some ideas to ease this effort. Allow the developers to use an automated acceptance tool such as Fitnesse (http://fitnesse.org). This allows the developers to code/automate the tests and carry on with the iteration demos. At a later point in time, more test cases can easily be added by the QA team during full system testing, and there is a much lower rate of defects because the customer functionality has already been proven. In addition, implementing strict unit test compliance (ex. before code check-in) can also decrease the QA load by ensuring QA will run into fewer issues during the testing.
3. Remove the “QA” and “Dev” labels. This is essentially an alternate version of #2 but with a “poker chip analogy” twist to it. In nirvana Agile world, there really are no testers or coders; there are only story cards and tasks needed to complete those stories. (Ironically enough, this is how our customers see it as well.) Just as a poker chip creates a level of indirection between the actual money and the act of betting, making a truly cross-functional team helps to break the psychology of doing tasks which may not fall into one’s normal area of expertise. In this mode, everyone is working towards completing a set of tasks, and while certain tasks will most likely be chosen for people with relevant skill sets, anyone can and should be willing to take on whatever is necessary to get the project done. In the end, there is a list of tasks to complete an iteration, and each person is given tasks until a certain number of stories can be completed, which means tested as well.
4. Decrease scope or extend the release date. While obvious options, they are understandably the most resisted because of the desire to satisfy customer demands. If neither of these are an option, see #1. :-)