I have been in a number of places where people, mostly QA Managers or Testing Directors, start talking about how they see uncertainty and even a level of threat from the wave of Agile expanding throughout the Testing and Development worlds.
This always seemed a little strange to me, especially after having been on a number of teams where Agile was properly implemented, and being able to experience first hand how this change was beneficial to the whole company and especially empowering to the testers within the teams.
Then, last week we had the roundtable discussion session about the 2016 State of Testing with Matt Heusser and Keith Klain, and this is when, as part of the conversation we were having, everything suddenly started to make sense…
The transition to Agile is really not scary to all testers and QA Managers.
Agile testing is mostly frightening for the disconnected QA Managers or Test Leads, as it takes from them most of the “formal” influence conferred by their job titles and their bureaucratic management skills, and it leaves them no choice but to generate real value based on actual work and their testing knowledge.
Are You a “Disconnected” Manager?
I want to make a quick pause here, before many of my friends press send on their hate emails and SMS messages to me, to explain what I mean by “disconnected” managers.
Disconnected Managers are all those managers who keep busy handling only people, and are not connected anymore with the actual work of their teams.
These are the guys running all day from “strategic planning”, to “lunch update”, to “afternoon review meeting”; and have then no time to really understand what is going on in their products and the actual challenges their teams are facing.
They are the same guys who are more interested in the way numbers compare to other numbers than in understanding the actual meaning and the interpretation behind these numbers.
And what always struck me as ridiculous is that these are the same guys that make really important decisions without actually knowing what these decisions mean, since they don’t understand the products or the teams they are deciding for!
If you don’t see yourself in these examples, then I am not talking about you.
And if you do, I’m sorry…
Why “Disconnected” Managers Need to Be Afraid of Agile Testing
I don’t think these guys are exaggerating.
If I was in their position I would also be afraid for my job too.
Agile testers are usually incorporated organically to be part of self managing teams, and so they stop reporting directly to the QA Manager. If this is the case, then disconnected QA Managers will have no direct control or responsibility over their testers.
If this isn’t enough, in Agile the testing tasks are carried out by every member of the team, and so the work and the results of testing are going to be part of the deliverables of the team, and not the exclusive responsibility of the Testers or the QA Manager anymore.
To make things even worse, Agile teams that understand the principles of their work will place Quality as a core objective of their process, and so they don’t need someone to remind them all the time about quality and testing, and they surely don’t need someone whose job is to threaten them if they don’t plan to test or reprimanding them if they didn’t.
All in all, in Agile teams Quality is not a burden or a problem, just as testing is not a dirty job that someone needs to take upon himself.
There is Still a Great Deal of Value to Be Provided By Good Test Leads and QA Managers
Am I saying that the jobs of the Test Lead or QA Manager are not relevant or needed anymore? This is far from the truth!
There are more responsibilities and challenges around testing and QA that need to be managed, and so the work of a QA Manager or Lead is greatly needed.
As the job of testing becomes decentralized this means that there will be a lot more coordination to be done. A lot of time will be spent in communication, sharing knowledge, and managing dispersed efforts in order to make sure people are working in a coordinated and efficient way.
As I wrote above, there will be more people doing testing, and this means more testers and developers to mentor and to make sure they are testing the system correctly.
A great advantage of having developers doing testing, is that testing can become more technical and advanced faster. There are tons of things to organize in this, and lots more resources to take advantage of.
And finally, as the teams work better you will need to spend less and less time putting out testing fires, and so you will be able to spend more and more time improving the overall Quality Processes of the whole Company!
The Three Main Problems for QA Managers in This Situation
There are significant challenges for any QA Manager who’s organization is transitioning into Agile.
- You need to go back to doing hands-on work, taking on projects and performing the actual tasks instead of just telling people what to do and providing feedback when needed. Just like an athlete starting to run after a period of inactivity, your muscles will not be fit for the whole workout from Day-1. Take this one step at a time, and if you were a good tester in the past you will see how you get back to your proper testing pace quickly enough.
- It is harder to convince people to do what you think is right when you don’t have direct authority over them, especially when this means they need to do things they like less, or that will make them work slower.
This is a challenge of all matrix management schemes, and you will need to find ways to convince people to see things your way.
- Company culture has been measuring success by heirarchical position. Now you need to value success based on a completely different measuring system. On the other hand, switching to Agile is not only a change in the way people work, but also a change in the culture of the company.
Agile Still Not Commonplace
During the State of Testing session, both Matt and Keith agreed that based on their experience many companies who think they are switching to Agile are actually not doing this.
As they said during the session, doing daily stand-up meetings, dropping their bug tracking system, and organize their work based on 2-week calendar sprints, does not mean you are working Agile if you still keep many of the processes and the approaches you still had in the past.
And so if, for example, your team runs the project having 1 or 2 Design Sprints, followed by 2 to 5 Development Sprints, then 3 to 5 Testing and Debugging Sprints, and finally 1 or 2 hardening sprints, before releasing the product into production or sending it to your customers… In cases like this, your job as a traditional QA manager is assured for years and years to come.