Episode: 446 |
Vijay Mehra:
Vijay Mehra on Agile Methodology:


Vijay Mehra

Vijay Mehra on Agile Methodology

Show Notes

Vijay is a former digital and technology leader at KKR leader and a founding member of  McKinsey Digital Labs in South East Asia. He is a highly accomplished expert consultant and Interim Chief Information Officer, and he currently serves Fortune 500 enterprises and companies invested in by the PEI 300. In this episode, he talks about a case example that illustrates the Agile methodology play in real life. Vijay can be reached through LinkedIn or Umbrex.


Key points include:

03:08: Case example: a legacy bank in S.E. Asia going digital

08:48: Getting people to participate in hackathons

18:15: The concept of the sprint delivery cycle

22:38: The Agile process from having the business and making it a working product


One weekly email with bonus materials and summaries of each new episode:


446 – Vijay Mehra


Will Bachman 00:01

Hello and welcome to Unleashed the show that explores how to thrive as an independent professional. I’m your host Will Bachman and I’m excited to be here today with my friend Vijay Mehra, who is former KKR. He was former McKinsey Digital labs. And we’re going to talk today about a case example that illustrates the Agile methodology play in real life Vijay, welcome to the show.


Vijay Mehra 00:26

Thank you. Good morning.


Will Bachman 00:28

And it’s great to be chatting with you. Sitting in Singapore today. I’m here in New York. Vijay, tell us about the the case example you’re going to walk us through.


Vijay Mehra 00:38

Yeah, sure. Firstly, great to be here, thanks for the opportunity. The case I’m going to talk about is one from Southeast Asia. Our client was a legacy bank, in the region that wanted to go digital, and typically, developing new products in the banking service line will take anywhere from nine to 12 months. And they wanted to see what they could do in terms of penetration in a new market, and the timeframe they’ve given us was was three and a half months. So we broke the problem statement down into a number of different areas we worked in parallel with part of the internal bank scene and our own strategy team to figure out you know, market segment analysis and profitability and where the where the, the sort of use for the digital bank is going to come from, and then we got to work to actually deliver the product. Now delivering the product was difficult, because we didn’t know what the right spaces were, in terms of what the market needed. This was a communist country. This was a country where local banks already existed, and we were a foreign bank coming into this country from the digital side. So we did a number of hackathons in the big cities, we did the angular hackathon is is in a very short period of time to be playing for the 40 years, a lot of ideation has done a lot of design thinking is done to quickly put together some sort of workflow in terms of customer journeys, in terms of the visuals of what the future would look like on a on a digital banking app, and play it back to an audience paid back to the folks who played back to folks online, get critique, you don’t get the prototype, quite extensively complete, to then figure out, you know, how people thinking how to making the decisions. What are they seeing when they share the prototype in front of them? What emotive response are they actually generating within themselves? And how do they then make decisions whether to want to open an account with that bank or not? And so based on that, that worked, we developed a number of personas to figure out, you know, is this a region where this is a country where digital banking should go first with retail banking, or supporting the sneak segment? Or is it a mixture of both. And based on what we found out from the hackathons and from the personas that were developed? From the hackathons we started, we found three things that the market wanted, that was currently not available. The first was for the small, medium enterprise, getting loans was extremely difficult. These are people who have small shops or small businesses of their own, they typically have some collateral that’s worth something, but they’re not able to get approval, and the process of getting approval is highly paper driven, and very cumbersome, very bureaucratic. So on the digital side, what we did is we, we ideated, you know, if with these with this for these focus groups to figure out if we were able to deliver a digital banking journey for the sneeze, but this sort of a approval for a small loan to finance or for helping the Small Business School can be provided provisionally that is a provisional approval within five or 10 minutes, subject to further verification of documents, this was done with this key market that could grow in the country. And one Behold, the persona mapping that we did said yes, this can be done. This is something that is a pain point nine is not is not actually supported by any local banks.


Will Bachman 04:17

Okay, so question. So who is participating in this hackathon? Was this employees of your client? Was this college students with random people off the street? You know, who was participating in this hackathon?


Vijay Mehra 04:32

