 There was a good group there who did not raise their hands, sorry, it is just late to raise the hand. Any agile coaches here? Okay, a few. Okay. How many people who are not agile coaches here? Yeah, okay, more. Good, so all the people who raised their hands are the people I am doing this for, talking about my experience of how I used to be just an agile practitioner, but circumstances led me to taking up the agile coaching role. In fact, it's probably something that you guys will run into pretty soon. I'm sure some of you are starting off just on your agile journey, but soon you'll see that, oh, it works. Let's try it out some more. You start with one team, and then you see, oh, it's working for us. Some other teams in our organization want to try it out as well. Now what do we do? One approach could be you get some external coaches and spread them across multiple teams. There's a good chance that that model will not scale. I mean, how many external coaches will you get? How many can you afford? Plus it will not sustain, right? Soon you'll have to look at practitioners taking on the role of agile coaches. Maybe not permanently, maybe on a rotation basis. I definitely hope to be an agile coach on a rotation basis. I would like to go back to a delivery project and be a practitioner as well. So I think it's almost time we can start. So I've already set the premise here. So from an individual perspective, there are reasons that you would like to try coaching away from just a practitioner, being just a practitioner on an agile team. Maybe I'll share some of my motivations soon. And from an organization perspective, this is again a topic that you have to look at just from a scaling perspective, scaling agile coaching in your organization. So there's an alternate slide, title slide, which is this one. How I got to be from that person to that person. And what's the difference between the two pictures? Anyone can guess? Okay, I became black and white. I became very uni-mediate dimensional, monotonous. When do you think this picture was taken? Okay, so maybe this was like six, seven years back. So good guess. Almost a fresher there, starting off on my agile journey as a practitioner. When was that taken? Yesterday? Okay, a few months back. I was hoping for a different answer where people will not be able to tell, because some people do say I still look very young. So I was hoping you would say, oh, they are just taken very close by. But yes, I did become black and white. Or this title could be not from practitioner to coach, but who stole Aman's smile? Yeah? Okay. But the question is what to expect. I'm just joking here. It's not about who stole my smile. It is about my stories, not user stories, but personal stories about my first agile coaching gig, which I did a couple of years back. And my personal experience is using some coaching techniques that I discovered. I'll be sharing a few of that. It's again a short presentation, just 20 minutes. So there's more to say. Do visit these links to get more details. Every experience report in this agile conference has a backing document. I have a five-page document which is uploaded to the Agile India website. I suggest you read that. So talking about my story, right? So once upon a time, I was a happy developer. I was a happy agile developer. These are some of the things I used to do, right? Typical stuff as a developer. Things that you make you happy in an agile team. TDD, refactoring, pair programming, stand-ups, something that didn't make us happy, velocity charts, story points, estimations, and lots and lots of coffee. Who here likes coffee? Good. I'm a big coffee addict. Some of you know that already. And I did this for many years, right? Year after year, project after project. Thankfully, mostly successful deliveries, some unsuccessful. After a point, I was almost about to roll off a project, and I thought I'll take a break. I'll go to the beach. At ThoughtWorks, we call waiting for a project being on the beach. Some people call it bench, right? But I was literally thinking of going to a beach. Sadly, who's the villain in such a situation? The boss, or in particular, the staffing manager, right? And the staffing manager comes over and tells me, dude, so we have an agile enablement coming up, and we need you starting one day to play the role of a coach. And I was like, okay, how does that involve, right? I've never thought of coaching before. And he's like, don't worry, don't worry. You've been this really great agile practitioner for all these years in our company, right? We have full confidence that you will be able to just help other teams do the same thing that you do. I make sure it sounds reasonable. I mean, I've worked with new hires in my company, juniors as well as lateral. So maybe I'll give this a shot. Anyway, it's been the same thing again and again while it's fun. It's nice to take a break from delivery as well. It does become repetitive after time. I mean, how many stand-ups do you want to attend in your lifetime, right? So yeah, I signed up for it very happily. And I was all enthusiastic of playing coach for the first time, right? And so what did I do as a coach in this team that I joined? I did TDD. I did pay for having, I did stand-ups. I helped people with velocity charts, helped them with estimation, and drank a lot and a lot of coffee, I was drinking before. The only difference being I was working with teams who were not perhaps as experienced as my colleagues that I had been working with. But that's okay. It's still the same stuff I was doing. So what did you think that led me to confusion? What am I doing with the team, right? Am I doing the coach role right? Is this what a coach is supposed to do? Do the same thing that agile developer does? Just help others explain to them, teach them how to do it? I had a lot of questions. Sadly, I was not able to get answers to them. And when questions don't lead to answers, they lead to frustration, yes? And I went through these moments where I was frustrated, partly with myself and partly with the inability of certain people to get me support because I'd ask for support, I would ask for answers and no one would give me answers, right? And frustration after a point, sorry, frustration after a point led to a boredom. Because sure, I was doing what I knew, which was being a good agile developer with this team and helping them on, but I was starting to get bored. I still felt that there's probably more to this coach role, right? Thankfully, thankfully I said this is enough. Let's figure this out. And I reached out to more colleagues of mine. I used my network, people who had done coaching before, and they were starting to give me answers. And then finally that started becoming, sorry, started becoming interesting. So they would answer my queries. They would give suggestions. They would give advice. Best thing, they would point me to articles or books to read. One of the resources was the Agile Coaching Institute that a colleague of mine mentioned later in my transition. But you know what helped the most was just looking around me. Sure, I was being a good agile developer with these people who had not experienced Agile before, but those people themselves were enough to tell me what a coach role is about. Because they were excited about a few things that I would introduce to them. They would have a lot of questions. And with my encouragement they were able to try things on their own. So there was progress that the team started making and they would give a lot of that credit to me. That's when I hit a Nirvana point. I started realizing at least one takeaway, which was earlier my focus was in this priority order. First software, writing good software, writing your business value for your clients, releasing good software out, doing TDD, good code base. So software was primary for me. Second was team, working well in a collaborative environment with the team. Are you being efficient as a team? And finally, individuals, maybe. The few people that I would mentor here and there. This was part of my day-to-day job. But I soon realized that a coach has to reverse that priority order. You have to find the individuals around you. Help them improve, help them on their journey. Help them discover their strengths. That will sort out the team issue on its own. But again, get the team to gel together. And you know what, that will do something magical to your software. A lot of good quality stuff will come out automatically. Almost automatically. Today I have this definition of coaching. It's always evolving. But this is my definition of coaching. It's about getting the most of individuals and teams by raising their awareness levels about the current environment, the environment outside theirs, and most important of all, their own potential. Because it's not like the people I was working with were not smart. It's not like they were dumb. It's just about are they realizing what status codes they are in? Are they challenging it? Do they have enough exposure to the practices happening outside in the industry? Outside their team, in another team, within the organization, outside the organization, are they attending conferences like these, right? Just helping them with that exposure. And then figuring out their strengths and making sure that they use that to their best ability. But you need a model, you need a structure. This is a simplified coaching model that helped me on that first gig. And in a lot of subsequent gigs. It's basically where you spend some initial time in an assessment period trying to gauge, be sure not to give out advice right at the start. This is about understanding their context. Then you figure out how you want to go about active coaching. And finally, you want to leave the team in a sustainance level where you become redundant. You can walk away. You create a space for the team members to step up on their own. And these will have some coaching techniques which I tried. I'll share some of those here. During assessment, it's basically a two to three period. Maybe it could go on for a week. A good way to start is to interview the team members of your team. If it's a large team, then maybe you can't cover everyone, but get a good representative sample. Try to understand what their background is, what role do they play, what processes do they follow, and most importantly, what challenges do they face. Yes. All that information that you gather, you can start mapping visually as a process. That will lead you to a visual process map. I use stickies to get a process map out. The good thing about that is that you can get more team members in and validate that process, your understanding of the process, and they can help fill some of the gaps. And initially, you'll want to capture some numbers, some metrics. It's important how you use those numbers later on. But remember, those numbers are just FYI for now. They may not actually lead to a lot of action. Active coaching is actually about pairing with actual team members on actual project work. I keep repeating the word actual because it has to be real. You have to be there for them day-to-day and help them perform their role day-to-day, whether it be QAs with identifying test scenarios or developers doing TDD, or product owners trying to prioritize and slice stories. In addition to that, you will need to focus on facilitation and by facilitation, it's a very broad word. You have to be careful how you interpret it. It's not just facilitating your discussion or huddle. It's that with also about facilitation of thought processes of individual team members and collective group, as facilitation in terms of unblocking people, empowering them to make changes. Measuring progress because hopefully active coaching is leading to improvements. You need to make sure that it's in the right direction. And very, very important is focusing on self-learning for the team members. You need to realize that you won't be there all the time to teach them stuff you're not expected to. You need to teach them how to learn. And this self-learning hopefully will lead to self-discovery, where not only do they learn how to learn, but they start looking inward and figure out what strengths they have at an individual level, how the strengths can fit into a bigger picture in an agile team or an agile project, and maybe in the organization, and they play to their strengths. And sustenance is the period where you realize that your engagement with the team is probably going to end soon. You're going to move on. That's a good time to work on a benefits report for stakeholders so that they realize what benefits they got from the coaching. And more importantly, any recommendations for next steps so that they can continue the journey without you. Quickly taking a look at some examples. Is this clear? Is the picture clear? No? Thank goodness. Probably client-sensitive information. So I've deliberately made that a little hazy. But you can see the stickies I mentioned, right? So you just use a whiteboard and you stick stuff up. Each sticky represents a step in a larger process. In this example, people start off writing epics. They're like really, really high-level requirements for lack of a better word. These epics are then broken down somewhere here into features. Features are then broken down into stories. At some point, the features are also estimated by a few people. And then the stories are also estimated by a few people. There are two levels of estimates happening. Those people we are annotating here. And then the stories go through the iteration. There's a regression in the end. There's a deployment. There's a go-no-go decision taken. And then there's customer support. So that's one example of a process that was being followed at an organization. This was based off the information I got from interviews. I got the PM, the technical lead, and the product owner into that room had them validate this. They are the ones who helped me with the annotation, got some roles against the processes. Who's doing what? Even got some names in there, actual names of individuals who I could reach out to and get more details. And they helped me identify gaps. So there were some stickies I had missed, but they called her, hey, this step is missing. They can help complete the picture for you. And then you let those guys out and you get some more people from on the ground. The lowly developers, the lowly testers. And let them see what part of the picture they recognize. I was just kidding. I was being orchestrated with the lowly developer thing. But it's very interesting when you get a developer in, he'd probably be very good with the details here. And they'll probably not even know what's happening up there. So this exercise actually helped team members. It helped facilitate team members' thought process about the entire flow. I would ask a question, how does what you go live with feedback into the entire process? And then they wouldn't know, right, that there's a customer support thing happening, there's feedback from the customers, how the product managers work on that with the help of product owners and so on and so forth. Very useful exercise to do with the team. Talk about collecting numbers. If your team had already started agile, like some of you here, you probably have some tools like JIRA or Mingle in place or Jenkins Go for product management or CI. If yes, then these numbers are easy to get. If it's totally fresh team who's not done agile before, you don't have any tools in place, there'll be some manual work involved for you to get numbers like these. That's velocity, coverage, and a different concept. Talking about active coaching, facilitation, right? It's not very clear. On the top left, this is an exercise I did with the team recently. It's called a mind mapping technique, right? You've got a group of people into the room. Now you want to brainstorm around how do you want to deal with the story within the sprint? What is the lifecycle of the story? But a good starting point was to just brainstorm what is the story? What does the team feel that a story is? I had no role in coming up with the items here. It was a team who was talking out. It started with that bubble, and then people started fleshing out, oh, a story is an idea. It's a requirement. It's a feature. Why do we do it? Who's involved? What is the objective of the story? What kind of activities need to happen on the story? And then that led to even further fruitful discussion. On the right, that was a closed meeting with, again, the product manager, the project manager, and the technical lead about their roles and responsibilities, clarity about their roles and responsibilities. I used a Venn diagram there to get multiple perspectives of a role and responsibility. The Venn diagram had the sets for environments, skill set, and interpersonal relationship. And this, of course, is a typical well-done retrospective. It's a variation of speedboat exercise or anchors and engines that you must have seen. There's a vehicle there stuck in mud. The mud is your anchor. The fuel is your engine. Self-learning. I mentioned self-learning. I found the Princeton model very useful. This is what Princeton University uses. They say that 70% of learning happens by doing actual problem solving. That's what I've been mentioning. My active coaching was mostly about solving real problems on their actual project. But 20% of learning happens through examples. That's where knowledge sharing sessions come in, workshops maybe. You can see a Kanban board that I had set up with the team, where the team would put up stickies of topics they wanted to talk about, learn about, discuss. And as in when we had a weekly or bi-weekly knowledge sharing session, we'd move it to done. And then 10% is reading, reading on your own. So I typically start up an email thread or a wiki page where we would collectively get links that we should be reading, links to blogs, articles, stuff like that. It's a big coincidence that a lot of the links are from Martin Fowler's website. He's in the room, a big thanks to him for writing a lot of good stuff out there and hosting other people's articles as well. Measuring progress. So quick quiz for you guys. So those are the numbers before and after coaching, a certain period of coaching. Given the metric of code coverage, which team is making more progress? So raise your hand if you think it's team B. Everyone thinks it's team A. Is that right? That's because 25 is greater than 10%. 25% is greater than 10%. Another question. So given the metric of defect count, that's before and after. Which team did better? And if you think it's A. No one? So everyone's thinking it's B. Both? Well, better, better. So it has to be a comparison. All things the same. All things, yes. Given all things the same, then sure it looks like B had lesser defects. So maybe given this, which team made more progress? B. There are a few A's, but a little more of B's. And maybe the answer is yes, because sure team A had all their focus on increasing code coverage. But why do you do code coverage? That number is not really important. The hope is that code coverage will lead to better quality. Another reflection of better quality is the number of defects that you have, right? So maybe the code coverage wasn't important. Maybe the kind of unit tests they were writing were not really good unit tests. They just helped increase coverage. They didn't add value that a unit test should be adding. So maybe B was better. A twist in the story. So if this was taken in the iteration of Sprint, where two out of the three QAs were on vacation, or team B, for team B two out of three QAs were on vacation. Maybe that's why they have lesser defects. They could have more defects, but no one discovered them. So that's just a game that numbers will play. So as a coach you have to be very, very careful with metrics. Just be very, very careful, because they are very easy to misinterpret. Metrics are an indicator of progress. They do not guarantee that progress is happening. Always use subjectivity and context. Quickly talking about sustenance. Again, some exercises that I like to do. This is called circle of components. I learned about it from a colleague. You have the team in the room. You give everyone an individual sheet of paper. They draw a stick figure for themselves. They put a circle around it. They list down points which they feel they are comfortable or they know well within the circle. And outside the circle, they put points that they want to learn or improve upon. That's a lot of introspection that's happening. And then they go around and look for people who already know the things that they want to learn. And you get people to connect with each other. That's just an art exercise where you just have people draw themselves as a way of introducing them without using words. So that's some crazy person who probably loves beaches and it's funny on the outside, but on the inside. I have no clue. Of course, they are better known tools for self-discovery like Strengths Finder and Mind Time. People have actually found it useful. I have found it useful, so I do recommend it. Benefits reporting. It's good to take a survey from the teams instead of you reporting the benefits of what you perceive. Let the team talk about what they liked from the coaching period, what they've learned. Put a few pictures from the team area which shows that they are getting to that sustenance level. They are doing things on their own and a nice well-maintained story board, story wall, or new visual indicators that they are putting. For example, a team came up with this idea for managing their time-boxing of stand-up. There were some techniques that I discovered with the help of others or just came up on my own. But there is more out there. The question is, are you ready for it? Are you ready for this role? As an individual, I feel you need a lot of patience and you need empathy. That's difficult. You have to grow that. So while you're coaching others, remember that you yourself are getting coached in some of these attributes. It's a learning journey for you as well. You need to focus a lot on facilitation skills and you do need experience and mentoring skills to help teams in difficult parts. As an organization, you'll need practitioners with coaching aptitude. Not every practitioner may make a good coach. You need coaches to coach the coach. Of course, you need a support structure for coaching. For example, just a community of coaches. They're sharing learnings across each other, a knowledge repository where they put up stuff. But most important of all, empowering the coaches to try experiments with the team, right? Give them that empowerment. Hopefully, if you do these things and then maybe more, someday you guys will make the transition from practitioner to coach. And my best wishes to you guys. It always helps to have a friend during that journey. Feel free to think of me as that friend and there are others out there you can reach out to. So be in touch. Thanks for your time here. I did exceed time so catch me offline if you have any questions. Thank you guys.