 Welcome to our next session, which is going to be run by Sridharishan Decretion. The title of the talk is Dot Tune, Eliminate Waste in Software Development. So without further delay, thank you Sridharishan, you can now begin. Hey, thanks, thanks for the kind introduction and good morning, good afternoon and good evening to all the people depending upon the time zones you are in. So today for the next 40-45 minutes, I will cover on the Dot Tune program. All our programs as part of our transformation, we start with that dot and primarily the tune is something like why do even the best people have coaches for them? For example, why does Virat Kohli has a personal coach or any other sports person has a personal coach? Everybody is performing at the peak of their performance and then you just need that small amount of tuning like how you tune your engine for the best performance. And if we tune in that particular aspect of it, we could have greater outcomes and efficiency. So that's why we have named this particular program as Dot Tune. As I said, any pressing questions, I request the moderator to ask that because I don't see the chat window as I have put it in. I have the dual monitor on the other side just to keep track of where the slides are positioned and moving on. And in screen mode, I don't see the chat window. So if there are some pressing questions, moderator do stop me and I will take it at any point of time. Sure. Thank you. Yeah. A small introduction about myself, right, you know, being in the industry, software industry from 1999 onward. I've been a hot core telecom engineer in dealing with the mobile switching and part of many of the first installations all over India, starting with small 100 line exchanges to as big as 10,000 line telephone exchanges and then, you know, part of the paging as well as the cellular networks and then shifted to software. Okay. And being in the industry started as a test engineer to start with and then grew up the later. Currently, as the program director of software center of excellence, which is a transformation program in Phillips. Just a small one we have the campus which has got started in Bengaluru is 25 years old this year or 25 years young this year and then so that's what you see in the slide one. Okay. So today, what I'm going to touch upon us. What is the foundational block. Okay, so I'm going to talk about something like software culture, what we have defined. Then I'm going to talk about your overall view of the transformation which we are in and how does this dot tune fit into this whole transformation, and then we get into the program some pattern analysis, you know, what are the results. What do we want to do for scaling up and so on. Just a caveat here, especially on the return on investments, I'm just actually bringing a small example of return on investment, because many people one of the fundamental and foundational questions that people ask me is that, hey, okay, we have got better investments, what does it mean, does it mean that you know, are we going to scale down on resources. Okay, this is one key question that I keep getting in many of my conversations and also in my external presentations. Okay, so it is not so as we move up in the program I will talk about it. Okay, it is not so this has nothing related with the descaling of resources are you know, reducing resources. When we achieve that particular productivity game, right, so in fact, we are actually looking at how could we reposition these engineers into the new NPIs. How could we make them better, right, how as each one of us individually, we could be much better than what we are today. And that's also one key reason why I'll talk about some of the potential savings that we have year marked right, I am not actually dwelling too much on a very big scale into this for example this program has something close to 15 million euros over a three year period of time. Okay, that is the overall savings that I have projected but in this session I'm not talking about it too much. I'll be more than happy to take some of those questions, you know, something separately outside. Right, so, so that you know it doesn't clutter that this is not a headcount reduction or key, what do you call doing away with engineers. So I just wanted to clarify that at the start. You will see that you know one of the key things what we focus our first and foremost is on the software culture, and then when we actually started this transformation program and then interacted with multiple people. We said there should be a foundational block on which you know we are doing a few things. Okay, for example, you know, make innovative software and innovate on making software here, the foundation and the fundamental question is, okay, what is new? What is innovative that I am doing? Okay, am I able to bring that Y part into each one of the activities or work that each one of us do, because this also has a linkage with neuroplasticity. Right, the moment when we start learning something new by the key fundamental questions of why and what right, each one of us start thinking in a completely different manner. Right, there are, there are tons and tons of data that's what a and ml all do for us and all those data are in front of us. Okay, are we collecting it for example, some of the sessions I was actually looking, you know, even in this conference, right, you know, we talk about so much on DevOps, two key pieces over there, both on the, the, the preventive side of it, as well as the, the collecting of data, and how do we feedback it as a continuous loop from the operation sites of DevOps, right, so collect and exploit data, just kind of correlating to some of the examples what we see here in the conference. Prefer show versus tell, right, this is a very, you know, appealing one for me, right, many at times people come with loads and tons of PPT deck, right, instead of it when we talk to a software engineer, we just ask them to give that a small increment in code. And they don't tell us like, you know, you know, hey, this is what we could achieve but make a very minute and a small slice, and then show that as working with your devotee. Okay, try versus speculate, right. So, if you want to prove a concept, come and try that instead of saying that you know in a vacuum this is how it will be again prevent over detect. So, we just talked about the DevOps there. Again, precise and fast feedback, how could you make the loop iterative and very fast in all that we do. Testing is a most important part of each one of it and in fact, you know, we always tell people do not differentiate between the test code versus the development code, right. Again, you could see that as the last point of it as well as treat test code and source code as one and equal. For example, if you keep about, let us say, on an average when we do analysis and observation close to about 40% of the test code. There are, you know, glaring duplications over there, right, even one line of duplication costs you money cost the organization money because that has to be main day. It doesn't mean that it has to be only at the source level. If you see a waste anywhere, it's a waste wherever you find. Okay, focus on automation, everything you can. Okay. In fact, for example, the CI for CI in DevOps, right, automate the automation. Zero weight and queue times. Okay, if you actually get into this value stream mapping close to about very quickly, you can find that the waiting time for any activity consumes close to 60% of the overall time. Okay, can we actually reduce those weight as well as the queuing time for waste, courage and humility. And this is where, you know, we also encourage each one of the software software developers, right, you know, anybody who are in the field of software be it manager be it's supposed to be developer DevOps engineer, configuration engineer, test engineer, depending upon whatever it is, right, courage and humility, how can we tune each one of them to be the best for these things to happen behavior changes are key to cultural changes. Okay, if you actually look at each one of our behavior directly leads to the cultural change in the team we are in, in the place we are in, in the organization we are in. So, so this is the type of software culture, right, you know, which we try to spread as part of this particular transformation. And you know, we could say that we are seeing results over. Okay, now, coming back into the next steps. This was a research done by Microsoft and then on the right side you could see that up to 78% of the developers time is spent in understanding the code so this is the data from Microsoft research, which means that in eight hour productive day for an engineer close to six and after seven hours, right, the engineer just spends in understanding the code, I will give you another data for 1 million lines of Java code, right, if you have to maintain it, the cost of that maintenance today is about close to 300k dollars. If it is a C or a C++ stack, it is close to about 375 to 400k dollars is the maintenance of it and then you know, if we have to look at it on an average for 1 million lines of code, the total amount of maintenance here for after 1 year, the code is a maintenance code based depending upon your product life cycle. The investment that needs to come from the organization is the is this particular content. Okay, and imagine just about you know, there is a stack of about 10 million lines of code or 20 million lines of code, very easily we are actually talking, you know, only as maintenance close to about 6 million to 7 million, right, so and then if we just keep adding things like you know, building the technical debt on this stack. Increasing amount of duplication, right, I just wanted in another two of us, right, I just copy pasted, I have 15 product configurations, I just copy this particular snippet in all the 15 product configurations, right, and then I miss out on two configurations it ends up in a field call, right, for that. Okay, so these are all the side effects that comes in, having a boy scout rule, right, if I see an issue, do I solve the full issue or I actually just do my work for today, or that particular task and keep moving on, right, so again this is related back to the culture. The end to end systems thinking problem solving, right, you know, of course you'd have heard quite a bit of these things. As I said, software development is a cultural movement. Okay, and we actually need to look at it more as a cultural aspect, rather than looking at, you know, I need to do some changes, I will do it, I will keep moving on. This is somebody else problem to solve it for tomorrow, right, so if we leave things as it is, right, it would result in a broken window concept, which in simple terms mean that, you know, if one pane of the window is broken, right, people would actually, so you are actually waiting for a crime scene to happen where all the windows would be broken, right, so this is the analogy over there. So if we do not address few of these things, okay, our code stat would tend towards the broken window and that is also a key reason why we had introduced this particular Tune program where we could correct a lot of things at the developer level in order to make all these things, you know, towards a better software development culture. Okay, some of the transformation programs that is continuously happening, okay, I'm not going to touch the whole of it, right, because this is just to give an idea or a landscape. When we say transformation, what is it that is running, okay, we have something called as the software excellence framework and then, you know, I'll just do it pretty quickly, we first started with the scaled agile framework, we have close to about 100 agile constraints that are running the organization, close to 4500 people, there are close to about 50 plus SPCs, good results that has come in. Okay, craft, starting with very, very fundamental things of shift left quality addressing, you know, things at the developer level, as I quote, the developer gets the list of issues that are there. So even before he could actually commit his or her code, right, so we enable an improvement opportunity for the developer to correct so that it doesn't get into the commit stage, it doesn't get into the pull request, it doesn't get into the nightly build, it doesn't get into the integration, because if you just keep these cycles, right, what you are actually doing is you are increasing your list of rework for a wrong commit. Technical debt, yes, that's a very familiar term in the industry, then we have something like a dot connect, the dot connect are programs where, you know, we do multiple workshops, either one on one with the developer depending on his or me or a group workshop, for example, there is a new algorithm that needs to be done, or if it is a code refactoring, where we would just like to throw away 300k lines of code, right, so those are programs, you know, which are addressed by dot connect. The dot grow is skill and capability building, you know, primarily, this is to scale up people for the new digital transformation, DevOps, I think, you know, we have heard about it. The source code, we are actually building a culture, all code that is written within Phillips, okay, by default, that should be available for anyone and everyone. Okay, so that is the first rule, the second rule is, then if you actually want to keep it as closed source, depending upon IP, depending upon some potential patent aspects that are there. Okay, then, okay, that you can actually term it as closed source and it is available only to the limited set of project team. And then we heavily encourage people to be on open source asset, which means that if you have something which you could share with the wider industry, you could do it. In fact, from the software center of excellence, periodically we even keep posting in LinkedIn and other places. Some of the work what we have done, especially on shift lift quality, then we have something called as a smart test ordering which will automatically look at the changes in your functional test at the code level. And then, you know, it will say that where it is impacted in your code base as well as the test and you could quickly go and correct it. So, we have actually made these stuff as open source, anybody could pick it up. Okay, and it is available, I can even share those links later. And the dot tune program is actually part of this whole transformation program. And primarily, we would work in revolving around eliminating the waste development is. And for today's session, that is where, you know, we would spend our time and then we will look into it. I will just quickly skip this. These are some results like, you know, from the transformation program year on year. We actually look into how do we do what do we do, right, because we need to have continuous flow of data. I will skip this particular slide. Coming to the based challenge, right. If you actually look at it, all of us love to be productive and effective. Okay, and then, again, just linking back to the behavior. How do I take care of productive behavior and how do I do, you know, if something is unproductive? Okay, what do I do? Do I know what are the things that are slowing me down? A classical example, right, you know, people say that it is just a two line change in code by the time. Some changes are being done to the time releases made for the two line change of code, right. You could see that it almost takes about three months time. And the reason being is that, you know, the code complexity level, the next to surrounding bits and pieces of it. Okay, the changes what I have done here, if it has to be reflected in another eight or nine product configurations, how should I handle it? So these are some of the things like, you know, since the complexity is very high around it. We do not know, right, you know, what is it that is really slowing us down? Okay, and am I going to take actions to reduce it? Okay, let's put a program together and try to achieve a culture of zero waste. Okay, and look at quantifying and eliminating the waste and productivity or predictability quality would be the byproducts of this. So when we start this program, very small, right, you know, in our observation, I'll come in the next slide, what we do here because we do not, for example, you know, straight away quantify like the whole meeting is a waste, right, or the way of working is a waste and so on. So this is more to do at developer level and also surrounding the areas in and around it. Okay, most important, I reiterate, okay, the when we gain an opportunity. Okay, so we first initially said to the leadership, hey, very easily, we could give you greater than 10% improvement. Okay, so that's, you know, the first projection which we made on just observing a group of about 10 people in various domains in a couple of businesses and then it made a pitch to the leadership. Okay, then, you know, they said, okay, go ahead, let's see where we get into and then in the program itself we said that reallocation of this productivity, let's say I have a group of about 100 people. Okay, I get about the productivity savings of 10 FTE over the year, what do I do with the 10 FTE? Right, so in all these cases they are actually moved into the new NPI, which means that next year when you are asking for the new NPI budget, you start factor factoring in the gains what you do today. Okay, so that, you know, of course, for example, you know, we need to set up a huge DevOps team, right, so are we actually just going to keep growing exponentially or are we going to make efforts from these productivity gains. So these are some of the constant discussions that take place. So how does this particular program work? It is based on deep observations by qualified experts, right, and depending upon whichever is the native language they are in. The participation from any developer is voluntary, right, and then we actually request for close to 60 to 90 minutes from the developer. And all we say that is that, you know, hey, we will just observe you in your work. And then we would ask you probably in that one hour of observation close to four to five years, just to understand what you are doing. And post the observation session, we will have a feedback session, right, and it could be any task that has been assigned to the engineer for that day so that the actual work of the engineer is never disturbed. And then, you know, we also make them quite comfortable so that it doesn't become like, you know, just on a joking way. It doesn't become a surveillance work of what the developer he or she does, right. And all the information that is actually gathered here does not go into, for example, a performance appraisal or it doesn't get into, you know, the development goals of that engineer and so on. So that is nothing like, you know, we just make an observation and say that try to grade this engineer on a scale of one to 10. Here is the engineer with about six and then another person has to improve or increase their skill set to nine and so on. So, right, you know, we make those things very clear. The only thing is we say that they don't say to us, you know, I am actually making a training session or we are in a meeting, please come and observe it. We say that this is a hardcore coding work or a design work, okay, or a bug fixing work, or if you are solving any field call issue, algorithmic work, right. So we say that, you know, bring those type of tasks so that, you know, the expectation is clear. We also collect a feedback survey, which is anonymous. And the main intention of that feedback is to consolidate and collate a lot of these patterns, right, you know, leading to these behaviors so that we could ensure that it is not repeated or made as a learning for someone else back in the organization. We had also done a privacy compliance assessment on this and we have a go ahead from the Phillips legal, you know, in compliance with the European laws that we are not violating any of the privacy constraints, right. So I will just skip this particular slide because whatever I spoke in the previous one, it is the same here. I just wanted to say here, we also make businesses part of it, right, and then we actually say that after we do, let us say, observations in a business, we actually train and coach one of the key or two key persons within the business who could actually take up the same observation role and then they could actually make it further, you know, shareable within that business so that it actually sticks there, the changes sticks there. Okay. And of course, is there a scientific reason over what we do, right, you know, we actually had a lot of data that we got collected before starting this particular program. Okay, so if you actually see here on a simple question, do you see repetitive waste patterns in your business? Okay, and then people say that, you know, opportunity for waste elimination, right, up to 34% of the people said 5 to 10% could be removed, 8% said that 10 to 15 could be removed, up to 5% waste is there, 25% of the participants said, and then 33% said that we do not know, this is quite interesting. So we have 33% population, you know, just be it tech lead or architect or a project manager, right, you know, who do not know, okay, there is a waste, which is there in the system or not. Okay, because the proximity of our work or you know, getting into the day to day operations sometimes blinds us. Okay, so that's the, so there is a huge opportunity for converting this 33% towards the other percentages where we could get it. So where does the waste go and what buckets it does fall in. Okay, so if you actually look here, the repetitive waste. Okay, many at times repeated manual testing. I just pass a particular parameter, right, and then I actually, you know, do my coding, I invoke my parameter manually, give those values manually and do it. Okay, I repeat this particular sequence of checks close to 25 to 30 times. All it needs is a one line script to say that, hey, temperature, okay, pass this parameter. Okay, the normal range should be between 90 to 108 degree Fahrenheit, okay, Fahrenheit. And then, you know, if it doesn't match for it or the glucose tolerance value should be this. Okay, if it goes beyond the boundary, okay, insert and assert. Thanks. So these are all simple one line automated scripts that you could do as part of your development. And then as you type, you know, that could actually run and give you the results, hey, you are doing something wrong. Okay. So similarly, like, you know, the waiting base, we looked at the start of it, right, you could also see that, you know, we have too much of duplication debugging without breakpoints. Okay. Again, code is built, but waiting to get deployed, it is always there on the staging. How do you handle blue, green deployment, remote desk software deployment. I'll just, you know, come here in my next slide, you could actually see that a small example. I'll just, there is a small video here. How do we do it? So this is a developer at desktop. I had taken permission from the observer to show this particular video snippet. I have actually made it faster so that, you know, as part of the one hour observation, it doesn't just give me one minute. Okay. So, so while the video is playing some of the things what you notice around there. Okay. Multiple context switching by the developer, right. Chat programming with a lot of people in order to get some information or saying that this is what is happening around. Okay, delayed action. Then you could also see that, you know, the engineer is switching on to look at some information related to image scans and how that particular scan needs to be looked into, right. So I just made the video run very fast, but this is the work within an one hour duration. Okay. And, okay, so if you actually look here, and, and in fact, you know, this is also feedback back to the developer and also look at the responsiveness in terms of the developer in taking it in a very positive way. Okay, multiple sources of truth, right, you know, you the person keeps switching from close to six to seven sources of truth. And each sources of truth when you actually keep switching like this, you have that much of ways that gets gained in the system. Okay, context switching between the work the person is doing. Okay, now they quickly they have to shift towards the image they have to shift towards the there are also a few things that comes as. You know, the disturbance or asking some other person and waiting for the feedback from an architect or a person. Okay. Can we have all information together as a tribal knowledge because there are a lot of experts within the organization who could do it right in a who could help us with the one key point which I wanted to state here is when the developer has their tech lead architect or project manager, okay, who are with them and shows an interest in the work that is being done by the developer. Right, you know, automatically, we have seen that you know the the level of engagement and also the pride increases to a great extent when I say the pride increases to a great extent. See, I have a person who cares for me I have a manager who cares for me and who is interested in the work that is being done. Okay, so we just pick up some of these patterns and put it into a wiki page right now for example, this whole of in many areas we have actually refactored the including test code. Right, and then very recently there is also an example where using simple techniques that team found out that close to 300 kilo lines of debt code would be removed from the system because each of the for example at least talking for the medical systems domain. The stacks are close to about you know 10 million lines of code and on an average they have a 10 year life expectancy right so always in these things you know people say that hey never disturb a working system, leave it as it is you do something right you have found out where to do a change just copy it into a new class. Okay, pass that particular parameter into that method and then leave it there do not do anything else because we do not know what impact it would create. Okay, just go back to the culture part of it Boy Scout rule okay if you just leave it today as it is again tomorrow you are creating a maintenance headache for your own and for the next person right again these are some examples. Okay, so when we actually show these patterns to the leadership continuously so there is a great amount of engagement they want to do and they always would like to far up with us in this slide you know I just wanted to highlight here. Okay, I have just included few more slides so that you know when I share it, you will get a good view of what it is all about. You can see their same base patterns. 65% this is actually coming from feedback survey 65% probability. Okay, whatever is the waste that is seen in my place. Okay, I could relate it it is there with another developer in my scrum team, it is there in the in my floor in my overall agile release train. Okay, right and then individually third eye on what do we do out of the box blah blah blah. Okay, the program has a score of about 8.4. Okay, so some of these ways we saw in the previous slide as well. Okay, so after we do an observation what do we do we run some workshops with the team as I said at the beginning. This is for a very small 40 member team. Okay, when we actually did this observation so this is just to get a view of what do we do so within that 40 member 32 people. Signed up. Okay, and then we did those observations and. Okay, so they actually classified where their particular base patterns are there and then they even said that hey what are the things that needs to be reinforced what actions we want to take. And also there were few items which is actually got some more new investments the business said hey I'm not going to do new investment now but I actually want to do. Do things which are in my control as a first and foremost and they took these top seven actions. Okay, and then that's actually based on the actions that were there it actually know the team said that we could say about 22,000 hours and you know, at the current cost that actually translates to about 600. So this team started in Q2 they are running their actions in Q3 and in Q4 they said that you know we could say 4000 hours which is about 115 K Euro and in the next year they said that you know we would get the remainder of these improvements. This is just a given idea if, for example, somebody who is very keen about return on investments and what do we want to do about it. Okay, there is a possibility you could go in that particular direction as well. Okay, so again so these are all coming from the just added some business results I will share the deck you could look into it here if you actually look at it. After we do this is it possible to sustain right so feature ABC you could actually see that you know the original estimate was 23% months. Okay, and based on the observations and the new patterns that team has already started implementing they were actually and with reduced complexity in the code they were able to finish within 12% months. Okay, so this is all from one same project team. Okay, where because of the reduction in the overall complexity, putting across the new way of working, primarily having shift left part of it because we always do estimation based on past projects, right. The first estimate was this, and then when we actually completed the actual work you could actually see the gain that has come. So this, this is primarily to answer the question right you know hey is it possible to sustain. Okay, so how do we want to scale it up right make business part of the problem the crime. Okay, and when you know when a person observes right you know developers within their own as well as outside the work. Okay, so there is a lot of learning and a type of knowledge that could be generated. And another interesting pattern what we have seen is we have seen many people who as observers when they come in, they actually go and ask the same person whom they observed, hey please come and observe my work and provide me the same feedback. Okay, so it no longer remains as a judgmental aspects, because many a time you know when I actually even attended the few external events to find out you know what is being done in the industry to get this work going on we see that you know people primarily focus on things like a let us improve Ajay way of working. Okay, let us improve, you know, meeting, let us improve, you know, waiting waste and things like that. Okay, but if you actually get at the code level, a lot of these improvements you know you could actually see results visible. I would say the next moment the next day the next month and so on. Right. Many people want to call it as part programming equivalent. Okay. It doesn't matter what you want to actually call in the name whatever works for you. Okay, very easily it could be done. All it needs is some deep level observation at senior levels, I talked about the dot connect program. So it's a it's a team of workshops, right, you know, and then from there only we got this idea for dot tune, where we just tune the parameters and then try to get the best summarizing. Okay. When we actually get into a deliberate practice that is repeating the the same good work what we do. Okay, again, I make a very classical differentiation between repetition versus duplication. I'm not a favorable person for duplication at all. But when we do a task. Okay, we actually gain the mastery and skill to complete that particular task. And when we actually do it again and again in a right manner, it actually acts as a deliberate practice. And then these are something which helps us to get into the next level. So I would be more than happy to partner with anyone to share more details, improving the software excellence share ideas. Okay, and how could we make it better. In there. Thank you so much. So nice. It was amazing. Thank you for sharing those insights and all the data and the beautiful journeys that come through. Thank you very much. And from the chat, I do not see any questions in the question and answer there is just one question that's come up in the reason I'm going to read it out. Yeah, please, that would be helpful. It's from Ashut Narayana. He says I agree with some aspects, but somehow I feel there is micromanaging that this is micromanaging. You're a developer just needs to glue to code right in window and keep on coding without turning around. Okay, see, for this also the other thing is, okay, for example, there is also an option, right, the person can just record only that particular window, okay, without even turning around or whatever it is. And then, for example, I did not go into the final details of it, okay, when you actually do an observation, it is possible that you get a personal call or you want to move out. Okay, or you want to say that, hey, 20 minutes now there is a focused work next 20 minutes I'm taking a break followed by your work. Okay, you can just record that and even send it to any observer of your liking within your business or outside your business. Okay, or if the observer wants a completely different pattern, okay, by saying that, hey, I don't want it to be observed. Come, let us do a pair chatting together in the sense like, you know, hey, this is so we actually enable a desktop where both of us put code together. And then, you know, we just ask the person to do the coding. And then we actually do a parallel coding with that person setting that he do you think that if you do it this way would it appear better. Thanks, thanks, thanks for your opportunity. Hope, and I was able to get across the message.