The Test Manager's Survival Guide to Going Agile

"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. 

Fear... 

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 Dictionary.com

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? 

Product managers get the benefit of flexibility and of building what matters most, first. They also get the customer involved early or ship to the customer faster. Developers have a direct voice with agile. Developers are empowered to create solutions based on need, not on technology. Executives get the power of predictability, and predictability leads to happy shareholders. But what about managers? What about QA? 

QA (QE, testing, etc.) can build quality into the product instead of correcting quality after the fact. Another benefit is early triage. Even when you’re not baking in the quality from the start, if you get to see the bugs before they are weeks old, getting them fixed is a lot easier.

How about less blame? Being at the end of the process, QA often gets blamed for "not finding the defect." If the defect wasn't there in the first place, because QA was brought into the process earlier, then QA can't get blamed for not finding the defect; it never existed in the first place. 

And managers, do you really want to be looking over your team members’ shoulders every day? Is your deepest desire to worry about every detail of every line of code? Does it really matter if they use QTP or Selenium, so long as they get the desired results? Turning around the coin, how would you like to be able to help your team grow? Would it give you pride to say "Over 75 percent of my team has been promoted in the last two years?” 

Agile gives your team the ability to what they do best: create. It gives you the ability to do what your team needs the most, which is helping them grow.  

This is what turned me around to agile. I came to realize my job wasn't about managing (controlling) people or projects. It was to help the team get from point A to B and help each individual on the team achieve their professional goals. To twist an old Bill Clinton quote, "It's about the people, stupid." 

Tips and Tricks for being an Agile (Test) Manager
Okay, let's set aside whether agile is good or bad. There are probably terabytes of data written on this topic already and we're not going to rehash it here. Like it or not, you are working in an agile environment. Now what? 

Well you could dig your heals in and refuse to change. "Horse carriages worked for the founding fathers, I don’t need a car!"

And if you're here at StickyMinds, I'm guessing that's not the approach you want to take. So here are a few pieces of advice for being a manager in an agile world. 

You Need Trust
Corny, I know. It still doesn't lessen its importance. The fifth principle of agile says "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." While the least actionable tip here, it is the most important for all the others rely on this fundamental. A child won't really learn to ride a bike until the parent lets go. This is the same principle for management: you have to trust your directs to do the right thing, which requires letting go. 

Focus on the Person, Not the Process
Following process can be taken to such extremes as to become the fodder of Dilbert cartoons or “Office Space” memes. Bad process can really mess up a team. If the process says you must check-in code before starting testing, does that mean you can't have a tester do a code review of a developer’s code before check in? I've seen it happen. 

How do you focus on people and not process? As Stephen Covey said "Keep the end in mind." If the goal is zero ship stopper bugs, does it matter how the team gets there (within constraints of budget, ethics, and the law)? Whenever you are faced with a process, try applying "The Five Whys" to it. While designed to find what went wrong, The Five Whys are also excellent for examining if a process is needed.

Manager Tools
About the same time I woke up to the value of agile, I also discovered Manager Tools. Their podcasts and resources provide actionable, easy-to-use tools to make you a better manager. The “Basics Podcast” series is quick to absorb and gives you the organization’s core foundations of good management in the form of the Manager Tools trinity. The trinity includes one-on-ones, which are weekly meetings with your directs, focused on your direct; the feedback model, a systematic way to provide feedback on your direct’s behaviors; and the coaching model, a simple process for how you can guide your direct as they improve their skills and abilities.

If the basics resonate with you, I absolutely recommend going back to the first podcast and listening to them all. Their podcasts are designed to be timeless, and all the advice still applies today. Many of the people I’ve given this advice to have done just this and thanked me when they’d finished listening to all the casts.

Agile Team Reviews
Your team members are humming along nicely. You're focusing on guiding and growing them and haven't stressed out about a metrics report in months. Then along comes review time and the house of cards starts to blow away. Unfortunately, your company's HR system is myopically focused on individual results not team results. Suddenly your well-running agile team has turned into a pack of individuals all competing for the best slice of the review pie. Out goes teamwork and results and in comes "I did" and "I was." 

Enter Agile Team Reviews. I first learned about this from Chris Sims of Agile Learning Labs. Working with a mid-size client, he rolled out a companywide agile review system. Each review was split into two equal sections. First was the team review. Each agile team was reviewed as a group and rated as a group. Everyone on the team got the exact same score. The second half of the review was focused on the individual and specific goals set with their manager ahead of time. These goals are always focused on the individual and their growth, such as "learn Selenium," "become a six sigma black belt,” and "improve public speaking skills by..." 

Three years after implementing the system, the company was still using the model. Acceptance was near universal and morale around review time was excellent. Most importantly, the teams kept being teams.

You can do this with your team, today. You don't need your whole company to change its process. Instead, work with your team and conduct the review as outlined above. Then translate the results so they fit into your company's HR system. When your people are outperforming everyone else, it will be noticed in a good way.

Welcome to the world of being an agile manager, in which your team is a top performer, doing more, and in the same amount of time as before. Team morale is high and its outlook good. This is a world that you, the manager, helped build and make happen. Instead of building the best process or the best code, you are building better people, and that makes for better teams.

Better teams make for better projects. Better projects make for better products, which make better businesses. And better businesses make for a better world. 

Additional Resources: Being QA in An Agile World
The role of QA in agile is an important one. Along with product owner, QA staff are one of the best voices of the customer. StickyMinds has stored up years of advice for how to do or be QA in an agile environment. 

What is your favorite trick for agile adoption or "QA Agile" article on StickyMinds?  Leave a comment and recommend it to other readers.