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