 All right, let's start. Thank you all for coming. And it's coming to the end of the day and third day of the conference. How many of you have been on the third day of the conference? All right, before we start, I just want to give you one of the things is I've changed the title of the talk. You've seen outside or on the publication, the convention side, it was called as Agile Coach Toolkit. At the time of putting in the paper, I felt that was more relevant. And we are talking a few tools or a few techniques and we zip through that. Over a period of time, I've been working with, as a consulting person, been working with a company. And then there were a lot of other thoughts which came in. And I thought it would be a more meaningful blend if I put in fluency, because some of the aspects of fluency was drove in into the thinking at least. We wanted to drive some of it. And instead of calling it as tools, let's look at it as techniques, which is much more relevant. And hence, I went and changed and tweaked a few things. But still, whatever tools that I mentioned in the paper, that still will be covered. So me bad, if somebody has to shoot me down, please go ahead do that. All right, how many of you are coaches here? Coach, consultant, how many of you are aspiring coaches who've done Scrum Master for some time? And you're getting into that level almost there as a coach. Wonderful. OK. So what are the key issues that you see as a coach? Just to get an understanding of any, what do you see as a key issue? Sorry? You're a troublemaker. That actually is true, right? When you go in, you want to disrupt something which is not there and then bring some sense to it. So OK. As long as you don't leave them shattered and come back. Cultural aspect, how so? Certain period of time, maybe a couple of years or even more than that, then to immediately come and try to, first the observing part becomes extremely important before you really try to bring any kind of change. And that resistance to change from working in a certain style. I've seen organizations where, working with American organizations where that kind of style was working for over 10 years. So any kind of change that you're trying to bring, there is immediately a big difference associated to it. OK. All right. All right. Good. So a bunch of these things that I'm going to share with you is an experience report, right? It's not like I say so and you do so and then you don't get the same effect. So it depends on who you are, what your personality is. At the end of the day, we also have to understand that. We will not be successful in trying to do everything that the other, we can't imitate other people. We need to have our own way of doing things, right? So this is based out of my experience over years that I've been trying. In fact, I should go back to back in my days at HCL when I transformed myself into being a consulting or a COE kind of person, morphing in myself or evolving myself into a coach consultant kind of role. And both working with the customers and also in-house with many of the teams. And there were a blend of things that I had to bring in and I had a lot of issues and problems. And some of it is on learning through those times. So it has taken some time. And eventually now I think I've got a fair degree of comfort in trying to put together wherever I go and do this. So it may not come out right for you, but then I'm sure you would have also tried similar techniques. Then we would be sharing each other's things. So please chime in wherever you've got some issues trying with some of the techniques that you are going to learn and some of the other techniques which will be interesting for others to learn. So we are okay with that, right? All right, so just to set the stage, coaching. What do you think coaching is? What do you mean by coaching? Helping others achieve their goal, okay? Helping others so that they help themselves, okay? Giving more practice. One at a time, please. Asking the right questions, okay? I think they are all fairly valid. Here is the thing from Wikipedia I got. Helping to identify the skills and the capabilities that are within the person and enabling them to use them to the best of their abilities. So I don't believe that as a coach I get in and then try to start teaching something. Yeah, there is sort of some element of it. I don't know, teaching is still good, but I don't want to be preaching. That's where we distort a lot of things, right? So there has to be balance, okay? The next aspect is role of an agile coach. This coach in general, but role of an agile coach. Much more concrete, not just by the definition, but role of an agile coach, what would you do, okay? Find it's team level, so think big. What else could happen? Sorry? Enabler, okay? Agile values, okay? Still team, okay, what else? Goals of teams, organization, management, what kind of, okay? Value addition of this methodology, okay? Change your, all right. I think there's something. So this is how I categorize them. This, obviously when we enter in as coaches, right? So we could be doing at either a team level where you instill an agile culture. You work as a change agent. You work with management to create structures in the organization in a large scale. So when you talk at an enterprise, which means that you will be talking to host of different people. It is management, it is senior leadership, and it is a team level, right? The hat that you wear is going to vary. You are not going to stop the same language while you are driving values with what you talk with management or the senior leadership is a way to what you want to talk with teams. How do you enable them versus how do you see the values from how should the management orient themselves to visualize a team is going to be different, right? All right, with that manifesto, all of us we have seen this. First of the manifesto item talks about individuals and interactions over process and tools, right? So this is where I have a challenge today. More and more I see process and tools. What happened to individuals and interactions? Lot of the coaches who get in are driving more and more processes and tools. In some form and shape. I mean training has morphed him to an extended coaching. So would that cut it, right? So rest of the things, they have value. I'm not saying that they don't have value, but I think we are losing the essence part of it. As a coach, I think it is important for me to start recognizing the value in that aspect of individual and interactions, right? So we have to pull ourselves back. As an agile community, we've come a long way, but I think we are also distorting somewhere. So I think my challenge today is with that and hence the whole pitch, why we want to focus more on that. So this is where we started. So when we started working with our customers, we said, we want to take this fluency model. I don't want to go into the details of the fluency model. How many of you were in Diana's talk keynote dancing with the fluency model day before? Okay, there's a whole lot of stuff that is already put up on the website. You can go to agilefluency.com. You will get a lot of details, right? For me, what is more important is why we went into a fluency model or what we looked at fluency from a coaching perspective. There is a whole lot of the stars, one star, two star, three star and four star, but one of the myths that, which is there are people misconstrue what the stars are to be a level gradation, which is equal to your CMMI and stuff like that, which is not the case. From a fluency perspective, it is more about the investments that you are going to put in. Investments is not just money, money per se, but it could be time, effort, how do you orient people, et cetera. So and do you want to be at a point where you want to be and how do you want to go there, right? So that's perspective. So we will lose the focus. I'll try and explain a little bit of this, what it is and what it is not, right? The rest of the details are there. Yeah, so basically when you look at it from a star perspective, what it says here is see progress from business perspective, redirect the teams when needed. So this is more about a team cultural shift, right? That is very, very important, right? To me that is important also because somewhere these individuals over these individual interactions also fit in into that context, what is the culture that I'm bringing in? It's all about mindset and culture. Agile is about that. It's not about the tool factor, right? Or the process factor. If I get this in order, maybe that will surely work out. At least my premise is that, okay? Now, agile culture shift is very important. There have been teams working on agile for a long time or practicing agile for a long time, yet you don't see making a successful product out of it or team behaviors are not kind of in the way you want, you expect it to be from a mindset or a culture perspective. It is more about regimented processes, right? I do it from a compliance checklist. If you go and look into these organizations or with the teams, you would be surprised that on a compliance list there will be probably nine or nine and a half out of 10. But when you see from an outcome, the behaviors and things like that is not somewhere coming along on those directions. So that is where I would see one star is a very important step because you want to make that culture shift first, right? The second one, second two star, it talks about shift on market cadence, capture the value frequency and reveal, you know, constructions early, et cetera, right? That is where skill shift happens. Lot of this agile world we are talking about thanks to scrum or no thanks to scrum, honestly, because it's easy to get into scrum way of doing things and call ourselves agile and lose out the entire factor of engineering part of it. I can get a head start, I can start off getting into these practices and doing some of the regiments of standards, et cetera, answering questions, but without the skill component of it, we're going to fail. And that's where we get stuck. The expected outcome or where we want to be in the agile curve so that we can start delivering without the skills will not add value, right? So at the three star level, we are trying to optimize value, right? Optimizing value is more about making excellent product decisions. That's where my product management as a component comes in. I mean, it's one thing to have a PO participate here, but then what kind of decisions are you making, right? How critical they are. So that is where organizational structure shifts happen. In many of the organization, you won't even have a one PO for one scrum team or few scrum teams available. In fact, they are distributed even in a distributed context, it's even more difficult. You have somebody, a pseudo BS sort of playing that role. There is absolutely no decision making. Now, how do you expect any amount of agile to happen? I mean, we could have it from compliance again as a structure, I can make a change by planting in one person. But the point is how effective is that person? Most of the time, organizations also in the transformation path would keep the structures in place, would put an order into the structures, but then again it's a journey. Effectiveness is more important at each of these levels, not just about creating structures. And that's an important thing to bear in mind because if we can take this fluency road, we have done exactly by this, but we are not stealing the value. Means that we need to go back and see how much is the effectiveness playing a role, right? So the last is the optimized for systems, cross pollination, prospective stimulation, innovation, optimized value stream, et cetera. This is again organization culture shift. I mean, if you look at the fluency model, there has been about less than 5% in this area, right? People are still more and more into the one-star, two-star. And people are aspiring to work somewhere through a three-star, and it takes a lot of time, right? Hopefully I've answered that, good enough, okay. So this is where these questions come. As a coach, when I enter in, I need to set the right expectations, very, very important. It's one thing to say that, you know, I would go there and try to do mentoring or I coach the teams, but then what is the management perspective to it? What's the experience? Even from a team perspective, where do you want to be? Where do you want this team to go from this perspective? It gives me a good guideline in that sense. It tells me this is where you are and this is what you want to achieve, this is what it takes. Each one takes a time frame, right? If I even want to achieve a two-star, it takes anywhere between 12 to 18 months. And that's how much time investment comes in. It's not going to be an easy shift. If you say that in two weeks, three weeks time or one month, two months, we will get it, we will achieve it, no. You probably can get an exposure towards some of these practices, et cetera, but you may not be there to do it, right? In a consistent manner, okay. Second aspect is, what investments are you ready to make, right? And the third one is what time frame are you looking at? Very critical, because sometimes let's face it. I don't need a team to go to a four-star or a three-star for the kind of work that I get or I am doing. It's valuable enough to be in one-star. In certain teams, it's valuable enough to be in two-stars, or I aspire to be in three-star because I am going to issue a product like this, but which means that I need to also put in an investment so that gradually I take that, right? So there is a commitment for that also. If I'm trying to do only sustainable engineering, support, operational activities, do I really want to do this? Or I'm working in very, very short projects, but then it is not going to be of high value. It is more about lights on. Then do I want to make that kind of an investment, right? So having that context is very important. Even suggesting where we want to go, what measures do we want to put in place so that as we go forward, we can measure these teams. Are they really getting there? Measures, when I say it is not like metric as in a metric where you can put down numbers to it, but at least are they making that progression? So making those expectations very explicit towards management or any of the teams is very important. So I think it's one of the most underplayed kind of a technique, but then we need to put that in perspective. And that is where make or break happens. I mean, we should not be shying away from the fact that we might lose this opportunity to coach because many of us are coaching and consultants, painting a wrong picture and getting in there, that would be wrong on our part. So that's where I'm very much critical on that element saying that this is what the reality is. This is what you can get, right? If it means that I have to come out early, the sooner, then it's better. I think I've done my job there, right? Many of the teams may not be even ready to start that. I may not even have the right infrastructure. I may not even have the right kind of team. So should I just go and plunk them, plunk myself in and then say, start doing this, it will get in and then we will see. No, I don't believe that. All right, so this is the key necessities. So the star as instead does not communicate any of those investment, which is what, from art kind of a twig, here are these, if you want to seek this benefit for these kind of an investment, there has to be a component of customer and also business. When I say business, the current, my business, my company and the customers whom I work, how do I engage the customers in this process across the line, across all these four stars or whatever you call as four piggy banks or whatever work, right? So it's important. Because people know now, if I'm expecting this kind of an investment, these kind of benefits, these are the things it takes along the way. I cannot sustain at going to a three star with a product owner being my, you know, conduit for giving me valuable feedback. It does not work that way. It still breaks. You need to have real, real customer coming in. Any questions? Sorry? In my experience, no. Currently in think we started off this whole thing by saying that we would probably attempt a two star. We are somewhere between one, one and a half star today. So, sorry, I don't have personally any experience to say here is a three star that I've managed to get. All right, coming to the actual techniques as such. So that's the fluency part. We want to have it to set the right expectations at all levels, right? Then we come into what is called as team norms and working agreements. How many of you have working agreements? Have heard of working agreements? What do you do in working agreements? Okay. How do you go about doing it? Are the kind of common agreement you have and you try to respect those agreement? It's decided by the team. So, here's the thing. We call it as, at least I call this four piece, right? What are these four piece? We start with people. People have goals, right? I come back to other accountable, responsible, later on, but then it is more about individual behaviors, goals, and aspirations. Everybody who's working on in companies as employees or on products have some of these, right? Next aspect is the product and what outcomes are we looking at, right? So the third component is more about understanding the current constraint, which is more about plan. What kind of successful strategies that I can put in place, right? And the fourth aspect is more about the process, the mechanics, you know, the enablers sort of. What are the things, so that if I have to succeed with my plan or the strategies that are there, how am I going to enable that, right? So if you look at it, I've kind of borrowed it from how many of you have heard of RACI? RACI matrix and traditional waterfall or whatever world, right? So there is an accountability and responsibility. It's just that, because you have to enable, in a larger context, let's face it, we still have project managers. We cannot do away with them. Project managers, functional managers, they're still relevant to the scrum teams as well. They do a whole bunch of work and bring in value. We cannot say that they're not required anymore. Decision making has to happen. Larger, I mean, any organization which is more than like 1000 people or even 500 people, you will have a structure set in. You will have to get through that hierarchy, right? So I think some of these, to have it in perspective is very important. So that is where I would have, I've called out some of the accountability aspects and some of the responsibility aspects. If you notice, most of the places, if you see, team is responsible, right? And there are certain players, when it comes to accountability, it is each of these players whose neck is on the line. Don't go and bombard a scrum team that you have to do everything when I don't give them how to do. It's not fair. What are the levers that are there which I can put in place or what are the infrastructure that I need to put in place? How do I equip them with the right skills? And I need to make those decisions. Go figure out, all the time will not lead you to outcomes and then don't blame them for it. If your strategy is, let the team go and figure out that, give them that time to come out with that and be patient about it. If nothing comes, finally you have to step in. You cannot compromise your overall goals. All those accountable, whatever is shown on this slide. Yeah, you could use that as a lever for it, but oftentimes I've seen retrospectives going stale. It's the same poor stupid questions we keep on answering and answering and nobody takes that. I mean, if we are in effective retrospective, yeah, that's a way to do that. You could do it. But what would be the forum where people will come or, because as the end of the day, the team is responsible. Yeah, I'll talk about that. How do you get to this? I'll talk about it in a minute if you can hold on. But the point is we need to have perspectives of all these three and people are central to this. But there are various, be it a retrospective, having your triage meetings, all those are necessary tools, techniques that you bring it along in the process, depending on how the context warrants it. You still will need that. But then it is not just this because this is just the perspective to say I want to drive down of all these aspects. If you want to create a structure and process within an organ in a larger context, without these elements you cannot. If you have to work with management, you need to have that perspective. At the team level, it boils down to one retrospective. So there are two aspects, there are team goals and there are release goals from outcomes and from an individual perspective. Both of them boil down to an acceptance criteria. If I achieve this, can I attain this goal? Right, from that perspective it is more about, okay if I have to do this, what are the set of agreement that I'm going to put in place? This is again collective. Some will be collective at the decision making place. You will disseminate that information coming back into the team. So as a coach you will have to be influencing, you will have to put that aspect along. So management is there ready for to do this. Given this is the thing what management aspires to do, how is it as a team that you can do? Are you equipped, et cetera? Then you will take all of these things and go into your sprints and over a period of time you will still go back and do it. At release goals, milestone goals, whatever you want to call it as. It's not just a sprint retrospective, it's an overall aspect. So you can tie it back into whatever your appraisal system and things like that, but let's not take appraisal out of context and then say I will do year-end appraisal and these are all collection agents till then. That probably will be negative. As long as I get learning opportunity, did I learn enough of it and what is that that I did a mistake and how do I correct myself? That is the most important aspect of this cycle. So having a perspective from this aspect will help us drive better working agreements. It's not just about putting a working agreement as a placeholder, it's how do you drive effectively and this should be a changing map all the time. Working agreement is changing. It's going to be a fluid document. And still you see the same behavior. What do you suggest or what's your recommendation? How to deal with those kind of tricky situations? It takes a slightly long answer. Let's see, we'll go through this course. If you have still not answered, we'll take it offline because there are multiple ways that we can handle it. Hopefully I try to answer with some of them. They get, I mean my thing is the way I want to approach is if an individual would want to go through a self-course correction that is better because I need to show him the way but not engage into a confrontation or ask him you are this and it is not helping. It's not going to benefit anybody, neither me nor him. I'm going to talk about that a little in when we go into the next technique where I can shift out these kind of things and how I've at least tried few techniques there to orient that and how people have fallen in place. I mean fallen in the places, it's in the order that their behaviors have changed because making culture shift is all about behavior changes and until I have it, I'm not going to get any agility. I might get compliance. I might be agile but I might not be driving from an agility point of view. So key considerations, why we need, this is an objective. Key objective of why we need working agreements. I needed to drive holistic factors. I mean there are a lot of things that I need to drive both from management angle, there is an outcome perspective and also keeping in mind the team's perspective, goal's aspirations, I need this, this is an objective. What should it be? It will encompass what are both of these and together collectively what we have made as decisions and how am I going to progress on this? Because this is again, let's not forget it. It's not something I am going to thrust it upon the teams. It is more a collective agreement and I'm empowering certain individuals. For example, if a scrum master has to do his responsibility and he has to go and ask a question, we are not delivering what we are supposed to deliver. In a scrum team oftentimes I've seen there is a backlash. How many of you have come across that? You are not supposed to be asking, we are a scrum team, we will take that. Scrum masters are more facilitators, you are not supposed to be asking this. How do you empower even a scrum master, right? So that is where functional managers, project managers or coaches would add that perspective. So now make this transparent. Make it occul and tell them that it is right to be asking questions because on the objective you are asking questions, not against a person. Because you have made it transparent now. This is what we all agreed on, what are we doing? It's about driving empowerment. When should we establish this? Typically it would again be again close to your release cycles. Shorter release cycles is better. Again you could do it as a release retrospective or a team retrospective at every time span. I would say every 12 weeks or one quarter max if you can keep on doing it, but at least it would take three months. Realistically to change behaviors. In our observation and also some of the study it takes about eight to 12 weeks at least to change behaviors in a person. It's not about, it's about, you're talking about individual behaviors. Whatever be your sprints, unless I change individuals behaviors, how I would. I mean it's, so you've seen most of the success stories or case studies come out of agile with experiments. Short experiment, one time I plunk it in like the Hawthorne effect, it will work. But will it work in a sustained basis that is where we lose out? Because there fundamental changes have to be made. Fundamental shifts as an individual I have to undergo. And I'm not used to it. The challenge is not only me undergoing the change, it's again as a collective unit we need to undergo a change because we need to wipe with individuals. So it takes about that time a sustained effort to do that. So who creates it? Obviously the collectively it's a team, the ownership with the, with the scrum master. Right, he would drive it, but then the point is he will become responsible for the whole thing. Bringing the people together, functional managers contribute to it or the project managers contribute into it. Everybody participates in it. We don't want to do it as individuals and then plonking it on to a team and subjecting them to follow these things. So as a coach what are your key inputs? So I do something called a deliberate practice. As team retrospectives as you mentioned, one-on-one meetings. So the way I start off is pretty much I would work with management. I will work with teams. I would do a team retrospective to understand, but oftentimes these retrospectives have been misleading. Very, very misleading. There's one thing that they say and one thing that I observe when they work. So typically when I go in the, at least ideal way I would want to start off is when they are in between a sprint so that I can observe, I can be part of them. And I don't believe working as a coach outside of a team. I embed myself along with the team and work with them on a day to day basis, morning to evening. And that is where I can get these observations. It's all about observing, looking at how teams, how individuals actually work and behave. In a constrained setting they would all come out good. When you leave them in the open it's that's where we will see certain anomalies and that is what you want to catch, right? So there should be a certain time period that you give for yourself to work with the team, understand these behaviors. And you may want to have one-on-one meetings, multiple one-on-one meetings. Here is my observation of these individuals. Have you also seen this, work with the management? You will always see, I mean, if there are convergent views then you are good. But if you are divergent views you have to go and revalidate it. And for that it takes time, you need that time. Allow yourself some time to do that. Because it's dicey to go with a divergent view and then trying to plunk in a certain thing and that process is not going to work. So it's very important that we do it. At least I want to give myself that room. So deliberative practice, I come to it because there is a separate technique section for that next section. We talk about more on deliberate practice. But again, I would want to watch their sprint execution, their business outcomes, objectives and customer satisfaction, how they are doing with that, what are their product quality? How it is really scaling well, how is this working? I mean, do they have any unit test run? Is there a daily stand up? I mean, is there daily builds going on? How often do they check in? What is that test automation thing that they have put in place? Because whatever good thing that you want to say, intent is good, but then without having these engineering aspects, it's not going to give you anything. I could be talking a lot of it, but then it's not going to give any success out of it. Before, you mentioned you need to set up the acceptance right area and then you set up the working agreement. Shouldn't it be the other way around? Yeah, so got your point. I think the reason I put up this four piece, originally I wanted to do deliberate practice first. Observe and all that, but then come to four piece. I'm not ordering it in the sequence. I'm talking it in a sequence. This is important as four piece. You need to have a perspective and for working agreements, you need these elements. But from a covering perspective, I'm doing deliberate practice later. Yes, you will need that. I mean, I'm not saying this happens in the same sequence. I could get into a team. I would do an observation, work with them from an execution perspective. I would work with management and I will be cycling through that. Yeah, true. Because I get into working agreements. Working agreements comes way longer. I mean, later. I don't even get into working rail at the outset. All of these one-on-one meetings, the observation, the sprint execution, from the sprint execution, the team retrospective. In fact, team retrospective comes after these observations one-on-one meeting deliberate practice. So I can converge on what are these convergences? What are these divergences? And then cycle through it one more time. Yeah, but these should not be like really dependent on the acceptance criteria, isn't it? Eventually when you want to set up a working agreement, you need a working acceptance criteria. How do you set up a working agreement without an acceptance criteria? These are what I'm talking about to formulate a working agreement. Here are these things that you need to go through. These are the key inputs for it. And there are management inputs. There are team inputs and your own observation, what you make out of it. And obviously as a coach, you are going there. You want to work as a change and you want to bring about a change. You are not about saying that they're all good and I'm aligning with that. Okay, right? So look out for these. I mean, when you work with teams, obviously what happens is most of the time, some of these guidelines driving are there, they're right behaviors that they are driving. Commitment, responsibility, accountability. Oftentimes you will not. You will agree on working agreement, but in execution you will see them in tangent. You will fail on those working agreements, right? So are these guidelines consistently violated? Because you have to shift back. You cannot give them three months again. So we have agreed one, let's see. Because if I don't see parity in it one to two weeks, I'm drifting away. We need to pull that back. Because as a coach, I think at least I have not had the luxury of working with teams at a really long stretch. You have to make certain progress in a relatively short amount of time. So it's okay to call out but ensure that this is done without breaking safety and trust. That's the most important element. See, it's not about saying that you are doing it wrong, but are you hurting that individual in the process of saying so. How you say and how you work with individuals matters a lot. There could be key influencers that you want to have a one-on-one to call it out, not in front of the team. But certain times you want to call it out in front of the team just to make it obvious and so that you get some traction. So again, context matters. Again, you will have to experiment it a little bit as to how it works and it also depends on your personality. How you will blend with that. So that's most important. I mean, I would not be able to experience you will probably have to look at it from your sense and get those inputs and slowly mature your way of engaging with team individuals rather than taking it as a recipe as to how he does it. Matrix. In some extent, again, it depends on the attitude of individuals. In a matrix, I know if I am reporting to some other people and I have nothing to hear, no matter what I say, I'm not going to bring that parity. Especially if they are like, I don't care what you are saying. And I'm like the big thing. I've been here for a long time. I've seen this as fads multiple times. You don't get. But if you are working in a co-located team and again, same thing can happen here. But it is relatively easy because you are working with the same management who's going to control. Both ways, right? I think the important factor is, are there right attitudes? It doesn't matter whether it is project in this because ultimately I can say, I will say yes to it, but then not work on it. It's equally a bad result. All right. So the next practice is deliberate practice. This is more about practicing software craftsmanship. I believe that we need to get into this mode of mentality of engineering excellence. We need to have engineering excellence without which I think as agile teams we will fail. I've seen empty number of times where people take on to scrum and start doing it and it becomes a mechanical thing. We get up early, come back, do the standup, answer those three stupid questions and then get no outcomes. It's the same rigmarole time and time and game. There's no value. In fact, it gets frustrating. I don't know how many of you have felt it, but at least I have felt attending standups, answering those three questions or even those retrospectives is annoying. In fact, I've advocated moving away from answering those questions, rather answer on, let's understand what is the learning that we've got? What are the outcomes? Are there any issues instead of answering that three regimented questions? So this is basically the experience that I got was I attended the first code read back in 2010, 2011, and it was in Mumbai when Venkat Subramanian did it. I was not a quote unquote developer or I was more about management. I've come from a development background myself. I've done a lot of coding. Not that I'm alien to it, but as you go along the curve somewhere you would have left that and you have to get back into it. I think it is important that we as coaches also are relevant. We also understand the developer aspect of it, how developer thinks and to stay relevant we also have to dabble ourselves into code time to time, right? So this was the opportunity back in 2010 or 11 I think, if I'm not wrong. And this deliberate practice is all about Kori, how many of you have heard of code retreats or participated in code retreats? Two, three, awesome, right? So it's a whole day of software craftsmanship building. So all of us get together, we do at least about six to seven iterations in a day, 45 minute iterations, where you work on the same problem all through the day with different perspective. The idea of the code retreat is not to find a solution for the problem, it is more about the approaches to the problem. What are the different approaches you can take? And it really tests out individuals. And the important thing is why we get together there is to improve ourselves from where we are. Here is one way of solving a problem, but then there is another way. So what is the best way to do? Is this a better object oriented way? And do I need object orientation at all? What are those key, and that is what kicks drives agility, right? I would be scared if there is only one solution to a problem. I don't know about you, but then I'll be scared. There should be multiple options at least to put it on the table and that is where you make effective planning. The decision that as a team you can take, here are different possibilities to solve this problem, but this is what it takes to do and is that what you want to do? That is what you want to be discussing in planning sessions. Not about saying here is a functional, this is a thing, we have put a number, this is the velocity and you come out all days and ends up okay, this is something which we could not do and we push it into an experiment. Perpetually get trapped into that. We don't want to do that. We want to hone our skills time and time again and this if we do it repetitively, it is healthy. Right? So Convay actually did this and it's become a worldwide thing. In fact, there is a particular day today, also it happens that every day, on that particular day all over the globe, there is a code retreat. Many organizations have taken to it. At least I have tried within HCL couple of times where we could do it in certain teams at least, if not as a whole, right? It has helped me and I've been at least to two or three code retreats which are there, which have happened so far, right? And that has given me a lot of learning and then I said, if this has helped me, why can't I take this from a coaching perspective, get it into the teams? I don't have to, because teams, people are smart because if they have been hired into this company and we are in working in IT, they are fairly smart individuals. At least I go with that belief. I don't want to say that you are dumb and I will help you. That's not the way we would work. They are fairly smart, you could do it. They may not know what exactly is a test-driven way, but I would, in this kind of an experience, you would know in a relatively short time, what is unit testing? Can I even attempt unit testing? These are all in a short part of time, without failing, you could actually fail in a safe manner. You would learn from individuals. You would be pair programming all through the day and it doesn't matter who is it, it need not be a developer, just a tester or anybody, including a strong master project manager. Right, and it's a beautiful way of getting the team started. In fact, the key objective from a participant perspective is about holding technical skills, the development skills. From time to time, this is very important to stay relevant, because they have to be relevant in the industry also, not just in the project context. Doing Java, what we did in 2001 and trying to do Java now also doesn't mean the same. Right, improving self-organizing abilities, because oftentimes I've seen certain people will hesitate to work with certain individuals. There are a lot of misconceptions. I don't like a certain individual. I can't work, but you are enforcing them to do pair program. What pairing will you do? I don't even know that, what are the abilities of that person? How do I bring that element? How do I understand that first of all? I cannot say this person is good and I can't babysit that, because they're all adults. They themselves have to figure out, yeah, I think I had a wrong notion of this guy, but now after pairing this, I thought I got a different perspective. I could also do it and I could learn from something. How do I create that safe environment for him? I think this is a fabulous way of doing it. I would sacrifice one day before we start off a release. It is much, much more effective than doing a stupid team bonding exercise at off-site. Seriously. In fact, I've had problems with all this team bonding exercise because whatever is the leftover budget, they will plonk it into team bonding at the end of the year. So instead of that, let me give you one day's worth of time, don't ask us anything, we'll go and huddle ourselves, do this thing. So as a coach, there are some key objectives. I am more interested in this. I mean, my true intent is to bring a qualitative change in the people who are participating in it. No doubt about it. But then, mind you that we are all, I'm also starting off this journey to transform as a coach. My key objectives are, how do I understand the team dynamics? How good are you? They will all say we are all very good. We are a very nice bonding team. But we do check-ins only once in a month. We hesitate. We can't take his work. He has done some work. How do I know some of these elements? There are good influencers, there are bad influencers. So how do I shift this out? So this is an observation period for me in a constrained environment, in that environment. While they are learning, I'm actually observing these things. How good is your test automation case? How good is your engineering capabilities? Do you do test-driven? Do you know about test-driven? Surprisingly, so far, many people who have not known test-driven have understood test-driven in that one day. In fact, we have downloaded unit test frameworks in that 45-minute time frame and at least done a Hello World TDD, which is lot better than paying some consultant or a training agent to come indoors and say, give me dole out $1,000 and I will do TDD for you. At the end of the day, you would have still done Hello World. You don't require it, right? Observe key behaviors of individuals, understand cross-functional abilities of them, communication problems, if any, because that is critical. And I think this is much more a challenge in working in India. I mean, don't get me wrong. We are much more a diverse nation. In a team, I will have somebody speaking Malayalam, somebody speaking Telugu, and somebody says, I don't, they actually do a great stand-up have they been speaking in their own respective language. But their communication becomes lot more challenging when you put them and you have to speak in that language where I don't, I'm not that proficient in. So I need to understand these aspects as well. How do I blend that? If I pair these wrong sets of people, I cannot get it up. And I cannot even point it out, this is your problem because you can't even surface. You have to figure out that. So what do I need to understand? All of these aspects, right? But much more is how, as a team, they actually behave. How would they come together to solving a problem? All of this is fine at the higher level, it's fine. But given that there is a goal objective, am I actually solving this? What is it that the approaches that I take, right? So many a times I've seen some of these aspects which kick in. These are my observations. Participation people are very, very skeptical. I mean, this is kind of high contrast to my experience participating in code retrieves. When I've gone into code retrieves, people are all angry on the edge. They want to participate because they have come with a purpose that I want to learn and take away something. But when you do it from a coaching or an organizational construct, it is an imposed thing on them. They don't know what it is. I mean, they come with all skepticism. They don't want to participate. They are very rigid about it, right? They don't want to learn and experiment because that is the time they get exposed. Let's face it, all of us want to look good, right? When you put in this kind of an environment, in fact, this is much more common with seniors versus the pressures. Pressures are more open towards experimenting. There are a lot of the seniors who have created their place and then saying that I'm good, but then ultimately when it comes, I'm failing. That's hard to take. But then this is an environment where you give, okay, this is where we are learning, not in terms of exposing those. So did that answer a part of it? If they realize that, yeah, I have got something to learn here which I had not done in my last eight to 10 years, that's a huge revelation for them. And that message that you send out is also a good thing for other juniors who are there because they now bond much very well with that senior. They never look at him as a senior junior. They know that, okay, I can also do something here. That's very important. And I think this is much better than actually going into conference rooms and talking to them. Individual experiences, especially the tech leads. How many of you have had challenges with the tech leads and architects in an agile transformation? For me, the biggest challenge has always been the project managers and the technical architects. I mean, including myself. I mean, I could not accept this discipline earlier on because of that mindset. All right, so passive pairing. People generally set. You know, there is a certain drawback because this is not something that you want to take because now what do I put in? So how do I monitor them, measure them, things like that? You would want to set up your working agreements with these things. If the team has got absolutely no exposure to this, having a high expectation in your working agreements, you want to attain daily checking. I mean, it should be every 45 minute, one hour kind of a check-in rate is not going to happen. It has to be realistic. Uncomfortable pairing with certain people. You will often see similar designs. Nobody wants to challenge on those designs. It's the same thing. Morning to evening, it's the same thing. Six iterations, it's exactly the same design. The key influencer, he started out with this design wherever he has paired, at the end of the day, you will exactly see the same type of code. Oh, I forgot. As part of this code retreat, one of the practices is that we drop the code at every 45 minute iterations. We do a retrospective every 45 minute, but before we do the retrospective, we delete code. You are going to start off on a clean slate every single iteration. That's the challenge. And you impose constraints. It's not that you have to cross all the code in a different way. You, as a coach who was standing there, you will impose constraints based on these things. Many of the times I don't see, so one of the techniques is, one of the things that I try and do is, if people don't unit test it, I, by the time of the second or the third iteration, I would say you need to have a definite unit test. I don't care whether you do it in a TDD fashion or you do it as a later part of unit test. But there has to be a unit test to solve this, to tell me that. I will not accept the fact that this is working just because you say so, right? Slowly I shift them around into a further iteration to say that now that you have understood unit test, try to do it in TDD, mandatory TDD. If you have not understood a particular framework, go Google and get that. As a pair, see what you can do. In fact, results have been astounding. In that 40, while they have actually taken whole lot of initiatives to learn TDD over years, in this 45 minutes, they were actually been able to do download unit test frameworks and actually test that out. And get a comfort feel, yeah, this is no big deal, we can go back. It's so much to say that in a mainframe context, we've been able to achieve this, no big deal. We would get that. It's about building that safety net where they can fail and learn. Any questions? So here are some of the experiences. This is what teams have actually felt. This is not mine, it's there. I've taken literal comments from what people have felt. Scaling agile, there's a lot of talk on frameworks and stuff like that on scaling agile, right? My school of thought is if we have a good learning organization, we should be able to scale well. It's not about the processes or the frameworks that we put in place. So how do we go about enabling this? What's a learning organization? Anybody? What's a learning organization? Open to change. I'm slightly running late, but I might need five more minutes, is that okay? I might need five more minutes more than the session. So basically this is what Peter Singh just said in fifth discipline, field book. How many of you have come across this? Learning in organization means the continuous testing of experiences and the transformation of the experience into knowledge accessible to the whole organization relevant to the core purpose. So that's what we want to strike a chord on. Because let's accept the fact that I don't know how much, what is your experience? There cannot be one way of doing agile. Each team is differing. Each will have contextual practices, experiences, right? For some team what works and the other team it doesn't work. Is that your experience too? How many of you have that experience? Yeah? So in that, is it fair to say that I need to have cross-pollination amongst individuals? Five more minutes. As for five more minutes, I'll do that. So we do brownback sessions. Brownback sessions is basically, you create community of practitioners and to enable peer learning, but it happens during lunch hours. Organization doesn't have to put in time or effort or money into it. As communities, we come together and do it. So what we have done is we've created forums for product owners, crumb masters, and the functional manager components, all of these roles specifically to participate and we do it on a weekly basis. Every week, particular days, for that one hour, we share experiences. And we validate whether this works for me or not and I've cross-pollinated like that. So people have taken experiences, it's not work, they come back into it. So basically about sharing their team coaching outcomes. As a coach, this is more relevant because how do you want to do that? How do you want to enforce? How do you want to see that there is a sustainable change? Not just for this team, but for other teams. Things can go wrong here. In fact, we've been horrible in this, at least in my experience, some of these things have been shot down. I mean, intent is good, they have all bought in, but there are various organizational constraints where it has not happened, right? Everybody buys the fact that, yes, it is important, but the point is they are unable to commit for it. So as a community, we will not be able to grow. So the point is it's more difficult to groom, to grow communities of interest rather than putting placeholders and things like that. Placeholders in itself will have no value, okay? So this, we've failed, but then at least, it is still on, hopefully we will succeed. So key measures, I'll quickly run through them. What are the motivators enduring self-organization? Important thing is progression increases motivation. That's a firm belief in which I operate on, right? So which is why you need those tools. But when you look at it from a two, we have two key measures for network, where people actually put the dot on a day, every day basis, did they have for network as they complete the day, right? And they also see work accomplishment. How much did I accomplish on a daily? These are the four quadrants that we have versus, I mean, if you look at it versus no fun to loving it towards accomplishment where none at all to awesome work that I did, I'm done, minute I'm done. So these are the four different things and this helps us to do continuous retrospective. And it also means that functional managers and scrum masters have something to challenge upon themselves if you see people are in no fun and none at all on a consistent basis. More they are towards that end, towards the right corner, you are better off. The simplistic measures, we should be able to make good progress. And we do it on every single day, through the weeks, at least for some time, till you sustain, almost done. So there is no one size fits all. Essentially, you will have to experiment with your own ways. At least these are food for thought you could take in into your own coaching experiments. And all right, so I can take some questions till they set up. But hopefully if you have any more questions, I could take them or we could have the hallway. But hopefully these were four or five practices that are there as techniques that you could implement in your own coaching assignments.