Welcome to What's Your (R)angle? A podcast by Rangle that explores thoughts, ideas and perspectives on the digital transformation space. Each episode we'll provide you with some key considerations for mapping your digital first strategy, and our Rangle on how we look at challenges presented. Join the conversation by using the hashtag #AskRangle on Twitter, or by emailing us at podcast@rangle.io.

Hello everybody and welcome back to What's Your (R)angle? I'm your host, Jennifer Shannon, and we have a podcast talking about all of the things that go into an innovation framework. This season on the podcast we're really digging into what some of those pillars are. Today I'm really excited to be talking about lean, agile and quality, and the role that that plays in the projects that you're building as part of your innovation or transformation projects.

Could not think of two better people to join me today than Payal Vermani and Myron Parks. Welcome folks.

It was a rough start because we didn't have consultants with us embedded, so that's not the right way to do it, in hindsight. What it did do is it just pushed me right into things to realize, okay now how do I adapt the way we work on my team, and how do we continue to deliver what we've been delivering? That was how I sort of got started. Did a few consulting gigs. Traveled around, basically lived out of my suitcase, consulting for a good three and a half, four years that I was in the US.

Because at the end goal of a successful engagement for every client is I want to replicate this. I want to bottle this special sauce and spread it in my organization. If you're not able to strategically align yourself at that level, you're not giving them more to keep you in for longer. Then they want to take you everywhere. All right, let's introduce you to this department, let's introduce you to this department. To me, crucial conversations is what it comes down to, followed by full understanding and empathy. Don't be shy to learn from them either.

Been certified in a number of agile methodologies. Scrum, safe, yellow belts, Lean Six Sigma, and a number of things that help to enable service delivery, or utilize quality for service delivery. That's one of the things that I see as typically left out of that picture.

Like I said before, I started in the Navy, and I was actually in Southern California. When I was done with the Navy I moved back to the Midwest, and people asked me similar questions, "Well, why would you come back to the snow?" I was kind of like, well there's just something about a culture that makes sense to you at the time.

Throughout my career I've worked on lots of waterfall projects for financial services primarily, and I got my first chance to work in an agile setting for a startup. They were doing migrations from, what was it?

Eventually though you find yourself in a place where to get an approval, or rather a conversation to happen with a person that sits just down the cube from you, there's a chain in place. You have to go through how many pieces of paper or forms to get something approved. That's what drives frustration, and sort of like that feeling of being handcuffed. Where I know what's the right approach moving forward, all I need to do is get this done, how many people am I going to have to meet with, justify and get their sign offs on?

I'm going to really water it down to say all that means is we do, I don't want to say the word bare minimum, but it is just that. Think innovative, think quick delivery, think saving money. Things like, how quickly can I get this product in the hands of my consumer? Be the first to market, have them touch it, have them feel it, have them realize the value it brings. What's the quickest way there?

Now if you build on top of what we've just talked about, the MVP, taking those feedback directly from the customers, bring it back into the loop, and then continuing to work on it, and work on it, and push versions out, and versions out, and versions out. That's what we refer to as the iterative and incremental approach to delivery. That's where you hear agile from people.

From sort of like an agile quality, how do you insert agile quality into that scrum process, or seed process, or whatever it is that you're using? I think it starts with identifying the minimum viable product first, and then identifying, what is the minimum set of problems that you have to solve in order to launch that to production? Working with the team, and the product, and the client, to actually deliver or realize value in the market.

Once, as agile practitioners within the lean agile space, once we realize that that is what we're actually doing, then the job becomes significantly simpler. We can take, with this approach, a library of 10,000 tests and bring that down to 100 tests. We can take that library of 100 tests down to 10 that we should assist and contribute to automating, to doing an automated regression so that the next time it's only 90 tests that we have to do. These are the types of things that we can do to enable that team to launch.

