Fascinating phenomenon noted by Kevin Rutherford at Silk and Spinach (post here). As he notes in his original post (here), a good tester (or testing team) can tempt developers to outsource all quality management to the testers.
However, because this is described as an “agile” project, I’m curious: What flavor of agile was used? It sounds like that the “bad code” developers were throwing code over the wall to their tester, which seems like a parody of a waterfall life-cycle.
The lack of details leads me to wonder how well the poorer-performing team was organized and led. Per Kevin Schlabach’s comment, I’d expect that testers would be in the sprint team already. That sounds like pretty standard practice. I wonder about the team dynamics as well. Lots of questions on that point:
- Where there interpersonal issues?
- How short were the effective iterations? In other words, did the poorer-performing team behave more like a waterfall team, waiting until the last possible moment to turn over code (or did the tester only accept code at that last possible moment)?
- Implied in Kevin S’s comment are questions about the relative strengths of the sprint/iteration teams. If the business team was working closely w/ developers, how did the tester end up testing so much crap code?
Filed under: Quality Management | Tagged: agile, agile development, iterative development, Kevin Rutherford, Kevin Schlabach, SCRUM, Silk and Spinach, Test Management, Testing |
Crossderry Blog 
Thanks for confirming the thoughts… I’m glad another person is weighing in on this also!
Let’s compare this to an analogous situation. Say there is a pharmaceutical company trying to develop new drugs. The company has an excellent clinical trial process that is very proficient at determining the safety and efficacy of drugs. Given the company’s situation would it make good sense to turn a team of brilliant chemists loose in the lab to find new drugs? What obligation do the chemists have to requirements like usefulness as a medicine, side effects or public safety? How about feasibility and profitability to manufacture these drugs? Having many hyper-productive “cowboy chemists” may produce a large number of compounds, but the company’s goal of bringing useful drugs to market *profitably* is not being met. Expending resources on clinical trials and risking drug recalls wouldn’t be seen as a sensible strategy. Yet, in many software development projects this is exactly the strategy that is praised: write lots of code unencumbered by insight or feedback on requirements, QA under the sword of Damocles, and release expecting to patch things in the field.