251: People Practices in Digital Transformations with Gurushyam Mony

Hit it.

Welcome to the Test Talks podcast, the place to go to geek out on software testing. And now your host whose mission is to help you succeed with test automation, Joe Colantonio.

Hey, it's Joe. And welcome to another episode of test talks. DevOps and agility are only successful if your teams continue to practice them. And every day, every hour and every minute. But how do you get this kind of whole team approach? In this episode, guru Shah Mani shares some of his top practices for helping companies with their digital transformations. A vital aspect of any transformation is not only tools, but also people. So listen up and discover real world tips on how to make your people the key to your company's digital transformation success stories. Guru Shyam Mani is the director of DevOps and Quality Engineering at Merkle and talking about digital transformations, One key aspect that a lot of teams are missing out on is security testing as they're trying to shift with their digital transformation. As they're going through these transformations, a big piece that's often overlooked is security. So if you want to avoid that type of situation, you want to make sure you're developing not only quality software, but also security focused software, make sure to head on over to secureguild.com it's a an online conference dedicated 100% to helping you succeed with security testing. If you haven't already, register now. Head on over to secureguild.com test talks is sponsored by the fantastic folks at Sauce Labs, the Cloud based automated testing platform that eliminates the need to maintain your own selenium grid and test infrastructure. Try it for free today. Visit testtalks.com and click on the sign up now link under the homepage sponsor section.

Hey Guru. Welcome to Test Talks.

Thank you Joe for giving me this opportunity.

Awesome. So today I'd like to talk about Your experience with DevOps and your team's digital transformation story. Before we get into it, can you just tell us a bit more about yourself?

Yeah. So I started my IT journey back in 2006, straight out of my college. I graduated out of University of Florida with a major in computer engineering and software verification and validation.

Joined as a consultant to a federal project that was to modernize and harness the data that comes out of crashes and highway fatalities that happen and mining that data to provide insights to officers and to law enforcement agencies, Department of Transportation and Motor Vehicles in general.

I learned almost all of the modern agility way of practicing software engineering from that team. Had a great opportunity to work with whom I believe is one of the greatest agile coaches at that Point.

I learned a whole lot on incremental software development and continuous testing at that point. Those days continuous testing was not a term that was used. They called it simply by test automation for softwares. That project went on for about seven years and we took the federal agency with a partnership of three state agencies all the way from mainframe system to a completely redesigned web and mobile interfaces with real time crash reporting and data analysis and business intelligence enabled for all of our customers, which was the entire state of Virginia and the federal department. When this project went very well and people were seeing the amount of features coming out in a rapid fashion, they wanted some of our team members to assist with some digital transformation in TMB and another state agency tax.

I was fortunate enough to get on board with tax, which is IRS's federated state agency that manages all the state tax. And we did a larger scale effort at that point, more so peeling me out of my software verification validation journey to a true agile and digital journey. So we focused on a lot on all the way from configuration management practices for software development.

And moving teams along in different trains to help and assist with incremental development and delivery and also put in mechanisms for test automation and enable continuous testing. So about two and a half years in that transformation journey went very well. Where we started to go from once in four months of release to every week release. And we also added a lot of quality checks to our data as well as to the softwares that were developed. And that works to ensure that your tax returns are of good quality. And.

Some way into that journey I heard about an opportunity similar in scale for Markel. So currently I work with Markel Corporation. It's a large financial holding company and an insurance diversified company as well. And I joined one division as a QE director Quality engineering and transformed their quality assurance practices. And.

2017-2018 was a major focus on one division. When that success was.

Pretty well received, they have asked me to lead the DevOps and quality engineering division for Markel across.

All of their business units. So this year I'm starting my journey to handle both DevOps and quality engineering for Markel. I'm pretty excited about it.

So back in the day you first saw when you were dealing with taxes it sounded like an older organization. How did you even get them to do the digital transformation? It seems like in that type of culture it'd be like we've always done it this way, why change?

Yeah, that's a good question. So to me there are two ways to.

Convince or to show the Art of the possibility to people who have done certain practices way. And I believe if the self realization for people doesn't kick in, no matter how much of.

