Pittsburgh Technology Council TechVibe Radio

Rivers Agile Founder and CEO, Ben Wilson, and Director of Quality Assurance Services, Keith Monahan sat down with TechVibe host, Jonathan Kersting, and Pittsburgh Technology Council President and CEO, Audrey Russo. Below is a transcript of the Rivers Agile portion of the interview, which begins at 31:05. To listen to or download the full interview (including Deloitte and LendingHome), click here.

Jonathan: There’s nothing better than breakin’ in the ‘ole podcast room for TechVibe radio. What do you think Audrey?
Audrey: Oooh, I’m so happy to be here!
Jonathan: Yeah!
Audrey: And I love our guests here, old friends of ours, watching them blossom.
Jonathan: I know, man. Like, so Audrey, they’ve been on the show a few times before. And every time, they get a little bigger, a little better.
Audrey: I know.
Jonathan: And they they always have new stuff to announce.
Audrey: They’re growing up, they’re like in their teenage years.
Jonathan: I know.
Ben: It’s very exciting.
Keith: It sure is.
Audrey: You might be post-teenage.
Ben: We’re just getting out of that awkward stage, you know. Yeah.
Keith: Right.
Jonathan: Exactly. So, we have Ben Wilson and Keith Monahan from Rivers Agile. Hanging out with us here in the TechVibe podcast studios.
Keith: Hi guys!
Keith: Yeah, thanks for having us.
Ben: Great to be here.
Jonathan: So, this space gives us flexibility. In case we don’t make it to the studio on time, we can always zip back over here if we need to. Right? You know.
Ben: Hypothetically, sure.
Jonathan: Hypothetically, these things can happen. And so, our backs are always covered.
Audrey: Well, the thing is with these guys, I like turn my back and the next thing you know Ben’s doing something different, and better, and additive.
Ben: Well, I really, you know, take the time to make sure that the company is always growing. How can we constantly be improving the company? And the truth is, as a small company it does morph into something bigger and better. There’s always things to work on, and so that’s a constant focus for me.
Audrey: I can relate. And so, what are you up to? What do you want to talk about today? Cause you’ve got?
Ben: Well, there’s a few things.
Audrey: Focus on a few things.
Jonathan: When you’re growing as fast as you are, and having like, you said, 36 people.
Ben: I know, can you believe it?
Jonathan: You’re doing something right. I know. You’re solving problems.
Keith: Absolutely.
Ben: It has to be twice as many as last time we were here, I think this is our fourth time.
Jonathan: And this is the first time we’ve had Keith on the show as well, too.
Keith/B: That’s right!
Jonathan: It’s always been the Ben Wilson show. But now, it’s the Keith show.
Ben: And it’s not the Ben Wilson show, right?
Audrey: That’s great!
Keith: Well, that’s what happens to great leaders, right? They learn to delegate and they learn to find trustworthy people.
Ben: Absolutely.
Keith: That they feel comfortable with, right?
Jonathan: And so, Keith, you lead up the all the QA, the Quality Assurance.
Keith: Yup.
Jonathan: And that’s really been the secret sauce for Rivers Agile, so?
Keith: That’s right! And it’s a big responsibility. Right? And so, the company was really founded in the principles of good QA, good solid QA. Right? And so even, you know, before we started developing software, custom web and mobile solutions, right, we started with a focus on QA, and so I’m very proud to sort of lead that division of QA.
Jonathan: Definitely.
Keith: And expand some of the service offerings that we bring.
Jonathan: Within QA, and just tell our listeners real quick what QA is. It’s when you go through and find bugs in code.
Keith: Yeah.
Jonathan: You make sure it works, it’s got quality to it, right?
Keith: Well, that’s right. Yeah, and so the idea, right is. You know, so Software Quality Assurance, right, which is sort of the official name, SQA, is what we do. And essentially, we look at software and we try to break it. Right? And so well, you have developers that are essentially assembling and building something, there’s gotta be somebody to test it. And the idea is is that we have trained QA engineers that are finding these bugs so the users don’t find them.
Audrey: Right.
Keith: And so, whether you’re dealing with internal users or your external end users. You want that product to be the best possible software that it can be.
Audrey: So, when you think of QA like I do, I think of it as like a continuous process and then it’s like a closed loop, you come back and keep testing it and keep testing it and etc.
Keith: That’s right.
Audrey: What do you? So, should I be thinking about you if you’ve not done the work for me in terms of design, but I bring you in and I want you to do some testing?
Ben: Well, you know that’s pretty interesting. In some ways, that’s a strategic advantage, right? Because we have no bias coming in. We are only doing the facts.
Audrey: Right, right.
Ben: We know what it should do, we know how it was described and defined. And we know what the expected outcomes are. So, in a lot of ways, it actually is a strategic advantage for maybe a CIO to bring us in, having NOT done the development.
Audrey: Right, Uh huh, right.
Keith: Right. And so, really, what we’re talking about is independent, objective view of the state of the software. Right? And So, if you really want to know, is this software ready to launch? That’s something we can help you do.
Audrey: Right.
Keith: We can take look at it. We can identify what the gaps are. We can say, “Hey, you got these priority one or these priority two bugs. And this list of bugs, you should fix before you’re ready to launch this.”
Jonathan: But doesn’t my automation stuff just fix all of that automatically so that I don’t have to worry about it?
Audrey: Nooooo.
Jonathan: I mean, come on, I spent a lot of money on this.
Ben: It’s a silver bullet.
Audrey: Lalalala.
Jonathan: Come on.
Keith: Hahaha.
Audrey: So, that’s fascinating, right? So, that’s a key opportunity and you’ve been able to build upon your strengths in development there.
Are there some common themes that you have discovered?
Ben: Well, there are. And you know, we’ve been at this for ten years. And certainly, we’ve…
Audrey: No!
Ben: Yes! Can you believe it? We had our 10 year anniversary last August. And it was amazing.
Audrey: I remember when you were a baby.
Ben: I know.
Keith: Hahaha.
Jonathan: He’s all growed up.
Keith: Yup.
Ben: You know over the years, you know we’ve worked with a number of clients. And we’ve certainly, you know, built our skill set even more so than when we started. And so we actually created a new service offering called a QA Assessment. We go into existing QA departments and help them sort of unpack the day to day and where things might be missing and it’s based on a number of key principles that we’ve defined over the years and they’re sort of standard best practices.
Keith: Right. And so, essentially what we do is we go in in the QA Assessment. And a lot of times, first off, just to back track. When customers sort of reach out to us, they reach out to us for our QA expertise. That’s what we’re known for, right? And so they say, “Hey, I’ve got a QA problem.” Well, a lot of times, they don’t have a QA problem.
Audrey: Right.
Keith: What they have is actually a Software Development problem.
Audrey: Oh, wow.
Keith: Right? Now, not in terms of, you know, in terms of the whole lifecycle, the whole SDLC as we say, right? And so, there’s sort of potentially process problems. And so, and because QA is sort of just one phase of that whole SDLC, we take a look at the whole process.
Audrey: Huh.
Keith: It’s a more holistic approach. And that’s sort of the difference between quality assurance and testing, right? Testing is just one phase of quality assurance.
Audrey: Right, right.
Keith: But we’re going to actually look at your whole process. So, that means we’re going to look like at things like your requirements collection. How do you collect your requirements? Do you collect requirements? Do you actually write them down, right? We look at things like, you know, how are you planning your tests? What’s your strategy for testing? And so forth. And so, we sort of look at 5 or 6 different categories of potential problems. And we fill out essentially a checklist and what we’re trying to determine is sort of your technical maturity. So, there’s this capability maturity model.
Audrey: Oh, right.
Keith: CMMI, right?
Audrey: Uh, huh.
Keith: And so, we try to do is, we try to figure out where do customers sort of fall on the big scale. You know, are they sort of still early, or they still have a lot to learn or are they far along? Because depending on where they fall on that maturity scale, changes what areas we might focus on later. And so…
Audrey: So, you’re actually using that Maturity model embedded into your QA practices?
Keith: We do. Sure.
Audrey: That’s cool.
Keith: Yeah, because, you know, a lot of times, right, we might have for instance customers ask us about things like, you know, key indicators, key performance indicators, KPIs – when they’re really not, they don’t even have a good solid process done yet. And so, we don’t really want to focus on sort of statistics, and trying to sort of analyze it from like a numerical perspective, but sort of look at a process.
Audrey: So, people who are listening, is there any kind, they might be wondering, is there any kind of technology that is your sweet spot? Or? Or not?
Keith: Well, here’s the thing. I think QA can be applied to a variety of different environments.
Audrey: Okay.
Keith: And so, you’re talking about the specific tech stack for instance, right?
Audrey: Exactly.
Keith: And so, if are we talking about .NET, or we talk about Java.
Audrey: Right.
Keith: Whatever the case is, not really. The same principles can be applied evenly across those. Now, of course, you know, the company that you hire, you know, like Rivers, for instance.
Audrey: Uh huh.
Keith: You want to make sure that they have some experience dealing with your stack.
Audrey: Exactly.
Keith: Right? Because there may be some specifics. But generally speaking, no, the process can be applied evenly across.
Audrey: So, what kind of experience do you have?
Keith: So, for instance, experience in testing desktop applications.
Audrey: Uh huh.
Keith: Testing web applications, and are these you know Angular front-end applications? Do they use Ruby on Rails on the back end? You know, what’s the make up?
Jonathan: So, just reminding our listeners, we are talking to Rivers Agile, here. Is it RiversAgile.com?
Ben/Keith: It is!
Jonathan: Can they check it out there?
Audrey: Who have just passed their decade birthday!
Jonathan: I know! Very awesome I’m sure.
Audrey: Which we’re very proud of.
Jonathan: Super cool stuff.
Audrey: Very proud of. And so, we can just jump for a little bit and talk about, I know you’re growing, right? So, I mean that’s true. But talk about you’re gonna be an exhibitor. You’re really getting out there and talking to the world.
Ben: Yeah, so this is a big change for us. So, the reality of it is, about 75% of what we do today for our clients is within the healthcare industry. Right? And so, as that has come to be, it makes sense for us to be an exhibitor at HIMSS. So, this is our first year at HIMSS We’re very excited about it. We already have some potential clients reaching out to us just based on the fact that we’re coming. So, I look forward to it.
Audrey: You’re like rock stars!
Ben: Oh, sure, of course. Hahaha!
Audrey: You’re like rock stars, I love that!
Jonathan: Yeah, that’s fantastic.
Audrey: You’re also putting yourself out there in terms of thought leadership in QA.
Keith: We are. Right? And so, we’re involved with The Pittsburgh QA meetup.
Audrey: I know.
Keith: That’s run over at Code and Supply, right? By Tara and Stephen.
Audrey: That’s great.
Keith: And we’ve worked with them in the past. And we really enjoy just having a place where we can collaborate. Having a place where we can learn new things.
Jonathan: Definitely.
Keith: Both share technologies and share our experiences and then also learn. And so, I’ll be presenting there on February 13th.
Audrey: But you’re going to be talking about the myth of automation in QA?
Keith: That’s right.
Audrey: I mean, can’t you really automate QA?
Jonathan: I think you should just automate the whole thing. Set it, forget it.
Ben: It’s a common mistake. And you know.
Keith: Sure.
Ben: And it’s really easy to get excited about it.
Audrey: I can’t just run my…?
Ben: Well, there’s a point in time where it’s actually not a good idea, right? You know, if you start off with automation when a project is pretty new, you’re going to spend a lot of your time and money babysitting those test cases.
Audrey: Right.
Ben: When in reality all you needed to get that MVP out or next phase out is some GOOD manual testing.
Keith: That’s right and so, I mean with automation, a lot of times what happens is the normal functional testing that manual QA engineers normally perform, a lot of times management seeks ways of trying to speed up that testing, right? Because…
Jonathan: Do it faster, it has to get to market.
Audrey: It’s already done. Come on!
Keith: That’s right, because it falls on a critical path in the total solution.
Jonathan: Exactly.
Keith: And so, they’re always trying to speed about that up and I appreciate that, but functional testing, at least initial first-round, where you’re actually trying to find bugs, there’s simply no replacement for having humans. And so, we sort of advocate having sort of manual testers in that part, and then after this has already been tested, after that functionality has sort of become a little bit more concrete, then we start employing automation strategies to do automated regression testing that then speeds up detection of regressions that might happen due to code that would be introduced later.
Jonathan: This is, yeah.
Keith: And so, we advocate for a mix of both manual and automated.
Jonathan: And this is why you’re growing at a fast clip because you are solving some tough problems. Keeping people on track. Keeping their software running the way it should, cause you’re getting all the bugs out of it!
Keith: That’s right.
Jonathan: For crying out loud. And once again, RiversAgile.com. Ben and Keith.
Audrey: So great to see you guys.
Ben: Thanks for having us.
Jonathan: So glad to be hanging out with you guys.
Keith: We really appreciate to be here.
Jonathan: Yeah, I’m just so tickled.
Keith: We really appreciate your audience.
Jonathan: 10 years, growing like crazy. Solving tough problems. Can’t say anymore than that. Great, great stuff. Hey. Another TechVibe Radio under the belt here, Audrey.
Audrey: It’s great. I’m proud of them.
Jonathan: It’s fun to do this. I know. This is why we get pumped up.
Audrey: I know.
Jonathan: Because we get to hang out with Ben and Keith and stuff, like that.
Keith: Fantastic, happy to be here.
Jonathan: We’ve got more stories just like Rivers Agile, every single Friday on TechVibe Radio. Keep tuning in every Friday at 7 o’clock. In the meantime, go to pghtech.org and find out all the ways we like helping tech companies succeed. This is Jonathan Kersting.
Audrey: And this is Audrey Russo.
Jonathan: Have a great weekend, everybody.