Navigating Your Agile Testing Transition: An Interview with Mary Thorn

Mary Thorn will be presenting a presentation titled "Seven Keys to Navigating Your Agile Testing Transition" at STAREAST 2014, which will take place May 4–9, 2014.

About "Seven Keys to Navigating Your Agile Testing Transition": 

So you’ve “gone agile” and have been relatively successful for a year or so. But how do you know how well you’re really doing? And how do you continuously improve your practices? When things get rocky, how do you handle the challenges without reverting to old habits? You realize that the path to high-performance agile testing isn’t easy or quick. It also helps to have a guide. So consider this workshop your guide to ongoing, improved, and sustained high-performance. Join Bob Galen and Mary Thorn as they share lessons from their most successful agile testing transitions. Explore actual team case studies for building team skills, embracing agile requirements, fostering customer interaction, building agile automation, driving business value, and testing at-scale—all building agile testing excellence. Examine the mistakes, adjustments, and the successes, and learn how to react to real-world contexts. Leave with a better view of your team’s strengths, weaknesses, and where you need to focus to improve.

Cameron Philipp-Edmonds: Today we have Mary Thorn, and she will be speaking at STAREAST 2014, May 4 through May 9. She's presenting a presentation called "Seven Keys to Navigating Your Agile Testing Transition" with Bob Galen. Mary Thorn is a director of quality assurance at ChannelAdvisor in Morrisville, North Carolina. She has a broad testing background that spends automation, data warehouses, and web-based systems in a wide variety of technologies and testing techniques. During her more than fifteen years of experience in health care, HR, agriculture, and SaaS-based products, Mary has held manager and contributor-level positions in software development organizations. She has a strong interest in agile testing methodologies and direct experience leading agile teams through Scrum adoption and beyond. Did we catch everything?

Mary Thorn: Something like that, yeah.

Cameron: Is there anything to add?

Mary: Nope, no. It's kind of crazy when you sit there and view your resume for the past seventeen years, so, yeah. It's good.

Cameron: It's an impressive resume. Since you are doing a session titled "Seven Keys to Navigating Your Agile Testing Transition," I'd like to ask you a couple of questions about that and about adopting and staying with the decision to go agile. The first question is, If a company hasn't transitioned to agile yet, why should they consider doing so?

Mary: You know the market's moving fast in many industries right now, and so with that said, the traditional way of doing waterfall projects, where you have all the gates and all the steps and all the paperwork that you have to do to get through all these gates, makes it really difficult to keep up with competitors. Agile has been one of the key needs of development process changes over the past few years that allow you to keep up with the next greatest product. Competition is fierce right now in the industry in a lot of different levels, and a lot of people are taking people's existing ideas and then just taking that to the next level. So if you're one of the early adopters who did a great product, like I said with ChannelAdvisor, now we have a lot of people coming in and automatically doing what we're doing. You've got to keep up with them, and in the traditional waterfall world, if we were circling through all those gates, we wouldn't make it. Agile is really allowing us to speed up the process and get things out to market along with all of our competitors.

Cameron: Why do many companies and people on teams try to revert to their old ways when they're kind of in that agile transition?

Mary: People don't like change. I mean, at the end of the day it's fundamental that within waterfall you have all your requirements, you have all your gates, and you know exactly who is accountable for what, right? Because you have these definitive steps. And when you're in agile, some of those gates and some of those steps kind of just disappear, and it comes a lot down to transparency and getting things to people in a different way. Requirements might not be fully fleshed out—testing might start in development, which we would have never done earlier on. So when you get people out of their comfort zone, a lot of times people don't see the value or don't want to see the value because they don't want to change. That's one of the biggest things I've seen as a resistance to change.

Cameron: Is there a specific aspect of the agile transition that is really pretty difficult or proves to be hard to change for most companies and most teams?