Efforts you put in for marketing and showcasing all these newer practices that can give value, it is going to be tough for people within teams to embrace that and start practicing them. So one way that I have always felt is the best approach to bring people on board to a newer practice or to show the art of the possibility to teams and let them come to a self realization or a conclusion on a better way that they could actually learn is by way of doing it yourself. So what I typically do on large organizations or even multiple teams that are on a train is take a role of a leadership that can show and tell versus letting them know that they should be doing certain things a certain way, which doesn't resonate well with them. To do that as a leader you have to kind of get your hands dirty, so to speak. So for example, they were testing their tax forms manually. Once the software was released to a higher environment, they would open up their interfaces and take the tax throughout their journey of the life cycle in a manual way. I actually took upon myself to sit and give them about two months of coding expertise and showed them how they could simply break these down into small chunks and write software that can actually test the daily stuff that they do. This relieves time off of them and they can start to focus on better things. This also lets them know that there is support within the organization to seek help rather than something that's mandated from top down. So in other words, bottom up approach along with the top down support is always something that will help any organization change at a rapid pace versus if it's only top down or if it's only bottom up approach.

Very cool. So do you find that a common way to get people on board is to start at a lower level where you can. Here's something that's very manual intensive, let me automate it for you. And once they actually see it, then they can stop believing.

Yeah, that's right. Because you found a connection with what someone is doing every day. And you have also shown them the ability to make their daily life much better. And leaving all of the other topics aside, that actually resonates well with the person who does something every day in a certain way. Right. They start to understand the value of a helping hand that is coming and is helping them change the way they do things for the greater good. And once that resonation happens, it becomes a lot less painful. In your journey.

Awesome. So it's almost like a top down approach and a bottom up approach.

So at the same time, right? Yeah.

So what's harder to get buy in from the management or people on sprint teams?

That's a good question as well. I think you have to take two separate approach to convince people at various different management levels.

Making someone's life more efficient, better.

Elevating their talent, elevating how they do things to the next level is always something that would work on your engineering side, your bottom up layers of your teams and all that. But from a top down, if you have to convince and get buy in from the leadership, which I would always say should happen either in parallel or should have already happened before you start your bottom up approach. So what I feel would be the best in getting the top down initiative support is to highlight what are some efficiency gains that they can get and what does that mean from a large organization or an enterprise perspective in terms of the capabilities and in terms of the value that certain practices bring in terms of saving, cost, elevating the quality and being more efficient?

Some highlights would be to collect some of what practices are going on from let's say a manual deploy, a manual test and a manual delivery perspective. You can start to quantify numbers and start to understand how long it takes and how many people are involved in it and put some measures on how much effort that is and highlight that to the management to say if you do it a way, it's this and if it's the other modern way of doing things where it's all automated, it's this efficiency gain along with the quality improvement and predictability. I think that separating out these two different approaches based on who you're dealing with is a key to get buy in at all levels.

Great. So once you have buy in, another thing I see a lot of, and I think we talked about this pre show was the problem that people want everything. They want quality, cost and they want it fast. And I think you mentioned something about a pick two problem. Can you tell us a little bit more what a pick two problem is about? Yeah.

So the eternal predicament of the triangle of cost.

Quality and time. I mean if you have done a large house construction project or any massive undertaking in your real life, you always get yourself in a conundrum of if I want to reduce the cost, my quality of what is going to be put on my house is going to be low. Or I can say I want the top materials in my house which is going to increase the Cost and increase increase the time of.

The project as well. So there are a lot of people who juggle this in an everyday life without even realizing that they do. And it's a fine balance to reach to not be stuck with only two of them. So typically people would go, sure, we want delivery to happen within six months. So they've already put a hard date on time. So then they cannot pick both cost and quality at the same time along with a reduced time one will have to give at the end of the day. So most organizations, enterprises, and even in our daily life, we are stuck with getting only the two of the three aspects that would work well. Finding this balance to keep the three in check is a really hard juggle to do. And enabling this juggle as a technology solution is an even harder thing to do. And then enabling this through a practice level maturity is also another hard thing to continue doing.

And that's the pick two problem that I depicted.

Awesome. So Guru, can you actually give us a quick example from maybe the technology side?