Yeah, great question. So we segmented the hackathons. Just looking at the way the banking industry is segmented naturally, we segment the hackathons to the retail side and the PSNI side and on the retail side we had a mixture of college students millennials and then mid level and senior managers as well. And what we saw is you know, the things that we go to the bank for are very different and then similarly on the on the snake side, we segmented the sneezed by a couple of sectors that were more sort of voluminous in the country and looked at developing personas, you know, in line with those, those sectors, what he found was really interesting the, on the retail side, the the college students and the younger profile people, they wanted to have a digital bank for, you know, aspects of ease of use, when they went out to a restaurant, they wanted to divide the bill equally, or, as they whispered very easily between between friends, etc. And some of them had this notion that when I want to send money, I don’t want to have to put in all the banking information in Swift code and all of this stuff, I just want to send it on a mobile number for mobile number to a mobile number. And the space has a different set of criteria that they were looking for, we wanted to be able to have access to trade finance, we wanted decisions to be done more quickly. They wanted on monetized collateral. That is, you know, they have a small shop, they have a home, they have a piece of agricultural land, the big banks wouldn’t look at those as monetizable. But they had inherent value. So they wanted to see if there’s a new player in the market that will actually look at those those assets. And through a combination of, you know, information on the asset itself, and some big data analysis in terms of their own spending patterns, would they be eligible for a loan, and that’s exactly what we did. So we looked at credit bureau information we looked at, you know, we mined some data, in terms of social media and profiling, figure out is this a risky SNI, that one should not give the loan to. And then of course, that was just for the provisional approval, the actual approval was done after looking at all the documents and checking the authenticity, and making sure that the risk was in line with what the bank’s risk was, risk profile accessibility was, and only then the loan was given. But the entire process was shocking. And this really took off in the country, because Steve’s never never had the opportunity to, to be able to log on to a digital bank for the first time within five minutes. And then apply for loan within, you know, 10 or 15 screens input basic information on the business and get an answer whether or not eligible for provisional approval, and then have a mobile banker, here is one part of the app was the founders part of the persona development, that they wanted convenience. So one part of the app we developed was to have a mobile bankruptcy to go to their location, and pick up the documents that would then give the eventual approval. And so this, this was a service that that a was much appreciated. And B was we opened up a real new niche in in the country that had not been serviced by anyone before.


Will Bachman 08:01

So So how did you get people to actually participate in these hackathons? I mean, if I don’t know, some foreign bank, came to New York and said, you know, would you like to come to an all day session, like a 24 hour marathon session and help us generate ideas? and say, Well, no, you could pay me But no, I mean, so it was it was like a prize at the end? Was it just glory or a scholarship? Or, you know, just paying people to participate? Or, you know, how did you recruit people? And how do you know that they’re going to be like smart people to participate? at, you know, so who got invited? And what was their incentive for trying to come and do a good job?


Vijay Mehra 08:48

Yeah, great question. So it was a combination of a little bit of charity and incentives, and also made driven by lead users on the snake side. When we did we first did an online survey to figure out, you know, is are these are these problems that we think, you know, as initial hypothesis, are emerging problems are these really relevant in this new space? So what we found is a number of sneeze, you know, responded in a way that pesticides and as potential sort of lead users sneeze, and they participated voluntarily and then to the kids on the retail side. Not really kids, but the younger, younger profile on the retail side, we had some incentives and some prices, some iPhones and stuff like that. So a combination of combination of both. The not not all the work is done through the 24 hour cycle with everybody in the room. So the initial ideation and the the development of the personas and the empathy maps. Yes, that is that is done with everybody in the room, the actual developing of the working prototype and figuring out how to lay out the journeys and and And so on, this is done by a combination of the digital lab dance and the UX UI designers. And then the playback is done the next day with the audience. So we try and make sure that when we have third parties participate in this, especially as a relatively sort of skewed sense that it’s not too burdensome in terms of their schedule, so it’s more like eight hours a day time. And then, you know, our team is doing the 24 hour turnaround.


Will Bachman 10:30

Got it. Okay. So let’s fast forward a little bit. So you do the one with a subject, the small medium enterprises. And an idea emerges, I hypothesis that an app or the digital tool that would allow people to get, you know, provisional approval in five to 10 minutes would be a great thing. Walk me through that process of how you develop that and, you know, sort of what were the Agile principles you were using? And, and what did that look like? You know, just building some kind of minimal viable product quickly to show it to people, etc. So walk me through that process.


Vijay Mehra 11:09

