#007 – Augmenting the Agile Team: A Testing Success Story with Mike Hrycyk

Ardent Development Podcast

Mike Hrycyk has been trapped in the world of quality since he first did user acceptance testing 19 years ago. He believes in creating a culture of quality throughout software production and tries hard to create teams that hold this ideal and advocate it to the rest of their workmates. He has worked many roles, but always returning to testing. Mike is currently the Director of Quality for PQA Testing.
In this episode, Derek and Ron chat with Mike Hrycyk about his experience using a regression testing team to augment feature teams, handling the testing regression cycle while the feature teams (developers and testers) do new development. He makes a compelling case and his story of success is well worth the listen.

Where to find Mike Hrycyk

@qaisdoes on Twitter

On the web at qaisdoes.com

Enjoy the show and be sure to follow Ardent Development on Twitter.

Follow @ardentdev

Transcript

Ron: We are joined today with Mike Hrycyk who has been trapped in the world of quality since he first hit his user acceptance testing 19 years ago. He has survived all the different levels, and a wide spectrum of technologies and environments to become the quality dynamo that he is today. Mike believes in creating a culture of quality through software production and tries hard to create teams that hold this ideal and advocate it to the rest of their workmates. Mike’s currently the director of quality for PQA Testing but has previously worked in social media management, parking, manufacturing Web photo retail music delivery kiosks and railroad. So welcome to the show, Mike

Mike: Thank you. Glad to be here.

Derek: It’s good to have you Mike.

Ron: Glad to have you. Now you just finished up at a conference. We thought we’d have you on to talk a little bit about your first talk that you gave there are. Augmenting the gentle team, a testing success story. Could you give us started on that topic, Mike.

Mike: Well sure, for sure. So Agile for me is a bit of a passion, I think. I really believe in the power of Agile. But one of the things that I’ve learned in working with people who do Agile is that when when people self teach or when they have bad coaches people seem to believe that there’s a right way to do Agile, that there’s one way to do Agile and they go out and they find a how to guide for how to do Agile and it teaches you how to implement it. But the problem with that is that every situation is incredibly different and that Agile isn’t really set up to be a how to guide it’s set up. It has a manifesto, it’s a set of concepts and it’s something that everyone who adopts it has to figure out how to do it right. And so I had a project that we did with one of our clients so, we’re testing as a service company. And we got involved with one of our clients where we did an assessment and helped them figure out what they needed to to be successful and some of the work they were doing. And one of the things that that we were looking at with them was is what they’re doing, is it doing Agile wrong, is it doing it right? And I have this personal mission to make sure that no one believes that you’re doing Agile wrong as a term that you can hear. I’m not sure if you guys are familiar with the concept but when I hear that it just makes me angry because Agile is an iterative approach to everything and it’s the way that there’s no way that it needs to be done. You’re doing it right, if it’s working for you. And so this talk that I put together is sort of a case study from a project where we did take and went way off the standard realm of Agile and did it our own way. And I wanted I talk about how we did it what the problems were and what the success was to help people see that doing Agile your own way is probably the best path to success. That makes sense?

Ron: Absolutely. It’s an interesting topic because as you go from company to company and do different assignments there you see Agile implemented in different ways. And I think if you talk to the folks that are involved in projects they would actually give you a slightly different slant which I think is aspirates this topic of are we doing it right. Because I.T. is often, you know years ago, there’s a right and wrong way if you will, right there seems. But this seems somewhat fluid. I think people are having a hard time knowing you know are we doing well or are we doing it right?

Mike: Well and for someone who grew up in Waterfall who’s spent years having lists of things that you need to do to do things properly Agile so different from that. And I think that’s one of the reasons that some people and I hesitate to call people old timers but if that’s your mindset maybe that’s the right way to say it. You get stuck in that mindset and Agile has too much change, it’s just too fluid and it’s difficult for you to go into that new world where you might have to be able to shift every two weeks, you might have to be able to shift the way you’re doing things because you’re supposed to be iterating to make things better.

Mike: So the clients I won’t name names but the client is a Canadian client that produces a retail management solution or an RMS for mobile phone kiosks. So when you go into a mobile phone place in a mall or wherever you go and you buy a phone and probably not the ones that are actually branded Fido or Bell or whatever, probably one of the other ones although they sell to the carriers as well. But when you go into one of those and you buy a phone, one of the things that they need to do is they not only have to track the purchase of the phone. They also have to set up provisioning for the phone so that when you walk out of that kiosk that you have a phone that is connected to the carrier and that does what it needs to do. So they produce software that takes care of that, takes care of the selling and takes care of that. And they’ve also extended it and tried to make it an option that will sell and take care of all of the needs of that client. So it also takes care of employment stuff, it takes care of inventory, it takes care of reporting and tries to take care of all things. And really what end that ends up being is it ends up being a very very complex system so anyone who’s worked in an ERP knows that that it’s like an octopus only not eight arms, like a million arms that that thread through all different things. And so there’s a lot of integration points for that. And then. So they were having some problems with one of their end clients which is what I term one of our clients who is working with someone else down the line. We call that the end client sort of like end user and when they work with an end client that end client was a name of one of the major carriers in the U.S. and they did 40 percent of the business for my client. So what they did is they had a lot of clout in conversations about features and things and that end client had 15 other vendors delivering solutions that all built together into integrated system that made them successful.

Ron: So it’s an octopus of octopuses.

Mike: Yeah yeah every aka arm had other octopuses living off in this kind of mutated. What that meant though was that that the SIT testing,the integrated testing environment system integration environment was very necessary and complex because you couldn’t test on your own box you can’t test for what’s going...