Mary: I think one of the major things—and people are starting to see that a lot around the industry right now—is scaling of agile. A lot of teams will start with that pilot one team, right? And that one team does pretty good. They're pretty productive and you can see them starting to take off. And then when you start to come out to do the second or third teams, or some companies will say, "Everybody stop—we're going all agile," and you have fifteen to twenty Scrum teams, that's a big difference in problems. Where I'm seeing a lot of the hard agile adoptions is getting past that first six months piloting and starting to roll out the scaling of agile. And I think a lot of things in the Scrum and agile community right now is the scaling agile framework, or "How are we going to get the planning for all these ten teams every two weeks or every three weeks or every four weeks done?" I mean, we have that problem where we're at where we just doubled our Scrum teams, and while five teams was easy, now ten teams is more difficult to plan for. We have a really fast changing market that we have to keep up with, with Google, Amazon, and eBay constantly changing APIs on us, and to be able to know how to do just-in-time planning between Scrum teams is difficult. That's one of the biggest challenges I have seen from an adoption perspective, is how do you get enough work to the people in a timely manner that's the right work to do?

Cameron: The title of your presentation is "Seven Keys to Navigating Your Agile Testing Transition," and I had spoken with Bob Galen a couple months ago. He's at STARCANADA now, and he actually mentioned that there are more than seven keys currently. But could you just briefly elaborate and kind of go over one of those keys?

Mary: Yeah, I mean, Bob started this presentation out when we left iContact. He started with seven and ended up with fourteen, I think. I think there's a lot of myths—you kind of go with the whole myth/fact about the transition. The biggest thing is, I think for me, around automations. Bob and I are looking at doing some stuff around kind of defining the agile testing framework. The biggest myth is that everything has to be automated from day one. It's not that it does, but what we talk about with the transition is you have to have a plan, and you have to have a road map, and you have to have an understanding of where you want to get to and doggedly work at that transition and that automation, whether it's for building the framework or figuring out what stores that you want to automate first and then getting people trained, whatever it is; coming up with a nice technical depth backlog around automation and then just start tackling it. A lot of times people are afraid to even go there. Their QA skill sets aren't where they need to be, or whatever, but at the end of the day you definitely have to have automation to go fast, and it's not an easy thing to do, but it's paramount to get where you want to be.

Cameron: The tutorial also says that after attending, delegates will have a better view of their team's strengths, weaknesses, and areas for improvement. What are some common strengths and weaknesses that are often misdiagnosed or overlooked?

Mary: What's interesting is when you transition from waterfall testing to agile testing, people often think the actual craft of software testing kind of goes out the door—that you don't need your standards and your templates, that you don't need your test plans anymore or you don't need to write test cases. It's like the whole lean, no-documentation thing. Well, that's actually a very big strength of the core QA that you are bringing along from waterfall to agile, and so the myth of "I'm going to go from documenting everything to documenting nothing" is really not true. You need to take the strengths of the QA that you have, which is the fundamental craft of the QA, and basically use those but in a lighter form. So I still have a QA standard operations procedure document in agile, but that is for "Hey, Mr. New Guy that just came in off the street, here is how you do your job, day one." Some people are like, "Wow, that's a big document. That's a waterfall document." Well, yeah, it is, but at the same point in time there's still got to be consistencies across QA on ten different Scrum teams, and that defines what the businesses of things are. Standards are very important in consistency.

A lot of times what's happening from a testing perspective and agile is it's always matrix, right? Some teams will have a QA—according to development—I feel like the people that care more about quality have people reporting to a matrix, a QA manager, or director, like I am, because of the craft of QA. I very much say we still have to do test cases. My minimum two standards are you still have to write test cases in agile, and you still have to write some type of a test plan. It doesn't have to be a big, forty-page dialogue you did in waterfall, but give me an Excel spreadsheet of the things and all the stores that you're going to test and ideas of how you're going to test it. So, you're still thinking about the plan of how you get all this work done. To promote straight myth and straight perspective: We still have the craft of QA; we still have the things from a software testing perspective that we didn't in waterfall that we still need to do going forward.

The weaknesses side is obviously a lot around the automation. While other QA engineers in the past decided they didn't want to be developers and that's why they went into testing, we have to upscale our QA engineers to have them be more technical. And there's a lot of tools coming out, from tools like SpecFlow and Cucumber, that will help the QA members on the team gradually move into the automation arena. At least have this happen in the test cases and then have somebody automate it, but once you get some of that framework in the learnings understood, then the actual automation cases, if they're somewhat willing, it's easy for them to learn. But you have to upscale; you have to take the time to train your QA people to get them to want to learn the automation piece of it. There will always be those QA that say, "Heck, no! I'm not going to automate," and that's OK. If they are subject matter experts, it's their main expertise—you still need those people to permit exploratory perspective. Exploratory testing doesn't go out; it's just a nice complement for the technical. We still have to have some of the team upscale to be more technical.