Yeah, great question. So the the tip of the processes is that by design, thinking and tipic design thinking, is to really figure out how people behave and how they make decisions based on what they’re seeing what they’re hearing what you’re feeling, and a little bit about their environment. So the landing was, you know, the insight into leanings, and it’s in accessibility. And there are actually elements of collateral that these knees have, but that they’re not having the opportunity to get them monetized, or get them even reviewed by the larger players. All of this was all of these items were insights that emanated from the empathy maps that we developed, based on the interviews and based on the participation of this news. In the first part of the of the hackathon, the principles of AGI that these, you know, map back to are essentially three, three of the pro that really, really stand out. One is, the idea is to come up with a solution that is a working solution. Now, whether it’s a working app, or it’s a clickable prototype on a hackathon, it’s still an end product, it’s an end product that somebody can touch and feel, and Representative the market or representatives of the market can react to. And that’s one of the key founding principles of HR to prioritize the delivery of an end product versus focusing on processes. And two, we always want to try and focus on delivering working software, working prototype and frequently. The second principle of HR that was really essential to get right in these hackathons was one of adaptability. And in Israel, the focuses on Quick, quick pivots, small pieces of work, and the ability to quickly change and adapt to changing circumstances and changing requirements. And this is happening constantly in Africa, because what do you think is important, you know, in the first half an hour is going to be not necessarily the same in a second now, based on how those empathy maps and those personas are evolving, based on how the teams are actually working with their stickies and problem solving and adding their comments and comments and input into synthesised, you know, abstractions, if you will, and the persona evolution is being done. As that as the process progresses. The third piece that’s really important is the self motivation of the teams and individuals. And here, you know, they were different, they were driven by different levels of motivation. So the youngsters wanting to bring the price on the sneeze genuinely wanted to solve the problem that had been unsolved up to now.


Will Bachman 14:06

Fantastic. So what we’re walking through some of the steps that you went through, you had this concept, and then what did the team do first to, you know, develop some kind of working prototype that you could get people’s reaction to?


Vijay Mehra 14:22

Yeah, so great, great question. So the, the empathy maps in the personas are still sort of a bit abstract, they’re hard to react to by themselves because one doesn’t have the synthesis of what that means to the look to the look and feel and flow of an app. So the next step from empathy mapping and persona development is to actually have what is known as wireframes develop and this is think of it simply as you know, if you and I were to take apart enough my level and you know, divided into three, put it in In a portrait, sideways format and divided into three columns, and then tear it, and then put, you know, say, 10 of these pages, so 10 times 330 on a table left, right? And literally start drawing up, what would screen one look like? What would screen to look like draw up in a cartoon fashion grew up in, you know, sketchy pictures, graphics, etc. and the different teams. In each of the teams, we had a UX designer that was embedded, that would basically take information from the persona mapping and the empathy mapping and translate it into what the screen could look like, based on what’s what’s the evidence in the data in the in the empathy map and the personas and then co create that with the team. And, you know, there’s lots of editing lots of sort of free flow of information and joint collaboration to get this done as a, as a sketchy set of paper that sits on a table left to right. That is, when when done is essentially a graphic graphical rendition of what the screen sets would could look like, and a flow as well as to what which screen leads from from from here to there, and what the overall flow is. Now, once that is done, then the UX designers work with the devs, to actually put that into a clickable prototype format. And there are tools out there in the market, we can do this very easily in an envision web app. Or we can do it on a mobile app as well with a click of a set of clickable prototype tools. And what you get at the end of that is essentially an app that sits literally on your phone, it’s not coming from the Apple Store or the Google Play Store, but it’s sitting on a phone, and you can work with it, you can you can press it, it moves to the next screen. data entry fields enables you to and to enter data, and you can react to it and you can actually get comments saying I like this, I don’t like this, etc. And so that iteration happens as a next set of iterations in the in the hackathon. And then that eventually leads to sort of a curation of the final output of the hackathon. Now this time, none of this is a sprint. All of this is just the hackathon to go from sort of market surveys and segment analysis to the design side of the empathy maps and the persona development to the customer journey development to the wireframes to then a clickable prototype. Once the prototype is played in front of the same set of participants. Generally, we try and also put it out there in a secure survey to get a broader set of, you know, 1000 2000 people in the market, react to what this smaller team has done, and then make another set of edits and only after those set of edits then we get into the delivery sprints, either weekly sprints or fortnightly sprints to deliver the product to actually write the software well are you


Will Bachman 18:04

there? Yeah, no explain this concept to me of the sprint. And how that’s different from like this what you hear about waterfall being contracted with.


Vijay Mehra 18:15

Yeah, so the sprint is the delivery cycle in a jar where the product is being brought to life and the frequency of the sprint, the cadence the frequency of the K the the person you are calling cannot accept calls at this time.


Will Bachman 19:18



Vijay Mehra 19:19

a well, I think I I think I used up my prepaid minutes so I’m just switching to my Singapore mobile fix this and the recording the break.


Will Bachman 19:27

Yeah, we can take the breakout overall.


Vijay Mehra 19:30