Most people who start on the DevOps journey, they start to say that let's invest in tools because the tools are going to help us go faster, right? So they'll say we have been doing all of this manual testing, manual build, manual deploy. So let's go ahead and invest some money to procure tools. Now, tools also cost money and they cost a lot of maintenance work and efforts and all that. So they end up actually procuring all of this. They end up putting all of this in place, yet to see that the cost just got bloated up. They got more efficiency, they got things automated. However, the cost just went up from what they were doing before, not because of the people cost, but the technology cost. So one has to keep those three in checks all the way from their people as well as from a technology perspective to get a lean way of modernizing your enterprise.

Seems to be a dilemma though, where you want to get people to get into DevOps and create quicker, faster software with quality and you want them to start automating, but almost like they get out of control and they want to automate everything. So and a lot of times it's always we'll just automate at an end to end level, which is the most inefficient way of automation. So how do you further educate them that yes, it's awesome that you want to automate, but let's focus on automation that gives us the best bang for our buck at the right level in the pipeline where it belongs.

Yeah, so that's a great question. I mean, even in terms of your automation itself, there is a where do I start? Do I start from the left or do I start from the right perspective? So most companies.

Inevitably start from the test automation side because their QA group is large or much larger than the development groups. And they also invest a lot on quality assurance as a division. So to your point, they always start to say let's actually go ahead and invest time on test automation so that we can start to become leaner in our budgets. But that's a really microscopic way of just starting in one level on the left. And people start to say we do shift left and let's start to transform the QA department to quality engineering. Let's bring in folks that know how to do automation and have them teach the other QA folks how to do things and whatnot. At the same time, people forget the fact that you should also take the shift right approach parallelly. What I mean by that is you cannot just focus on one large segment of this entire orchestrated delivery. You have to start parallel everywhere. So providing gates at the same time to push the testing to a lower environment is always a big easy win rather than focusing on the higher level testing. And what I mean by that is, as your quality assurance division, manual testers are transforming and going towards automation, the development community also has to put in a lot of checks and balances and practice changes. At the same time, the lower you start to run your automated tests, the cheaper it is, the faster it is. And starting only in one area of this whole segment from a code delivery and deployment perspective is also a bad practice and it leads to failures. To your point of they would have gotten only end to end automation done after about six or seven months of large efforts, yet only find that the fundamental gates of getting a code from when it was checked into the dev environment lacks a lot of practice maturity. So typically teams should first come to an agreement of what their orchestrated pipeline delivery mechanism is and they should lay that out as building blocks and you should focus on all of those boxes in an incremental way rather than going a mile deep on one of the boxes. And what I mean by boxes is let's say if you had build as a box, you have inspect and do quality checks and then you deploy and then you have your unit tests and component tests that are running and then you are deploying to a higher environment like QA and you have your functional tests going. These are your boxes. If you're managing a large enterprise, you should almost be having a good eye towards elevating all these boxes at the same time in their practice maturity.

Awesome. So being someone that's been involved in multiple transformations, were there any areas of automation that you were surprised by how effective they were but not utilized by many people?

Yes. So one example I can think of when it comes to phenomenal automation that exists in a place but it's not fully utilized, is where the enterprises are lacking what is called a cross pollination capability. What I mean by that is you have teams that are enabled in the agile journey to say, hey, you all have the full rights to go ahead and keep automation as priority. So the teams start to work in silos and they start to build all these capabilities and they build it very well, actually. For example, one team that is doing a PDF comparison for quote and bind for an insurance deck has a great solution to actually compare a couple of PDFs within a few milliseconds and they are able to actually automate 55,000 test cases quickly so that people are not manually comparing letters that go out of their software platform. If another team that does similar things, for example vouchers and they want to compare vouchers, if that team does not have an insight into what this other team has done for letters comparison, you lose the whole collaborative and collective approach to elevating enterprises. So you see that a lot when you go in and you see the explosion of tools. So explosion of tools indirectly means that there isn't a lot of cross pollination that is happening between teams in each division or across divisions. One way to solve that would be to start a small central team or have practitioners from each of these teams that are doing very well to come and do brown bags and a monthly meet to share and learn from each other. And secondly, if your tools are consolidated and not allowed to explode, it automatically facilitates the sharing of libraries, sharing of scripts that one team has written that could be used by others. So that's a good question. You have to kind of have an eye towards that as well.

