I made a difficult decision to move on from my incredibly wonderful agile team at ePlan Services to take on new challenges at the equally wonderfully agile Ultimate Software. This leaves the team at ePlan with four programmers and one tester (plus two system administrators, a DBA and a ScrumMaster).
Even with two testers, the programmers pick up some of the testing tasks – ours is a testing-intensive financial application. The programmers often document stories on the Wiki, write FitNesse tests as well as automating them, do manual testing, and investigate functional test failures in the builds. Everyone on the team is willing to wear multiple hats. The sys admins sometimes do development and testing tasks, the ScrumMaster sometimes helps with manual testing.
Conversely, we testers help with production support, occasionally take on a simple development task such as changing text in a report, fix SQL query bugs if the solution is obvious to us,and the like. It’s one of the things I enjoy most about working on an agile team. Nobody’s stuck in a pigeonhole, and everyone focuses on common goals.
In the past, when we’ve been down a tester, the whole team pitched in to take up the slack. For example, when our Ruby/Watir expert left a few years ago, every team member bought the Pickaxe book, and helped maintain the Watir scripts and even write new ones.
So, I was surprised the other day when I heard a plan to have one of the programmers, who started out here as a tester, revert to the tester role until a new tester could be hired. Yes, he’s a terrific tester, and indeed has continued to do some testing tasks along with coding work. But why should he have to abandon his new role, especially as he’s really getting traction with his new skills, to do testing activities full-time? It makes no sense. Naturally, with his experience in the tester role, he’ll be an important resource, but his job shouldn’t suddenly revert.
I reminded everyone of how we normally handle this situation. It was a bit of a “doh” moment as everyone realized the whole team approach to picking up the slack has worked so well in the past, and there’s no reason not to keep using it. Everyone can pitch in on testing tasks, just like always. Every role on our team is equally valued, so nobody feels that testing is somehow “beneath” them. Everyone is committed to delivering the best software possible. The team velocity will drop while they’re short a member, but quality won’t suffer.
The Whole Team approach to testing has been so effective on my teams, and I expect it will work well on my new team too!
