 This session would be a very quick rundown of 20 minutes about one of the software development methodology that we follow at our organization and along with a particular case study, how it was executed to one of the project. So, but before that, getting on to the case study or the business problem, the project, I just want to give you a brief introduction of why we have gone for this kind of methodology and what is the need of it. Like, predominantly we are also following agile or the scrum in most of our project, but at the same time, like, you know, why we have gone or thought about, like, you know, just doing something on top of that and build a methodology that will give a little bit more advantage to us. Just let's have a look at it. So, when we look at the industry actually, like, you know, we have very defined processes. We have many things. Many good things are there in the industry, but still, why do we need to have something else? Like, we have defined processes, different practices, C-M-M-I-I-S-O, we have lean startup, we have agile philosophy and the different methodologies. But still, like, we do have the stringent development and the management review practices, et cetera, but still, when you look at the reality, these are all we have it, but when you look at the reality, we still have the failures. We still have most of our projects are challenged, some of the other are, like, you know, they're failed. We don't get the outcome what is expected. We might get the output, compliance or projects are compliance to the requirement. We build exactly what it is asked for, but still, we don't get the expected outcomes as the projects were intended for. Many times, we get the poor user experience, like, you know, the user experience, whatever we are expecting or the supposed to get, like, you know, we don't get that user experience, customers are not happy, and so on and so forth. So then, just to get rid of, to some of this, or at least to minimize this, as we all understood that, understand that, like, you know, we cannot get rid of the, like, you know, all the negative things, right, with the one methodology or one approach or anything, but at least if we can improve a little bit towards that. So we started a little bit, doing a little bit analysis, so how to improve the experience. Experience from the perspective of the end user who is going to use my product or the services or the, like, a project we are building, or the experience of my employee, like, you know, whoever is building that particular product. So what can be done to improve that particular experience or beat end user or your own employee? And we started, like, you know, just going through the different industry research or the trend, the way the industry is progressing and, like, you know, the major trend in the market and so on and so forth. So finally, we picked up a couple of best practices or rather, like, you know, which is there in the industry for a decade long, right? But we have not adopted them very, like, you know, as a mainstream process or the practices. So one of the practice, what we picked up is the design thinking. So as, how many of you have worked on the design thinking or applied design thinking in your project? Any of you? Okay, so design thinking is one of the practice or rather, it's not one practice, it's a, like, you know, a combination of multiple practices or the, like, you know, way of doing things. It's a kind of philosophy. Where in the most focus, the focus of the design thing, when you say you are applying design thinking principles, the most focus is given to the end user. Before you build something, you see it from the end user perspective. Who is going to, it's not my customer, my, like, you know, the exact customer who has asked for building this services or the product. There might be some end user who's going to use that product. So just, we need to start thinking from the end user perspective before even we start, like, you know, gathering the requirement or building the requirement. In our traditional approach, what do we do? We take an inside out approach. We take the system. Okay, this is the system I'm going to build and these are the functionality. We build the system based on the functionality whatever we perceive that my user is going to use it and they are looking for it and they are waiting for this, like, you know, requirement or the features to be built. So we take a systemic view, basically look into, look from the requirement perspective, build it, then ship it to the product or the end user. Then that's where the experience comes in. The end user might like that experience or may not like that experience. So what design thinking actually suggests or the design thinking principle suggests, you take the outside in approach. So you first start from the end user perspective. What is your user segment for whom you are building the product and take it, what's their behavior? What's their, like, you know, the beliefs, what's their likes, dislikes. And of course to the business context, whatever we are talking about and then build the product, build the requirement on top of that from that and then start getting on to the, creating the system and give the product. So if you see it from the end user perspective, their likes and dislikes consider that factored in into your design and then there's a probability that product would be accepted by the end user and the experience it will create is a real good experience. So this is one of the principle that we thought of. So as you can see that's inside, like a couple of things I have mentioned over here, these are ingredient of the design thinking. Like understanding the user's behavior analysis, building personas, understanding the user's experience. So this is also, like, you know, lean startups suggest before you build that, you see how the users will traverse into the system, how, what all will be the different touch points of user into the system once they build the system. So if you do that, like, you know, you'll find that if there is any missing gap, if there is any things which is not giving the expected behavior of the system is giving. So we can find that and a couple of other things. In addition to design thinking, of course we are, like, you know, building that on top of our agile methodologies. So basically our, the base framework, we are taking, it's a scrum framework. On top of the scrum framework, we are building that. Along with that, we have, like, you know, this in our organizations we are, like, you know, bringing the concept of the pre-package component. So now what, so far in the industry, what we have been seeing is the projects are there. Once the requirement comes, we start building all the requirements, all the blocks, all the things, whatever is required and deliver the product. What if, but if I see from the manufacturing industry, like, you know, the way, how the car or any other manufacturing stuff's getting assembled, the components or the parts are built, like, as a separate and they're kept and when you need the, need to assemble it, get the component, assemble it, do the tuning, whatever is required, assemble it and then deliver the product. So, like, you know, we still, like, you know, trying to establish a similar kind of approach on a vertical voice, like, you know, different segments, like, say, banking and the healthcare, these are the two segments we are looking into right now, is building blocks based on the behavior analysis. So the segment of user, let's say, if we talk about the healthcare, in the healthcare, these are the general behavior of the end user and these are the components or these are the things or the systemic components or the technical components or the functional components, we might need it, like, from this segment of the user perspective. So we have a group of, like, you know, a group who is looking into this one to build the component and in our project, when we get the project, we start building the project, we try to see what all the components we can reuse, we can plug and play or if not 100% directly plug and play, we can do a little bit of engineering to that and then assemble it and build the solution. So that's the pre-package component, like, you know, the concept we are trying to adopt. We are not yet, like, you know, I would not say even 50% reach to the level where we want to, but we have started the approach and, like, you know, we delivered a couple of projects using the same. Along with that, we have the concept of unified resource. So though, it's the same as the cross-functional skills to what, like, you know, typical agile suggests. So what we say is, if the, in the development cycle, I have many stages, right? So we have the development, requirement development, you do the testings and you have the UI at front. So, of course, even if you do it in a scrum manner, but there are different skill resource they do, they does the thing. So now if my every resource has a little bit of overlapping skill who needs like, you know, little bit of assistance to understand, but they all fairly understand the, like, you know, the rest of the aspect, all the interfacing skills. Like, say, when am I UX, UX or the UI developer, hand over the things to the next level that the development. So they understand, the development folks understand little bit of UI or the UX part of it. So if that happens, the handshaking happens much faster. Handshaking between the one resource or the one type of skill to another type of skill happens little bit smoother way. And eliminate couple of ways what we generally face. So taking this few, like, you know, concepts or the principles, we just, like, you know, assembled our, this is not a new, but the assembled or the, like a customized approach. We say it's user-centric accelerated software development methodology, wherein the main focus is the user and centered around the users who built the whole thing. So the first step is to discover and then design and then deliver, that's how we do it. And it's an outside in approach, as I was saying, like, you know, we always take it from the end user perspective and then getting on to the system. So now let's look at the, like, you know, the business case, whatever we are, like, you know, this is one of the projects wherever we have implemented it. This is, our customer is one of the medical device manufacturing company in the US, it's a leading company and the problem statement was that basically into orthopedics, like, you know, device manufacturer, manufacturer. So we had to build a any device application, be it in the web or the mobile application. So to support the different functionality, like, say, awareness and the coping, coping up with the diseases or the pre-surgery, post-surgery and then, like, you know, normal recovery process on all the steps on that one. And the typical, like, end user of this particular product was the patient, by themselves, caretaker, caregiver, and the practitioner doctors and the service providers, hospitals, so those are the typical, like, typical end user of that particular system which we built. And the approach we have taken is, so as, like, you know, the, based on the whole approach is basically outside in and then we started with the behavior of the end user behavior and then get on to the business perspective. Like, you know, in this particular business case, business, like, you know, business of building the application for the any device, how it is overlapping with the end user's expectation and then what expectation of end user it is satisfying and then what all the touch points would be. We'll see that. What all the touch point would be and then devising the use cases, actually use cases, that needs to be built. Many times what happened, if we do this approach, it reduces the unnecessary lack of the features which we initially think a system might need or our system might need it. Yeah, so this is the complete view of, I'm sorry if the texts are not visible because the colors that I have used is not very correct. So this is the whole approach of the complete development cycle. We start with the envisioning and then we get on to the engineering, then assembling and then the deployment. But whole thing goes in iterative way. It's not like, you know, we complete the envisioning for the entire product at once, like in waterfall and then get on to the engineering. We don't do that. So each of them, like, you know, the envisioning goes in two weeks of iterations. Typically that's what, like, you know, the approach we follow. And post that, we take it to the engineering and the assembling, which is again, combining two weeks of iterations and then get into the next level. So now when you start with the envisioning with, like, you know, design thinking in mind or the design thinking approach, so these are the typical, like, you know, the activity that we actually did it for this particular, we recommend and did it for this particular project is to understand the behavior of the end user with this business context and then identifying their behavior and then that, like, you know, the user's journey into the system. Once we will build the system, why my user has to come to the system and if they come, what and how they will achieve the objective, what they want. So that's the, like, you know, the user's journey into the system and that exactly map to the, like, you know, the, what are the functionality we are going to build and helped us creating the use cases or the user stories. So just have a look at, sorry, just have a look at some of the screenshots, whatever we had one second. So, okay, so for the behavioral analysis, for the, while doing the behavior analysis of this particular project, we don't recommend any specific tools or, like, you know, technique or model to be used for the behavior analysis, it's up to the project, whatever you want to use it. So the, for this particular project, we use the fog behavior and model and hook model. So fog model is a three-parameter-based thing, like, you know, the model which helps us to understand what's the, like, you know, the user's characteristics in terms of three-parameter, like, say, to the name, which, what motivates them to come to my system, what will, whether they have the ability to work on my system and they are willing to work on my system or come to my application. At the same time, hook model helps us to devise how to, like, you know, tune their behavior the way we want. So taking these two, like, you know, models, we actually did that, this is, like, you know, we, it is not expected you to read this one, that this is the text, which data we actually, like, wrote it down after doing the behavior analysis for this particular thing. So what all, using this fog and hook model, so what are those triggers, what are those motivations and, like, you know, their abilities and how we translate to the functionality. And from that, that leads to the, like, you know, for each user segment, we had to do the, like, you know, the behavior and the what are the different paths or the different, like, you know, this path actually leads to the epic of the requirement and each path would lead to the epic and that will be broken down into the user stories. Thus, similarly, like, you know, this is a typical path, the detailed descriptions of one path for this project, that is for path for the one set of segment of user, that is the young people who has the low need of health assistance, but they have the ability to, like, you know, spend money onto that thing. So if that is my end user, like, you know, for that end user, how, like, you know, what all the action or what all the behavior or the features I need to include into the system. So this blue tick mark shows that these are the actions I need to incorporate or, like, you know, provide the facility into the system. And, like, this is overall, like, you know, the two touch points, what all the touch points in every path, what all the touch points, whether it's educational, whether it's like, you know, we need to have the call center or the connectivity with them and so on, so forth. And these are some of the, some of the typical use cases, whatever we have, like, you know, got out of that, the few screen shots of the typical, like, you know, use cases. So, you know, going back, like, you know, once we got the use cases, then we went to the engineering block where we started analyzing what all the existing component, as I was saying, that we have an inventory of verticalized component, and then to check what all the things we can reuse it or basically plug and play over here. And we probably, like, you know, around 40% blocks we could have used it for this particular project. The whole objective is to, like, you know, let's say initial investment of the organization to build that particular inventory with the verticalized inventory and then you get the benefits. So the initial, it's little costly, so we need to invest time to build that and then, like, you know, take it forward from there. And once we do that, and of course, every project has a little bit of differences, so we cannot get all the component directly plug and play. So what we need to do, we need to do a little bit of engineering to change it and then incorporate. And then do the assembling and, like, you know, do the deployment UAT and the deployment part of it. Yeah, so this is the whole approach. And now from the benefit perspective, if you, like, you know, this is what we have, I've noted it down over here. So from the envisioning phase for this particular project, we've got around 500 plus user stories, the granular final, like, you know, the user stories that was taken to the development for the building. And at the end of the whole, like, you know, the deployment, we've deployed the web application as well as the mobile applications with respect to, these are the key features, or the, like, you know, the functionality that we incorporated and delivered to the client. And still the project is going on, some of the other, like, you know, threads or the dimensions. And the team size of this particular project was like this. We had the analyst, we had an architect, and the, of course, the SME and one engineer and then one UX engineer during the, in the envisioning perspective. And whereas in the development side, I had only two development engineers and the two quality engineers. So because if you see the development engineer, like, a little less considering the, like, you know, the timeframe of the project and the scope of the project, because our whole objective is to spend money on to creating the inventory and the, so that my development cycle goes down. And so that we don't, that is the whole objective. We don't, do not want to spend much time in the development, but it's just an engineering of those blocks and then assembling them. So the whole idea is if we can do that, my, the project cycle, development cycle goes down, whereas we invest time on envisioning phase, whereas, like, you know, this will lead to a product or the services that will be well accepted by your end user. So, and like, you know, the duration perspective was the envisioning was the six week and the whole development was the 12 week. It was a kind of little bit of parallel overlapping stuff and the profit benefit perspective if when we compare this with our historical data, we got to see around like, you know, 25 to 27% of the schedule reduction at this phase or this particular project we had. Yeah, yes. So the whole envisioning for this set of functionality took the six week, but we have not done it like, you know, after six week, we started the development. That was the parallel, like the activity. After first two weeks of envisioning, when we got the few features which was created, user stories created and the prototype was created and the review with the client and it was agreed. So we took it for the engineering part and then we'll go went for the next set of like, you know, the requirement envisioning. So the total time was around 16 weeks time. Like, you know, because not one full cycle for this particular project. It was something like our envisioning was going on like this and then we like, you know, our engineering and assembly and then deploy. And there is options like since the base framework is the agile, like, you know, we can deploy it at any point in time whenever the customer is ready and then like, you know, set of features which is like, which is a significant amount which can go to market based on the customer thing. So, but in this particular project case, we did it at the end because it would be much less because from this engineering, like I said, like in this particular project case, we could not even use 50% of the component of the functional block as is because we're still maturing that our inventory level. So from each of this project as we execute, we also, it goes to our inventory saying that, okay, this is the new block or that we got it. And there is an additional effort that is in parallel going on to mature the inventory. So if you get the next project of the similar line, so probably it will get down further, further maybe a few weeks and so. Yeah? Yeah? So the first dependency or the first, like, you know, hurdle that we had it for the, like, you know, doing the user's behavior, like, you know, understanding the users and stuff like that. So here in this particular case, like, you know, we had good support from the customer to provide the information. They also did a survey of the, like, you know, before, like, you know, just coming up with the whole product approach of their end user. And also we had a couple of SME in that area. So that helped us. But there is another project which is currently going on where, like, you know, we had a dependency. It is for one of the South African customer. And we had a language dependency. And so we cannot directly, like, you know, like, you know, interact with the customers. And then, like, the end user also. So we have a, like, you know, intermediary team, so which we are tied up with. So they are helping us in gathering the, like, you know, the envisioning part of it or the user's behavior part of it. The current one? Current one, this is the first time. Yeah. Are scope creeps and scope changes? Yeah, scope creep, like, you know, if we, our expectation is, like, you know, when we do the, like, you know, this approach, outside-in approach or the design thinking approach, many times the scope changes or the CRs does not arise much. But of course, if it comes, then we need to handle it the way, like, you know, agile suggests. Basically, either you can exchange it with some of the existing requirements or, like, you know, you can bring that change and increase your, like, you know, the timeline of your release. So the probability or the expectation is once we mature onto this model, like, you know, we do the thorough of the user's behavior and analysis and the touchpoints and their experience mapping. So that would lead to less number of changes that we encounter down the line in the project. Any other questions? I'm pretty much done, actually. Okay, this is the last slide, as we already talked about, like, the benefit perspective, what we can expect out of this is the, that's the best benefit is the better user experience. So we try to give the better user experience to the end user and the cycle time comes down. And that's the third point, like, third and second point, which talks about the subjective quality. Many a times when you talk about the quality of the product, most of the time, you focus on the objective quality. So number of defects, defects, density, and so on and so forth. We never talk about the subjective quality of the product. So which is nothing but, again, the end user experience or the outcome, whether it meets the expectation. So it focuses more on subjective quality and gives you the better subjective quality as well as the outcome meeting the expectation or, like, you know, the project expectation. And, of course, the shorter time to market. So that's the best thing. Okay, I have not focused on the objective quality part of it. The subjective quality, as we talked about, if you understand the subjective quality, is nothing but whether it is solving the purpose for which you are building this particular software or the product. Is it well accepted by the customer? Whether my end user is able to use it and solve his business needs or the ones? Is it solving the main pain areas for which we are building this particular product? So that's called the subjective quality. And through our envisioning cycle, the way we are applying the design thinking and trying to envision the product and get the requirement or the use cases, so that's to take care of your subjective quality of the product. And with respect to the objective quality, of course, we have our standard. This is on top of your standard, the way we do scrum, along with the scrum. It's built on top of the scrum. So our regular activity of my unit testing, your like, you know, the, what are the, SIT, IT and all these things, all the testing happens as usual. It is a framework, it is customized methodology which is sitting along with the scrum. It's like, you know, just to incorporate few more practices along with the scrum to give the, some of the edge, some of the advantage which we are lacking right now. Yeah. All right, so I think I'm over shooting by five minutes. So like, yeah, thank you everyone for listening to me for the last 20 minutes. Thanks. Bye.