Cameron: So you talked about test automation there, but you also have a strong interest in agile testing methodologies. What about agile in particular is so appealing to you?

Mary: In waterfall days, QA was responsible for, Is it a process problem or is it a test problem? So do we dismiss it from a testing perspective, or is there a cross where the requirement's bad? To me, my job is in the same lens. So, is it an agile process problem, or is it a not-testing-the-right-thing problem? For me, I realized early on when I took my ScrumMaster's and I got into this—Scrum came out and I thought, "Oh, heck, there goes all the middle managers. Everybody is going to be self-empowered, self-organized as teams; my job's going away." And so I went and got my ScrumMaster's search and certification and thought, "This is great. I actually enjoy this. I actually enjoy ScrumMastering. This could be a second profession." But then I realized that people still have to do performance reviews. But then I started to more passionately learn the agile, Scrum, kanban, SP practices because I realized that this will help me figure out, Does my QA team have a process problem or do they have a test problem? Learning both sides has allowed me to build stronger agile teams. Most of the time I'm teaching this around agile coaching. When I was at Deutsche Bank I was major QA manager over at sixteen on six Scrum teams, and it was almost all process issues there, and that was the lens that they allowed me to have. That's the lens that I feel like here from an agile perspective, as well as at ChannelAdvisor, where, Did I come into a place that has process problems or quality problems? That's why I've gotten passionate about it—it helps me do my job better.

Cameron: What advice would you give to new adopters of Scrum and agile?

Mary: You know, it's a team sport. That's another reason I got into agile. I played college basketball, and I loved working in teams. It's a team sport, so if you have a bunch of track runners as your employees, then you might want to think about this before you do it, because you need a team of football players, or basketball players, or people that want to work on teams. There are some people that kind of really just don't want to work on teams. So, you have to have people that have a good attitude, good aptitude, and can communicate well, and want to build a good team and want to work on that team. That's always my advice: When you cut over to this transition, you want to make sure you have the personnel to do it, and if you don't, you have to be OK with people voting that person off the island, is what I say. You know, one bad egg will kill a Scrum team, and so you have to figure out a way to get the right attitudes, the aptitudes, the people that have the right communication—people that want to work together on those teams.

Cameron: You have a teammate in presenting your presentation in Bob Galen. What's it like working with Bob?

Mary: Bob's amazing. He is an awesome mentor. He's wanted to do this. He's constantly pushing me to make myself better, and he's just got a lot of great experience in this business. I really hope people will come out and listen—listen to what Bob has to say and read some of the books that he's written, which are also very enlightening. Think about what the message is that he's trying to give out, because at the end of the day he talks a lot about culture and making things, empowering people and being a servant leader, and that's kind of the person he is. That's the way he managed me when I worked with him at iContact, and he's just overall a great communicator, too, so you can actually understand what he's trying to convey. I really ask people to come and listen because he's really a great communicator about agile testing and agile in general.

Cameron: Now, is there anything else you'd like to say to the attendees of STAREAST before they attend the conference and before they attend your presentation?

Mary: Just come with an open mind. I think a lot of people come to these things with some preconceived notions of things, so come with an open mind and listen to what you have to hear. Challenge us. I mean, my favorite thing is when people go to conferences and say, "What you said won't work and here's why," and I'm like, "Yeah, I can see your opinion." It also helps me and us get better. Come with an open mind—please collaborate with us. Don't be the guy in the back of the classroom that doesn't say anything, and you'll get a lot better of an experience out of it.

Cameron: And like you said, "It only takes one bad egg to ruin the bunch."

Mary: That's right.

Cameron: All right. Once again, this is Mary Thorn. She will be speaking at STAREAST 2014, which is May 4 through May 9. She's speaking a presentation called "Seven Keys to Navigating Your Agile Testing Transition." Thank you so much, Mary.

Mary: Thanks, Cameron. Bye.

Mary Thorn is a director of QA at ChannelAdvisor in Morrisville, North Carolina. She has a broad testing background that spans automation, data warehouses, and web-based systems in a wide variety of technologies and testing techniques. During her more than fifteen years of experience in health care, HR, agriculture, and SaaS-based products, Mary has held manager and contributor-level positions in software development organizations. She has a strong interest in agile testing methodologies and direct experience leading agile teams through Scrum adoption and beyond.