So once again, you've been involved in multiple digital transformations. Is there like a secret sauce to making it happen?

I think there are various secret sauces, but at the end of the day, it depends on your ingredients, so to speak, which is your people. Technology is hardly the problem. In many areas you can swipe a wand and get the technology tools and capabilities provisioned, but if your fundamental people practice have not matured enough, your technology stack is going to exacerbate all of these pitfalls. So to me, the secret if you were to ask for my opinion of a secret sauce, I would probably say it's 0.8 times the people transformation aspect plus 0.1% on the practice transformation aspect along with a 0.1 times the technology capability aspect. That's the equation, is what I would say, because your efforts, it's reflective of the weights and efforts from your people side as well as your technology and practice side. And bringing in the right people, the right amount of people to transform or finding people in your own organization who are enablers. And finding a lean team is always the best.

So for a lean team, do you have any approaches you recommend? Because that's another thing that I think teams struggle with. What's the right mix of their teams in order to give them the ability to be agile or give them the agility that's needed in an enterprise that's going towards more agility.

Sure. So I consulted a little bit with Capital One and I found that they were going by a equation and I'm sure many people would have read this or would have probably practiced this while doing their people transformation. They call this the 2 to 1 or the 3 to 1 or the 4 to 1 ratio between developers and Estets versus developers and a mix of assets with QA folks, all of that.

I feel that while those equations may or may not work for a few people, it's fundamentally lacking the holistic approach of how to transform your entire train. It's actually not the best recipe if you're just focusing on SDEX to developer ratio. You have to also look at is the product owner in that team enabling the team to succeed? Is the scrum master capable enough to understand the journey that's happening and be able to effectively negotiate with the product owner on technology debt stories and technical enhancement stories along with delivery stories. So this kind of transformation spans beyond just developers and and testers and test engineers. It goes also in terms of how we manage these teams. And.

I feel that you have to within your own train. If you have a large amount of teams, the best way is to not get stretched thin. Start with one or two teams and help them get through a particular level of maturity and use that success to slowly trickle and bring the other teams as well on board. You also want to be cautious that the pilot teams that have started are not flying so high to a point where their maturity levels are skyrocketingly different between the others. You lose the value as well. So there is a mix of a lot of practices that you can put in to arrive at what you want to do.

So guru, I'm sure a lot of people hearing this be like, this sounds great, but can I have a specific example of how you did this?

Sure. So in one of the teams in Agile Train here in Markel, we decided that this particular team is managing the front end presentation product portfolio for our customers. So being able to deliver software quickly is key for the customers to know the benefits that we have started to release often and we are releasing stable code often. So we picked that team in the train and we said, hey, we have so many QA testers, let's start to embed some estets. And we started to embed one nested in there. You start to realize that the estate who comes in also has to have the mentality that this is all new. So they have to balance the right way of automation and the right amount of automation each sprint until you get the full support. And if, if you start to holistically change the entire team to say, well, the ratio of three developers to two testers is not working. So I need to bring in all new people of engineers and developers who know how to automate into the team. You are now sacrificing the delivery. It goes against your principles, so you have to juggle the delivery as well while slowly transforming the people in the team. And you have to learn and listen to the team every two weeks. And if they start to struggle in certain aspects of automation, you have to start to enable them with either more people or have the developers also pitch in or find the right balance of what their backlog stories are in each sprint and start to inject some technology enabler stories along with product delivery stories.

Perfect. So once the team's on board, you have management on board, everyone's on board. I'll just curious to know the area that to me seems lacking still is getting feedback from production. So is there anything that teams can do that once they release production, they can get feedback or monitor something to then modify what they've done to make it even better?

