Does a Scrum team need an Agile Test Lead?
Posted by Matt Archer on December 15, 2011
‘Agile Test Lead’; it sounds like a reasonable title, but it could be interpreted as going against agile principles. ‘Test’ smacks of being role specific. Not the kind of separation you want to encourage if you are aiming for a team of multi-disciplined individuals. And ‘Lead’. It doesn’t sound as bad as ‘Manager’, but it still suggests an element of hierarchy, rather than a self-organising team of peers.
So why when I Google ‘Agile Test Lead’ does it return so many hits (369,000 to be exact). I haven’t invented it as part of writing this post and it’s obviously more pervasive than a few old-school software houses clinging onto their roots whilst also trying to embrace agile principles. So what is an ‘Agile Test Lead’, if I was hiring one, what would I expect them to do and is it a role that will stand the test of time?
I would always expect an Agile Test Lead to roll their sleeves up, get their hands dirty and contribute towards the release like every other team member. This includes testing during every sprint, on a daily basis, not just when the team is busy. If you are familiar with the analogy of the chicken and the pig that discuss opening a restaurant1, I believe that every member of the team should see the Agile Test Lead as one of the pigs, not a chicken.
With the 10th anniversary of agile software development behind us2, you may be surprised to hear that I believe many agile practices remain a mystery to people, testers included. The mind shift for a tester that has never worked in an agile environment before can be significant, but this challenge is not restricted to those without experience. Due to the different practices that exist between one agile team and another and the different interpretations that teams make, even testers with previous agile experience can be left confused when they join a new agile team.
I believe a good Agile Test Lead should be able to help demystify agile testing practices, not just in terms of regurgitating what it says in the books (people can read the books for themselves), but through explaining why specific practices have been chosen and illustrating how those practices have been tailored for that particular project, paying careful attention to any deviating from the textbox definition.
It could be argued that the team as a whole should share the responsibility of guiding new members. I couldn’t agree more – this should never be a single person’s responsibility. But with so many overlapping agile practices related to testing I also find it useful to have an experienced voice that can help guide new testers as they join the team (and any other member of the team for that matter).
If you are curious about whether your project would benefit from such specialist knowledge, try this simple test. Ask a random member of your team if they can explain the differences between Test Driven Development, Behaviour Driven Development, Agile Acceptance Testing and Specification by Example. If you’re feeling really brave, go a step further and ask them how testing fits into each of these practices and which tools they would shortlist to support their implementation.
I rarely meet people that can answer these questions, but I frequently meet testers who want these questions answered. It is for this reason that if I were to hire an Agile Test Lead I would want them to be able to answer these questions, plus many other questions related to testing in an agile environment.
Agile software development processes, such as XP and Scrum, have challenged the testing community to think about how we test.
As an example, there are few agile projects that can point to a hierarchy of test documentation that cascades from a Test Policy, to a Test Strategy, to a Master Test Plan to multiple Phase Test Plans. Why? Because, historically these documents have taken several days (sometimes several weeks) to produce, by which point the typical agile project is in their second, third or even fourth sprint. Consequently, most teams conclude that this style of test planning is not compatible with agile software development.
Another example is performance testing. It is common for teams to use a dedicated performance testing expert (sometimes in-house, sometimes external) to understand where their application fails to meet expectations. Combine the long lead time often associated with this style of resourcing with other restrictive factors often associated with performance testing (such as intermittently available test environments and limited test tool licenses) and you can see why performance testing can also be difficult to integrate into an agile project.
There are countless other testing practices that are at odds with agile software development, but many of them were never designed to be used in an agile environment. It is difficult to dismiss decades of tradition, especially if it is engrained in an organisation’s culture, but this is exactly what a good Agile Test Lead must be able to do. When a team is new to agile software development, few things can be more troublesome than trying to wrap traditional practices in sprints and iterations. It’s a tough job, but a good Agile Test Lead should know, and be able to communicate, which testing practices should be left in the past and which should be embraced in the present.
Unfortunately, this task isn’t simply a case of dismissing old practices and picking new practices from a predefined list. Such as list doesn’t exist and even it did, it wouldn’t contain all the practices that a team needs to be successful. It is for this reason that a good Agile Test Lead must recognise the need for innovation, be able to innovate themselves, and most importantly, champion and support innovation within the team related to testing. The most successful agile testing efforts I have seen have taken popular practices, tweaked them a little, before finally surrounded them with their own, home-grown practices. Unfortunately, many people still believe that testing is the same today as it has been for the last 20 years, but this has never been further from the truth. A good Agile Test Lead must not only recognise this personally, but also help others appreciate the innovative solutions that are often required to test in an agile environment.
One of the things I like about agile software development is the collaborative practices. Group bug hunts, pairing testers with developers and fleshing out stories as a team all help reduce the blame-game and improve the team as a whole3 by breaking down silos4.
But life is always a compromise and whilst working as a team can improve many aspects of software development it isn’t a silver bullet. In fact, it could be argued that spreading testers throughout a team (rather than having a dedicated test team) introduces its own set of problems, especially as teams grow or become geographically distributed.
One such problem is related to sharing knowledge between testers, improving testing practices and optimising the way that testers work. With this in mind, I believe that a good Agile Test Lead should be able to take a step back and look across every aspect of testing, identify areas of weakness and help facilitate their improvement, often by facilitating the personal development of one or more testers. This doesn’t need to be a time consuming task. It can be as simple as getting Tester A to talk to Tester B, arranging for Tester C to run an informal lunchtime learning session or opening budget holder’s eye to the need for training for Tester D.
Once a team is up and running with agile, I believe it is the tiny micro improvements that help a team reach hyper productivity5. What can seem like a small inconvenience can significantly affect a team’s velocity if they are left to fester. It is for this reason that I believe a good Agile Test Lead must be able to identify opportunities for improvements, however large or small. Below is a list of sample questions I would expect a Good Agile Test lead to ask, should the situation arise.
– Is there a consistent way that testers install the latest build on their machine or is each release individually installed by hand?
– Is there a reason why some testers are using JUnit, whilst others are using TestNG as their execution framework for automated tests?
– Where does each tester store their test automation code, how often is it run, and most importantly, how often does it break and need to be repaired / maintenance?
Are Agile Test Leads here to stay?
I frequently meet people who refer to themselves as an Agile Test Lead, many of which fulfil a role similar to the one that I describe above. Was their role part of the original agile blueprint? – Certainty not. But I have no doubt that for many teams this is an essential role.
Being an Agile Test Lead is undoubtedly a practical role, but with subtle connotations of coaching too. I believe it is this coaching element that makes many Agile Test Leads tremendously valuable to the projects they serve, often more so than external agile test consultants who lack the day-to-day exposure necessary to understand a team’s subtle needs.
Are Agile Test Leads here to stay? – I think so, at least in the short to medium term. Agile software development has hit the mainstream, but many projects still have a long way to go. I have no doubt that a good Agile Test Lead can help a team progress towards a way of working that delivers the benefits associated with agile software development. Once a team has reached this milestone, maybe the need for the role becomes less important, but with so much change happening every day in the world of software development, who knows what he future will bring.
A Wikipedia page explaining the chicken and pig analogy
A blog by Mike Cohn, reflecting on the 10 years since the agile manifesto
A blog by Kelly Waters in which he describes the problems associated with sub-optimisation
A blog by Elisabeth Hendrickson in which she explains why silos can dramatically increase the cost of test automation
A presentation by Ryan Shriver introducing hyper-productivity