Because the development team, so there's one aspect that you talked about Jen, and that is making sure this thing works. That's what we do every single day as a part of either a lean team or anything else, a lean agile team or anything else that we're doing. The other part that we have to pay attention to is, what do we need to make sure works in order to actually launch this piece? When we look at it from a system perspective, we tend to get into those situations where, all right, there are 10,000 things that have to work for this whole thing to work, but we're working on this little segment right now. How do we make sure, how do we work with this cross functional team to develop and deliver that not just to the end of the sprint but to production?

If we start working on that, and we start contributing to what I call the end to end delivery pipeline, then that's where we realize the most value applying our agile practices across. Not only during the development, but during the specification phases, as well as that delivery phase up front.

While we do that as a team, with the focus on quality of the product, what we often forget, and it's just when you get used to something and it's your day to day routine, it's bound to happen, is we also need to put that lens on our process. What happens is the team has now gone through the storming, the forming, and now in the norming stages. Now we know how we work together, and we sort of get into this groove. This is where you get like those high functioning, high performing teams going, "Great, is the process still doing what it's supposed to do?"

I can give you very granular examples that have worked out for us in the field, where there have been simple little steps that they sound very simple on paper, and they've made massive improvements. For example, I have some designs, I'm a developer, I have started developing a story. Off it goes to the quality person for testing. Quality person looks at the story, starts to test and goes, "Doesn't look exactly like the design." There's a little back and forth happening there between the developer and the quality person to say, "It doesn't look like the design, but this is the closest I can get it to look like based on the API I'm using."

Overarching sentiment there is that as a scrum master, as a program manager on a project, on a program, you're continually watching for those things. Gathering that empirical data, is what we call it, be it in form of metrics, be it in form of feedback during retrospectives, be it in form of direct feedback from customers. Not only implementing it on the product side of things, but also on the process side of things. That's your key differentiator. We're always looking to improve.

The next thing is, once you've gained that trust, and they're like, "All right, well you're actually a part of that team." Now you get involved in sort of like the discovery phase, and identifying what we're actually trying to accomplish. Like Payal was talking about earlier, get involved earlier with desk checks. Like from a lean agile perspective with quality in mind, that's bringing the decision, or the quality decision, closer to the work that's being done. You're shifting that work forward so that when you find problems there's less rework. Rework typically equals cost. That is the key metric that I look for, looking from a continuous improvement perspective. That's the key metric that I look for to add value as a [crosstalk 00:23:56].

They said, "Okay, we have a number of products that we're developing, and so we have a process for that. But let's develop delivery, everything that we need to do in order to launch a single time. Let's develop that as a product as well, and let's do that in an agile way so that we're making incremental process." The team that's building the features, or doing the feature development, they own that as well, in moving all the way through that process.

When you specify that process, and you add quality in there, I.E., here are the things that have to be done specifically for us to be able to launch it and have a sustainable release that doesn't destroy our company, or harm our reputation, et cetera. You can shorten your cycles down once you have that process defined.

In a waterfall approach, if you take six months to develop the features, and then you start working on that problem at the 10th hour, and no one that built the application or the features, and understands it, is actually available to assist those people, you're not going to have an effective process. Your testing is going to go late. Your application's going to have probably a lot more bugs and whatev than if they had been integrated the entire time. For sure the types of problems that are found are going to cost more. That's just been proven.

I would say those are the reasons that it's important for organizations to adopt an agile quality approach to solve those issues.

Reality is in today's day and age though, if you want to be ahead and continue to own the market share that you own, you've got to keep up. There have been systematic changes to the way we do things that nobody saw coming. Before Uber came around, did anyone think the cab industry would ever get disrupted the way it did?

When we think about that, and we include quality in there, we actually put that into that delivery pipeline, we're building a situation where, let's say you have a house and you install an HVAC system for air conditioning. You install that system and let's say it's a state of the art system, and it works fine, but it's set to 20 degrees. How do you change that to, let's say 22 degrees, or 23 degrees if it's really cold outside? Well you install like a thermometer that's combined with a heat sensor. Now, you want it to be 24 degrees so you change it, and this is your release n+1.

Generally in technology though, I would say in addition to those things, the electrification of transport, what Tesla's doing.