The stated motto of this year’s Agile Testing Days was “The Agile Movement is Thriving! How Does It Affect the Future of Software Testing?” and for me, the answer that came back was: “by focusing on valuing individuals and interactions over processes and tools”.
When I say that, I mean that this was an implicit message, (there were no ‘Agile fundamentalists’ running around calling for a return to that particular statement from the Agile Manifesto). In the presentations, and in the conversations with speakers and delegates, the message I picked up was that many had learned through (often negative) experience that the values embodied in that Manifesto statement were crucial to the future of software testing (whatever that may hold).
Of course, I’m a big exponent of the notion that it is all about people (my ATD talk was another attempt to encourage folks to use Belbin Team Roles as a tool to develop better understanding within teams) and I accept that I’m likely to have heard what particularly appealed to me, but I will point out just a couple of talks that highlight this theme.
On Day 2, Bob Marshall gave a fascinating talk on his “Anti-matter Principle”, that is: Attend to folks needs. The argument being that if you abide by this principle you do not need to worry about anything else (anti-matter being the most expensive thing on Earth). That’s the basic summary, but there was a lot in the talk, including non-violent communication and motivational theory (Theory X & Y), which warrants chewing over in slower time.
My gut reaction is that meeting folks’ needs leads to dependency and disempowerment, so maybe there needs to be some distinction between felt need and ‘real’ need, but I still think it is great to hear someone say at a ‘technology’ conference that software development is all about meeting folks’ needs.
Antony Marcano’s Day 3 Keynote seemed to particularly strike home amongst the ATD crowd. Entitled “Don’t Put Me In A Box”, he used his life story to highlight the importance of not being pigeon-holed as a tester and adopting different roles to increase agility.
In one useful illustration, he referred to the ‘Read’ method the military use for entering premises. The basic idea is that the door entry expert in the team breaks the door down, but the others are first in. If there are further doors, it would take too much time for the expert to reposition themself, so the first person there simply breaks the door down each time, regardless of their expertise. Marcano likened this to software development, where all of the development team pitch in to do whatever needs to be done (including testers).
Of course, there is a danger in going down the “we’re all developers” route of encouraging teams to be full of jack-of-all-trades generalists. In so doing we could lose the value contributed by professionals who are dedicated to their particular specialism.
However, I think Marcano’s analogy can be taken further to guard against that. In the Read method, the door entry expert was the trained, dedicated explosives specialist. When there was a difficult entry to be made, the team still deferred to this individual. For the sake of agility, it makes sense for test specialists to take on generalised skills, just as it makes sense for explosive experts to do so. But, when you are looking for someone to blow your door down, you’d expect the door entry expert to be the best at their job, not just some generalist who knows a bit about explosives!