The Test Manager's Survival Guide to Going Agile


Joel Bancroft-Connors presents a survival guide for testers going to agile. Joel explains what happened when he had to make the switch from waterfall to agile. Welcome to the world of being an agile manager, in which your team is a top performer, doing more in the same amount of time as before.

"You'll pry waterfall from my cold, dead, hands." 

I uttered these words to an agile evangelist years ago. At the time I had no greater certainty in life that this was the unshakable truth (being a Californian I should have known that even the strongest foundation can be broken). Today I am an ardent evangelist of agile principles. I can't fathom how I ever allowed myself to be so blinkered that I was unwilling to even consider agile. 

Okay, that's not really true, I can fathom why. 


I was terrified that in an agile world, I wouldn't have a place. That I wouldn't have a job. Ultimately, it was a fear that I wouldn't have control. Not a surprising fear considering the definition of “manager,” as stated by

Manager: Noun, 1. a person who has control or direction of an institution, business, etc., or of a part, division, or phase of it.

Agile was telling me I didn't have control anymore. Control lay with the "team" and the team certainly didn't have anyone with a "manager" title in it. The ScrumMaster had the closest thing to a manager title (it started with "m," I'm stretching here) and the role had nothing to do with being in charge. Instead it was focused on this strange term, "servant leader." What the heck is a servant leader? Am I supposed to lead the horse to water and then serve him from a silver pail? Management is supposed to be the leader, right? And managers are in control, right? How can I be a servant in control? 

The role of the product owner (PO) didn't give a lot of comfort, either. Sure, the role looks like a product manager. But for those of us paranoid, agile would change our worlds, for the ill; we quickly saw the PO role as also part project management and functional management. This person decides the direction of the project and agrees if done is really done. Where did the PO role leave manager managers? 

QA managers have an additional level of fear layered over the fear all managers have. In speaking with my QA colleagues, I’ve heard some common themes, like the following: 

The development teams get coaching on pair programming or TDD, while testers get nothing. Agile teams often add QA as an afterthought. The developers are doing the testing, if my team isn't needed, I won't be needed. You have to be able to code to be a tester in agile. If QA is part of the team, and the dev manager is responsible for the team, what's my job? The team is setting the schedule, the team’s mostly coders, we won't have enough time to do testing, QA will be blamed. 

With all these fears and worries piling up, is it any wonder managers are resistant to being pushed into agile? In all the time I've worked in agile, I personally can think of only a handful of instances in which a manager pushed into agile didn't approach it with all the trepidation of a rabbit entering the lion's den. And in a reality in which first impressions are king, a bad first experience often leads to your last experience. 

This almost happened to me. My first experiences in agile were akin to a train wreck in slow motion, with every frame being managed by a hyper-controlling executive team. Fortunately for me, the agile evangelist I told to take waterfall "from my cold dead hands," took it as a challenge. He took the time to explain what agile really was and why, as a manager, I was still very much valued and needed. 

Agile Primer in 500 Words or Less
First, let's get a key misconception out of the way. Agile isn't a project methodology. Agile is set of four values and twelve principles used by teams as a guide to create something better; originally, agile was used in software, but now it’s used in countless different industries. 

Next, Scrum is not agile. Scrum is a light-weight project methodology based on agile’s values and principles. There are several ways to run an agile program, and Scrum is just one suggestion. A bad experience with Scrum doesn't invalidate agile’s value. If you're using big design up front (waterfall) and the program goes awry, is all waterfall bad or was that program mismanaged? 

Agile's first principle begins with "Our highest priority is to satisfy the customer." Okay, let's turn this around. I'm a manager and I have to use this thing called "agile." What's in it for me? What are my benefits? 

User Comments

1 comment

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.