 And so this presentation is more like a MVP, minimum viable presentation. So the topic is how do you lay a strong foundation for a gel transformation based on an experience for a particular client and yeah there are lot of things to speak about it but I will try to speak the minimum. I try to close before 20 minutes so that you can extract information from me by asking questions. So let's make it interactive but for the first 10-12 minutes for maximum 15 minutes I already set my time. You will hear a alarm now at 12.45 then I will speed up and then give time for questions. So this is basically an experience report presentation, am I audible? So I am Gopinath, I am an independent consultant and yeah I have been in this process improvement field for the last 18 years and prior to that I was also in development and project management and all this stuff. If you want to know more about me, information is available there so I am not going to talk too much about myself, I rather talk about my work. The client in the question, these are some details about the client with whom I was engaged for a gel transformation exercise. And these were the five steps which we took to effectively initiate an agile transformation. Now agile transformation initiation is one of the most crucial things and it's directly the success of any agile transformation depends upon how well it has been initiated. And these are the five steps which we took. Now I am not making a very tall claim that these five are the best possible thing and this will work everywhere. No, I am not really making a tall claim, all I am telling is what work for this client and it has also worked for me in couple of places. And this is an experience report presentation, that's all, I am not going to make any, what work for me, that's what I am going to talk about. First thing, setting the sponsors' expectations right. Now you must be aware that many of the organizations get interested in agile without really understanding what it is involved in agile transformation. In what are the, what do they need to sustain the agile transformation effectively. And many a case, agile may not be the right solution for your organization. It all depends upon the business you operate in, your work culture, your organization structure, so many things comes into picture. And that's why it's a moral responsibility of any consultant or a coach to make the sponsors aware of these risks in an agile moment. So the first step which I took was setting the sponsors' expectations right. So the very first question was, when we discussed, why are you going for agile transformation? What is so bad about the current situation? When I first talked to them, I really didn't find why they should go for agile. What business problem are you trying to solve? So these are the things which we discussed. During the discussion it came out that what client wanted was, he said he's an innovation space and he wants a very quick, innovative, iterative solutions in the market so that they can remain complete. This is instantly more than a 40-year-old company, so they are well-steep in waterfall culture as I was showing in the previous slide. Now that struck me as something which is, yes, client has got certain real reason to explore the agile person. Even then I didn't say that let's go for agile, I said okay, understood. Now let's try out agile as an experiment in your organization. Now having set these sponsors, there's one more thing about agile transformation is not going to be an easy one, it's going to be hard. And it's not the matter of just changing the work cycle, the life cycle, it also means changing your work culture, your engineering practices or probably even your organization structure. And one more thing which I pointed out to the client is you can generally expect a drop in the productivity, rather the perceived productivity of your people when you start implementing agile. And you should be prepared for all these things. And for that we need to get a bind from the leadership team and that was the next step. How do you get the bind? Have you set the sponsors' expectations and how do you get the bind? So for that, the leadership needs to understand what exactly agile involves. For me, agile is not daily stand-up meeting or sprint planning meeting or retrospective. For me, agile is how well we live up to values and things. So even before we commit to the agile transformation, let us see what does this values and principles say first, understand that and then take a call whether it's applicable to your organization or not. And that's what I told them. And we had a one-day workshop where the sponsor and the entire first-level management, which you will directly report into the MD, participated in that workshop. And they are discussed each and every agile values and principles. And during this course of exercise, we did a small exercise. I'm not going to get into details of this exercise. Only a business expectations they came out with. What exactly you are expecting from this agile transformation exercise? And they listed out the business expectations. And then each and every principle, they discussed and said, okay, does this principle make sense to meet our business goals? If yes, okay. If no, why not? So I didn't say that you have to implement all the principles, you have to make the people self-organizing. No, we are not even getting into agile while taking a decision whether to go for agile or not. We are just seeing whether agile suits are business or not. And instantly it so happened that each and every principle was found to be relevant in their business plan. And then they started discussing, okay, if this is the principle, but there are a lot of constraints, of course, are we living up to these principles? These were the questions people are asking themselves. If we are not living up to this principle, what else we need to do to live up to this principle? And that's where the buying came in. It was a full day exercise. And finally, everybody felt, yes, now we should at least explore agile and see how it happens, okay. That is the story of the leadership team. But usually in the organization, there is always a big gap between what the leadership says. See, what I'm trying to approach is I was approaching this organization as an almost a novice person. I don't know anything about the organization. So I'm assuming that there's going to be a major gap between what leadership thinks and what is the situation exactly in the trenches. So we need to find out where the real work happens, what we call as jamba. We have to go to the jamba and see what happens there. And there, that's where we come to the third step, assess the current scenario. Now we need to see how the projects are getting executed, how the product is getting developed. So what we did was we used this comparative agility framework. It is a freely available framework developed by two well-respected agile gurus, Mike Kohn and Ken Rubin. But we heavily customized this. The idea is to, they are listed a lot of practices and they're classified into several heads. Our customization was take those practices, maybe change here and there to suit the organization culture. Like for example, couple of things that are straight away deleted, do we have daily stand up meetings? I didn't remove the practice itself, because I know it's not going, it's not happening. They're entirely new to agile. So there's no point in keeping. So like that customization went on. And also these parameters are mapping to, sorry, the practices are mapping into certain parameters. So there are total 38 practices and these were the seven parameters which were assessed in the initials. And how do we get inputs for these two things? One is a release retrospect, another one is a survey. Now release retrospective, we had three sessions covering various cross-sectional people, but one session was typically the idea, the potential pilot project, and the second session was people from other projects and third was exclusively for line and project managers. And they kept this, it was a structured retrospective, they kept all these seven stuff in front and then did the usual retrospective which happens, what went right, what is going right, what didn't go well, what can we do to improve in the previous, we kept the scope to the previous. That was one, I facilitated those retrospectives and that was one input and another input was a survey questionnaire which was based on the comparative agility framework. So but here I didn't even say that these are agile practices, I said this is a situation. Now you tell me how close is your project is to the given situation, whoever participated in the retrospective, they all responded to this question. So you have to, this is just an example, parameters team work has got four practices associated with it. They have to say how close your project is to the given situation, very far, so like that the rated and the parameter average comes from, the parameter rating comes from average of this four times. This is just a sample and these practices are taken from that agility assessment framework which I just showed. And the two pilot candidate projects were taken, they got this ratings in a spider chart, roughly in the scale of five they were between three to 3.5, that was the baseline. The purpose of the assessment is not only to compare the practices but there has got one more agenda, one is to quantitatively know where you stand, what we call as the baseline. And probably the most important thing is to surface, are there any critical people issues coming into this organization because if certain basic hygiene factors are not satisfied in an organization, people issues, like I am not happy with my salary, my salary is not coming on time, my, sorry, I am not happy with my boss, I do not have a chair to sit one place where I was coaching, if I leave my seat for five minutes my seat will be pulled off, I will not get my seat. So such hygiene factors are not satisfied in an organization. I would say that there is no point in starting a agile journey also, first set these things right and then because agile is discipline and micromanagement, micromanagement not by the managers but self-management and also discipline. So unless you have this hygiene factor satisfied, how are you going to do agile, it is going to backfire, it is better that you are being the existing waterfall model, probably that would be better in such situation. But fortunately no such critical issues surface and we decided, okay, it is time to start the pilots but of course every organization has got certain weaknesses. So these are some of the practices which were requiring attention in the organization. This is basically 7, 8, what I had to picked up was there are certain responses which are rated as far or very far from the given agile plan and the figures in the bracket indicate how many percentage of the people indicated that as a practice which need attention, 3 to 3.5 that is a parameter by average of team member feedback and also for the pilot project and also the practices associated with the parameters, sorry, yeah, so average and put it in the private, right, right, yeah, I will come to that and let me finish this presentation because I want to finish it early and so that I can take your questions. So and one more thing is we had assured confidentiality in the retrospectives and also given option to respond anonymously. So I hope that people responded honestly and even I have, when you go to an organization with your experience you can just feel the atmosphere surrounding the organization and can make out especially if you are being doing this for your burden but you generally get an intuitive feeling that whether this organization is okay or not, you will get a good or bad vibes and fortunately I didn't get any bad vibes in the organization so it was good enough to start. It was not perfect but it was good enough to start and that's where we need to start train and coach the pilot projects. So we chose two pilot projects which was again with the discussion of the people and the management what would be the, and so what I ensured was the pilot should be non-trivial, it should not be some hobby project type of project, it should be having some, it's a real life project it should be. And as I said it was a functional organization so we need to co-locate the developers and testers so that we made it co-located and give them the best possible working conditions which they can. Some people will say that no, no you should work with the reality and then find out. That's one thought but my other thought is given the best situation what results that the team can show. That will be a demonstration proof of concept. Therefore we did that and also we chose framework which was derived from Scrum but not Scrum. It's a Scrum but you can say but I don't care whether it's a Scrum but or Scrum derived or pure Scrum. For me for us rather that's the message I was trying to come. Our goal is not to become agile, our goal is to become effective in our business and for that whatever means are there even if it's a waterfall it's okay for us. So that's why we didn't hang out too much on this Scrum, we derived a lot of good things from Scrum but certain things, especially we retained the events and practice ceremonies but we didn't use the Scrum rules but at the same time we should respect Scrum also. So if you are deviating from Scrum we should not say that we are doing Scrum. We may be doing something so let us not change what is pure Scrum and call it Scrum. So that level of ethics we need to have. And then yeah so we after that before we started the pilot we had a training for the pilot teams. We had one day session for again on agile values and principles and the framework what we are going to use. We are not the full distance but more importantly we had two more trainings. One was teamwork, short sessions not two extended teamwork and role of managers in an agile world. This is to ensure that the managers don't get into command and control mode when the propellant is in progress and secondly the team should understand at least the basic concepts of how a teamwork should be done. So with that intention we had two short workshops for but then we didn't have workshops at a stretch okay three days from training after that you do work. No what I believed was just in time bite size training. So before the Scrum starts the sprint starts we have a two day release planning session. First a little bit of slide presentation and some exercise at training and then do your actual release planning work. Similarly just before the sprint planning after they gave a gap of some days for them to form up the release plans and then we started the sprint one. When we started the sprint one just before that sprint planning training. And we were using the real life work products. What simulated games and exercises we are not playing games there we are really using our work products. Games have their place in public courses where it's impossible to have your real life work products in the process in the training but when you are training somebody in their own offices I would prefer to use them to use their own life work life. What they use in their real life. And then we yeah so that's how the trainings were given and I was observing the sprint one where I did the facilitation. But the sprint two onwards sprint two and three handed over to the people who were supposed to facilitate whereas I went into the role of a more of a coach. Where our focus was to see whether there is a teamwork is being done whether they are following the agile mindset and the ceremonies the focus was only on these three as far as my coaching was concerned. And then after that six weeks three sprints we have to tell what has how from has affected no sorry sorry for using the word from it was not from how the agile way of working has impacted the pilot teams. So for that we had another server this was the same survey same set of questions for both parameter level and the practice level but the question was slightly different now instead of telling how far you are from the current situation from the given situation our question was ever since you worked in agile way of working has certain things become better or worse or remains the same. So we used only one metric to measure the impact one type of how many people said that situation has become better that was our metric to get the impact of agile way of working on the pilot projects. And these are the results of how the perceived impact of agile on different parameters okay just to there are different types of people some people like to see graphs and some people like to see figures this is for the people who are more inclined towards pictures and the same data is projected to the people who are more inclined towards numbers. So these are the parameters and you would see that 100% of the responses said that our requirements architecture and design project planning and monitoring the continuous improvement culture is better over the last six weeks. It is only a six weeks results and you can still see teamwork and product quality are also ranking pretty high then if you remember I had pointed out certain practices which were rated as far from the given situation that means they are not agile okay this is the I am not expecting to read everything this is the way we classified all the practices if you are more than 80% responses are saying better we put it in one column 60 to 80 another column less than 60 other column do not bother to read it I am just going to give this one line result summary of this that 40% of the 38 practices rated by rated as better in the post pilot survey by more than 80% of the respondents. So that is the impact that is why we could measure the impact what agile way of working is creating in the pilot projects okay now let us come to the practices which were rated slightly on the lower side in the pre pilot survey yeah the same results in terms of numbers everybody agreed that visibility of the progress is now much much better 100% unanimous tester getting involved is also very high earlier they were working in silos now they are really appreciating that okay developer and testers are sitting together and working team behavior is getting an interest so like that these were the things even the lower responses are actually they are better response 36% said that technical that is better but let us focus on what has happened what was the strong points okay so I am almost coming to an end of the my MVP that is minimum viable presentation and so your question will be so all these results were presented to the sponsor and the leadership team and even the pilot projects and the decision was yes agile way of working is helping us so now let us bring eight more projects into the agile purview what I am talking about here in this presentation is not the complete transformation journey still goes on I am just talking about how well you initiate a transformation we are still in early stage there are a lot of things then again my involvement is not their full time I am not a full time coach there after this pilot my involvement become less I focus started focusing on other projects not on the project which did the pilot so it's always a danger that it might slip back to the older ways of working so for the eight projects which we took up we followed a similar projects and they went to the same cycle what I described for this particular but we also took a survey off for almost one year on the pilot projects how things are impacting this now this time we made the survey a little bit more cover a little bit more ground we did some more customization we now we evaluated some 11 parameters and this is the results after one year the same product I am not told you all the information here I am expecting the questions will answer that so this was the impact which was created in the same project after one year so that finishes my presentation now you can ask questions or you can go for early lunch sorry so far yeah okay yeah very good question because unless you improve your engineering practices you cannot take full benefit of project and this particular organization they were following certain practices and many organization takes a different route some people want to improve their project management practices some people want to some of this organization was they felt that okay there are other dependencies for engineering practices they are not scope much scope of improvement so we focused on the management and other process part of it but every time I have been stressing that agile will take this all these things will take you only at a certain level if you have to go further in the agility scale you have to improve your engineering practice like test automation then breaking down vertical slices so those are the things and try to finish all the stories but then it's a company's choice your goal is not to become agile your goal is to get the business results so if you're comfortable with a certain level of practices and it's working well for you whom I could force them but at least I made my opinion and my share the best practices sorry best practices again a wrong one but a good practices way industry that okay without engineering practices agile can go only a certain level to get the maximum benefit of agile you need to improve but if you still see there are 33 percent people are still saying it's better okay this is all survey so there is no we didn't introduce the velocity and those concepts because it is just their perception and so we say that product is yeah the what has happened is yeah I'm coming to the issues the people felt that the productivity was reducing so at least the product manager they felt the productivity was reducing and that I had already been stressed with the fact that your productivity might drop but then that productivity sort of a perceived productivity because developer does something it works on a machine oh you're productive but it was not been tested so that was taking time and that was giving a perception that people are not productive but after three months that release cycle they felt okay though though that time we felt that we're not productive but we are actually more productive that's what the senior manager said that yeah initially felt that we're not productive but now we are but still that is still there is a scope of improvements not that it is fully productive okay I think time is some of my alarm didn't ring thanks