Okay, okay, great. So let me answer your question then. The sprint in HR is the delivery cadence. So whether it’s a one week sprint or two weeks, it’s the cadence the frequency with which you’re bringing the product to the market, or at least to a live production environment. When you compare that to waterfall, waterfall has a much more extended delivery cycle where typically there’s a requirements gathering that could take depending on the size of the system or the applicant In a few months, then there’s a high level design and there’s a low level design and the actual delivery starts. And then there’s a unit testing, integration testing, and then a push to production. So typically, you know, could be many factors into 10 to 15x, of the sprint cycle. The other difference between sprint and waterfall, and there’s really two, there’s two key elements here. One is, the pieces of work that are delivered in the sprint are much smaller. And each of them is a working module or working part of the bigger picture of the software. The second part is that second main difference, a big difference is that in the waterfall approach, you’re actually defining requirements to the nth degree of detail for something that you have no clue, you know how it’s actually going to work and translate from requirements into life into production. So requirements on paper design, again, on you know, in design tools and in, in people’s heads and on paper. And then the thing that’s actually live has a variation between aspect and as build that deviation and that that gap is essentially removed in the in the HR framework, because the delivery from idea to working software is is highly crushed is made much more much more fast. So when you deliver a piece of software, or you deliver a module of the software, and you get feedback from the market that well, I like this part, but I don’t like that part. I like the journey of approving of the the information in the provisional approval. But I do not like your application to be more specific, it’s too cumbersome. I don’t like the two factor authentication for reason, ABC. We can react very quickly to that in an HR delivery cadence. You can’t do that in a waterfall delivery cadence because the setup of each of the steps is much longer. And you don’t have that information until the pool system is delivered versus pieces of the document.


Will Bachman 22:13

Got it? Okay, so much longer process. So then once you have gone out and you build something quick, and then you you know, you did the survey 2000 people to get the reaction to it. What What does the Agile process look like to go from there to actually having the business and making it a working actual product?


Vijay Mehra 22:38

Yeah, so the first step is setting up squads in terms of you know, how many squads Are you going to have an what is the composition of each squad. In our case, we have a very specific example, we had four squads, and each of the squads had 10 members in them. We had two front end UX UI specialists, we had three front end devs, we had two back end devs. We had a QA, quality assurance engineer, or test automation. And then we had one role that spanned across the squads as the senior DevOps engineer the person that setting up all the tooling, making sure that the CI CD pipeline is working, also playing the role of architect technology architect across across all the squads. Now, these squads can work in an API cadence of weekly sprints and delivered the the feature so we deliver the features in line reporting called epic so there was an epic for the onboarding of the PSNI, there was an epic for the provision approval, there was an epic for the the collection of documents and the sending out of the mobile banker. And on the retail side there was there was an epic for the onboarding of the retail customer, there was a epic for transaction history, there was an epic for the split, and the ease of use of sharing of payments across the mobile platforms using the phone number, etc, etc. So based on these epics, then the epics are broken down into stories. And the stories are broken down into story points now that breakdown so the epic selects the epic allocation to each epic is allocated to one or more squads based on the competence and skill sets in the squad. And then once the epic is allocated to the squad, the actual computation of how many stories you know the complexity of the stories and decomposition into story points is done individually by this by the squad and that’s a strength of a joiner and that’s also weakness. So, one of the things we did to make sure that we were bringing to the strength on the AGR side in this case You made sure that the squad the full stack developers, which fought well, and these are typically the more the more experienced developers, that they were following the same principles of complexity in breaking down the stories in the story points and assessing the complexities with the common sort of planning. So a lot more stand up a lot more communication across squads to make sure that hey, if I’m counting these three screens, as you know, 20 story points, that in another squad, three equivalent screens are being also counted as 20 story points in 10, which would make a difference in the velocity and the difference in the Pacific output and real output of each each spot.


Will Bachman 25:47

Fantastic. So vj, if, if folks wanted to learn more about agile follow up with you, where would you point them online?


Vijay Mehra 25:58

So I can be reached across through Umbrex, where I am one of the independent consultants at Umbrex. And then they can reach me on my LinkedIn page as well. And happy to happy to answer any questions you have with any, any support etc. My my, my way of working with Umbrex is through my own little LLC and that email is ej Naira at D two T two llc.com.


Will Bachman 26:30

Great. Well include those links in the show notes. vj, thank you so much for joining today.


Vijay Mehra 26:37

Thank you so much. Well, I really enjoyed the discussion and thank you for the opportunity

Related Episodes


Nicolai Chen Nielsen, Advisor, Author, & Entrepreneur

Nicolai Chen Nielsen, Advisor, Author, & Entrepreneur


Tom Critchlow, Writer and Strategy Consultant

Tom Critchlow


Author of The 2-Hour Cocktail Party

Nick Gray


President and COO of Bunkerlabs

Joe "Hark" Herold