Absolutely. So a key aspect of agile says you have to retrospect as a team. And I believe that the industry has gone to a point where they just retrospect as a people and they forget the technology retrospect that they need as well. So what I mean by that is continuous monitoring, continuous feedback and continuous inspection not just works for your agile practice, it's also for your technology platform. When you release a particular feature into production, you need to have the capabilities to be able to see how much of that is being used? What's the meantime to failure of that particular feature? Is it causing a blip in the right direction from what we expected to bring more revenue? So, for example, let's say we are releasing one click pay functionality for a team. You want to actually release it into production. Let's assume you have built it right, it works, right? All the tests are all good, it's all automated, it's gone into UAT users, pilot users are great, they think it's great and they have signed off. You put it into production. There's no guarantee that the actual consuming users are going to be on the same page as your development community here within your own enterprise. So you have to build in continuous monitoring capabilities, whether that be bringing your logs from your servers, using real time matrices from the feature itself to see how much of it is being used and how much did it actually bring in in terms of revenue because of that in comparison to when the feature is not in production? Those are actually key enablers to help the team reflect back and see what can they improve the next time they put out something similar. I'm not suggesting that you won't be successful otherwise, but these are catalysts to enable you to go to a quicker transformation.

Very cool. So, guru I was, you know, before I interview someone, I do quick searches on the Internet and for some reason I get some videos when I search for a name for tennis.

So are there any, this switching gears here, are there any parallels that you've learned from tennis because it seems like you're an expert tennis player to digital transformations, that you were able to apply some sort of mental model that you learned from tennis and then brought it to digital transformations?

Yeah, actually a lot of that helped me with my working career. I was in college in University of Florida and I had a terrible backhand. My forehand was pretty good and to be quite honest, my backhand sucked. So I was very intrigued by the University of Florida tennis players who would practice every Tuesdays and Thursdays and they would have beautiful backhands. Obviously they're experts and they train well and they keep practicing it. Right. So I started off to ask one of them to teach me in their free time. After about six months, one of them extended the favor, probably because he got bugged by my requests. And he came through one day and he basically said, I have about half hour to spare and I can't do this every week, so here is what I'm going to do. And he showed me a few things and he asked me to repeat them over and over again. And I kid you not, 45 minutes is what he spent. He got a ball machine and he sat right next to me and he made some little adjustments one at a time throughout that 45 minutes. And then he said, continue doing this for the next seven days and if you stop doing this, even the next day you're done. You won't be able to get to the next level. Right. So the next seven days I brought the ball machine, I started to practice hundreds of the balls and I realized, yep, this kind of.

A stroke. He corrected me on these aspects and all that. And it was very simple the way he applied the changes. When I came out of that, I said, you know what, I should actually take whatever he taught me and I should take a video out of it. So I requested Raul Torres and I said, hey, can we actually do a simple video for a lot of people who are probably in my boat, who don't have a lot of money to pay to expensive tennis lessons, but can benefit from these simple tips? So that's how it led to my tennis video that's selling on Amazon, although it's reaching a plateau for seven years now. But I keep those fundamental principles and take them to the Agile journey as well. So DevOps and agility is only the best if the teams continue to practice them every day, every hour, every minute, even if that practice is stopped for a period of time or the practice is not facilitated or encouraged. Often you tend to fall back into your regular set of activities, which is not conducive. So my point here is I've taken a lot of those simple techniques that teams can take and one time correction per Sprint methodology where you don't give them 20 things to change, you work with them to change one at a time, or one practice at a time, or one technology solution at a time. That has helped me a lot to take that parallel from tennis into it world.

All right, guru, before we go, is there one piece of actual advice you can give someone to help them with their digital transformation efforts and let us know the best way to find or contact you.

Wow. One piece of advice for the team.

I think.

If you were to summarize in one statement. Oh, that's a. That's a big thing. Sure. Okay, so, okay, I'm going to apply whatever I do in my day to day life as a recommendation of one thing. Never stop reflecting back at what you do and improving by way of thinking out of the box, because you're only as good as your last hour and I can be reached@gurusham monimail.com and I'm also available on LinkedIn and email is the best way to reach me, and I'd be happy to answer any questions if people want to reach out.

Thank you Guru for your digital transformation. Awesomeness for links to everything of value we covered in this episode, head on over to test talks.com 251 and while you're there, make sure to click on that. Sign up for a free trial link under the Exclusive Sponsor section to learn all about Source Lab's awesome products and services. So that's it for this episode of Test Talks. I'm Joe and my mission is to help you succeed with creating Automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Talks podcast. Head on over to www.testtalks.com for full show notes, amazing blog articles, and other automation awesomeness SA.