 So with me, I have Vishal who is working as a product expert. He's been part of our conferences for many years. I remember him raising his hand, asking questions. So it's fascinating to have Vishal here. Talk on something which I think is very dear topic to many people around agile coaching and his stake on why he stopped coaching. So I would love to hear that from you Vishal. So without much due, Vishal, over to you. Thank you very much, Naresh. And thank you everyone for joining. Well, you said 33. I wasn't really expecting a lot of listeners considering the topic that I'm covering today which says why did I stop coaching? But I'm happy. I'm happy with the attendance. Thanks. Let me just share my screen before we proceed. Awesome. So a little bit of brief about me before we go ahead. Yes, I'm a consultant at ThoughtWorks. I primarily play the role of her BA, but I've worn various different hats as well. And I'm quite passionate about the modern software development practices and a part of my job does require me to impart this knowledge to stakeholders in form of coaching or otherwise depends. And apart from this, I have a keen interest in professional education. So I recently started a podcast with this in mind to educate organizations to be a much more satisfying experience for its people. I call it educating organizations to be awesome. And if that sounds intriguing, you have the website on the page. It's enterprisejoy.com. I have nine episodes so far, so feel free to check it out. But lastly, I do love to experiment a lot to an extent where I guess I have formed the habit of failing a lot. And this talk is basically a result of my experiments. So before we proceed, let me set a context just for the listeners. And I would like to take the questions towards the end, as Nareesh said. So please keep putting your questions in the chat. And if we are not able to cover all, we go to the lounge. So the story for me for this particular talk actually starts back in 2019 Agile India Coach Camp. And during this Coach Camp, we had quite a well-known group of audience members. And I remember Woody Zool, he ran an interesting talk at that time around organizational inertia. Now people who don't know it, this is basically a state in which the organization is, which considerably slows down the change process and at times is considered to be one of the biggest hindrances to any kind of a change process. And during last year, I did, as I said, I do a lot of experiments. I use an acronym SLICE for myself. And I presented that last year in Agile India as well. So I thought of running a thought experiment around this particular topic. So what I did was I just placed an idea which went something like this. We can deploy Agile Coaches in organizations and hopefully the organizations become a better place to work in 10 years by overcoming their organizational inertia. Contrary to that belief, it may also happen that if Agile Coaches just cease to exist. And in the next five years, the ones which are then left are automatically great places to work. And obviously from an economic standpoint, the second point looks more interesting and more attractive. However, this didn't go down well with a lot of coaches, not just during the coach camp but also afterwards when I had this talk. But this wasn't my intention anyway. What I was suggesting is merely one of the ideas and possibilities. And there were a lot of follow-up discussions that happened after that. So there was one where I spoke with Shane Hasty where he said that yes, it's possible that this happens. However, his job requires him to make it a great experience for people at this point of time and not five years later. And then a similar discussion happened with Sunil Mundra in one of the podcast episodes where he said that a coach is pretty much like a doctor. We can't be selective about our patients. So yes, maybe this is not a good idea. But since I said that I like doing experiments, this doesn't stop me from coming up with a number of hypothesis. And I actually tried out a few in the real world because curiosity has no limits. And what I showcased today is just two of those experiments or observations. And this is not to just say that, hey, this is what you should do. This is just observations that I've collected. You are still free to decide what you want to do after that. Okay? So with that, let's go to the first hypothesis that I came up with and the first hypothesis, this actually came up during a discussion with Shane Hasty, where we arrived at a point saying, anyone can be an agile coach. Not everyone should be. And the context that we have is that recently we have seen an explosion in the number of agile coaches, a lot of them self-proclaimed and a lot of them driven by certifications. And this hypothesis, although it's fair to teach coaching skills to people, not restricting coaching as a practice to a few, may be more harmful to organizations than doing good to them. And one of the reasons I make this bold statement is because I used to certify people in ICP ACC. That's the agile coaching certification provided by IC Agile. And I was disappointed with the participants in the class who many a times didn't even know the basics a lot of the times. And I do remember conducting one of the classes where I had auditors from Deloitte. So I had no reason why they were there, but yeah, they were there. So there are two particular experiments that I ran and the results, and I'll show you this result basically in two blocks, something that more people agreed versus less people agreed. There are no specifics or percentages over here because this is more of an ongoing thing. What I show now is the result that I have so far. Okay. And in that to say the fans of Jira who have found the new love of precision and story points, maybe you don't like it. But this is basically what I had the two observations or the two areas around which I captured observations. The effects of having a code of ethics for agile coaches. And the second one is the effects of making agile coaching and certifications either obsolete or extremely difficult to achieve. And the participants of all of these observations that I share are a number of my students who I certified for agile coaching, LinkedIn polls, friends and colleagues in the same profession, folks I meet during meetups. The demographics is mostly Indian crowd of all genders and roughly corresponds to 100, 120 people. Okay. So let me just drive you through the observations based on the questions and the things that I observed. And then let's see what happens. Okay. So the first question that I basically asked a lot of people is that are you certified agile coaches? And obviously when I asked this question, a number of people said yes. As in more people said yes, less people said no. And this was asked to a bunch of my students as well and the people who in some form have a certification that either mentions agile or mentions coaching. And the reason why this observation was interesting to me is because until last year at least no program existed that was named certified agile coach. There's one now. I don't know the credibility of that, but the known certification bodies that we have in the agile space, let's say I see agile or Scrum Alliance or Scrum.org, they didn't have anything like this. And yet people believed that they did. They were certified agile coaches. In fact, there were a lot of them who had that mentioned on LinkedIn as well. And the crazy thing was that people attending my classes as well did not have this clear. And there was at least one time when I made this clear to a bunch of students and one of the students really got upset and he actually made a phone call to the training provider organization to just get the truth. So yes, there is a misconception in people around this that, and even in this room basically, let's say 30 people who are here, you may feel that you are certified agile coach, but that may not be the truth. And this is something that I wanted to be clear about. So that's okay. I did not mind if someone said that they are certified agile coaches. There was a follow-up question that I basically imposed, which was, will you be open to follow a code of ethics for agile coaches? And of course, most of them said yes. So I presented a code of ethics to them and the one that I presented was very superficial. It was nowhere close to, let's say what Shane Hasty discusses, okay? And I just wanted to see if I present a code of ethics, will that be acceptable to the people? So this is basically what I did. I added a bunch of superficial yet important points under the ethics, something like this. And it basically said, I will not call myself a certified agile coach. That's one. I will not call myself an agile coach unless I'm actively coaching. And I will call myself a scrum master on LinkedIn. That is, if I'm a scrum master, I just call myself a scrum master, not an agile coach. Very honestly, I had never seen the answers move very quickly from yes to no, okay? So the moment I presented this code of ethics, there were people who said, no, we cannot follow this. Although the first question, they pretty much agreed to it. And even the reasons for this was very consistent. So many stated that this helps them with their career progression. And many said that this is something that they aspire to be, which is not a bad thing. The problem with aspirations is that's not how we introduce ourselves to people. When we introduce ourselves to people as agile coaches or maybe something else, it comes with a set of expectations. And which if not fulfilled, it can do more harm than good to organizations. And that directly ties back to the hypothesis that I had. And then there were just many people who did not even buy into the entire idea that, hey, there is no program in the world that calls someone certified agile coaches. So yes, as for the first result, when I showed a code of ethics that someone would might to follow, the answers actually changed. But then I took it a step further. I said, okay, that's perfectly fine. Let's go with the next question, which says, will you pursue a higher certification if it was sponsored? And I was actually not expecting a different answer over here. Most of the answers were yes. And this was just to say that even if you want to pursue your journey of being an agile coach and let's say if certifications is one of the way to do it, will you consider it if it is sponsored? And many people said yes. And then I kind of changed the question. And the question I changed to was that will you pursue a higher certification if it was not sponsored? And the results, to my surprise, rarely ever changed. And this is something that I admire about because this shows that people still have a zest for learning. Whether it's sponsored or not, it doesn't matter. Now, obviously certifications can be misused and I'm not saying that certifications is the only way to learn. But let's say if they do specify something in your career, the zest for learning does exist. And this is something similar to what I spoke with Jeff Stite on the last episode of my podcast, where he observed with his work in the Indian subcontinent that the zest for learning is much more compared to the West. And I do see this as a positive sign. So I don't teach certification courses anymore, but I'm still passionate about continuous education and this is kind of a positive step towards it. So I was really happy when I posed this question and still a lot of them said yes. Although this was not long-lived, because the next question I imposed and this was the second observation from my hypothesis where I said, will you still pursue this higher certification if it was extremely difficult to pass? And by extremely difficult, I mean, let's say if someone has to score a 90 or 95% in the exams to get these certifications. And the answers flipped. And more people said no, if it's extremely difficult, they would not want to pursue that. But there was still a small group of people who did say yes. However, the common theme between these people who said yes was people who were either trying to get a career in training as in training people on fundamentals of agile or someone who wanted to become a consultant or a coach full-time and they want to go ahead in that direction. And that's probably the reason why I mentioned initially in my hypothesis that anyone can be an agile coach, but not everyone should, because this is a rigorous path and it needs to be a continuous process. And if not done so, it can do more harm to organizations than good. However, firstly, certifications is not the only way to be agile coaches, to be great agile coaches. And secondly, this is not something that I'm trying to decide on your behalf, what you should or should not do. So you're free to actually pursue agile coaching or certifications. This is just me stating some observations. So this is basically what I collected out of the first hypothesis, which was to say anyone can be a coach, but maybe not everyone should be. But then I went on to my next hypothesis and the next hypothesis basically mentioned not talking about agility improves agility for others. It may be a little confusing, so let me just try to explain you in different words. If we limit the amount of suggestions we keep on providing to everyone regarding agility, that will probably reduce the amount of agility. So if we stop doing that, people will be agile much faster. And this is obviously beyond the agile software domain that I'm talking about. Another way of saying this would be I shouldn't be teaching swimming, I should just push you in the pool and you'll probably learn to swim much faster. And initially, with this particular hypothesis, I wanted to focus a lot more on social media to say that what happens in social media stays in social media kind of a thing. But very recently, the last month itself, I kind of shifted towards tools. So inspect and adapt in play over here. And although I had two different observations, I don't think we'll be able to cover the second one considering the time that we had, but the effects of tools on the knowledge of agility. And this is something where if I ask a poll in this particular group, I wouldn't, but let's say if I would, and if I ask how many of you use JIRA or a tool which is equivalent to JIRA for your work, a lot of you will raise your hands. And this is where I want to go ahead and say that tools like JIRA or something equivalent, they have kind of become a source of knowledge for many to an extent that now people understand agile software development from a scrum or Kanban, only to the extent to the features which are provided in JIRA. And that for me is dangerous when it comes to professional excellence. So a few days back, I asked people on LinkedIn if tools enhance or restrict your creativity. And most people during this poll replied saying that it enhances creativity. And now this is where experiments like these become tricky because surveys may not be the best tools to get results on topics which are more factual than more opinion-based. And this is a set of experiments where I kind of prove it. So I'll try and explain it, explain to what I'm trying to do over here. Let's consider kids. Now kids are creative by default, right? So you give them some colors and they'll do something with it. You give them Lego blocks. They'll probably build something. You give them an iPad and they'll probably do something with the iPad. But occasionally kids surprise you as in sometimes if you give them colors instead of painting, they would eat it. Sometimes if you give them a laptop, they might become a white hat junior. I don't know. That's trending right now. But the point is that the same creative person can do many things. So it is simply to say that the tool is not the one who's enhancing your creativity, you're creative by default. The tools are simply there to unleash your creativity or not even enhance, just provide you a facilitation point where you can just let everyone know how creative you are. And at the same time, there is a statement that says, a fool with a tool is still a fool. And this actually, the second statement became reality a few days back. So just for fun, I tweeted and asked Atlassian who are the creators of Jira, by the way. And I said that we live in an era of pair programming and mob programming. And Jira still does not allow me more than one assignee on one ticket. Why is that? And the reason I know this is because back in 2008 when I started using Jira, Jira at that time was a pure ticketing system. It was a bug tracking and ticketing system. And unfortunately I see that legacy being continued even till today where I cannot have more than one person assigned on the tickets. And what Jira or Atlassian basically did was reply to that tweet with a bunch of request URLs saying that, hey, we have a lot of these requests and we basically build something that users request for. So if you want this, please put a vote up and we'll get it done for you. Unfortunately, a lot of these tickets that they replied to, I don't know there was some judgment of error, but most of these were closed. So even if I would have voted, they were still closed. So I still continued with a few back and forth tweets with Atlassian. And finally they said, okay, we have taken your request and we'll pass it to the development team, which in a big brother's format is a polite way to ask someone to back off. And then a few days back, something interesting happened. Jira made a very nice release which had decimal points for story point estimations. Precision for the win. That's what they said. And that's when I actually went ahead and I questioned them that they claim to be world's number one software development tool. Why are they propagating bad engineering practices? And to which they actually replied to Ron Jeffries, the creator of story points, saying that this is basically something that many users ask, so they provided. But this is another example where surveys or user research went wrong. This is an example where although I do understand user experience is one of the best things that has happened and we do a lot of it when developing products, surveys cannot be a basis of a lot of experiments or a lot of things that we do at work when it comes to facts against opinions. To give you an example, let's say if I go ahead and I ask people what is the answer for 2 plus 5 divided by 7 and if say most of them say 1, that doesn't necessarily make the answer correct because the fact is that according to board mass the answer will not be 1. And similarly, if I go ahead and ask a number of people what is it that they want that's still going to be wrong if it's not fact. And this particular Twitter thread it got a lot of traction even Ron Jeffries he retweeted it and number of sharing and commenting even on LinkedIn happened with a number of different people but the sad part is that this feature still stays in JIRA and probably the number of teams around the globe and Flat Earth, I'm inclusive of everyone this is an example of a massive organization imparting wrong knowledge to a massive audience and especially the ones who equate agility with the tools that they use. So of course I went ahead and I asked JIRA that why don't you provide me the bunch of tickets or the request URLs where people asked for this particular feature and so far JIRA has not applied yet but this is where I want to reiterate my second hypothesis which says not talking about agility probably improves agility because a number of people and a number of sources who talk about agility may not be doing the right thing. Now this is an example of a tool speaking with us, speaking with the people and providing them goals as to how they are supposed to work which is contrary to the belief of the coaching stance. Coaching stance is to get the goals from the coachee and not direct them how they are supposed to work. So if there is a code of ethics for example for coaching then that should apply to tools as well and to big organizations that provide some part of knowledge when it comes to agility. Now I know especially in COVID times you may be asking the question how will you even work in a distributed way if you don't have tools like JIRA? My suggestion would be to identify tools which are more simplistic and have minimum set of features compared to something which is feature rich like JIRA and this can possibly unleash much more creative capacities of individuals than otherwise and I usually joke around that if you really want to see the teams to creativity forget renewing your license like renewing your JIRA license for a month and you will see agility overcome a lot of obstacles in that case. So this was the second hypothesis where sorry, I wish I'll quick check we are a little over 5 minutes time so yeah, I'll let you wrap up. Yeah but that's all that I have so I will actually leave you with these observations this was just to impart some information about what kind of experiments I have conducted and where they sit when it comes to coaching agility and my intention from this talk is not to ask you to stop coaching agility rather coaching is one of the essential methods for helping people grow this is just to highlight which aspects of human behavior gets mistaken as coaching and why these must definitely be stopped so yeah, I think I'm good there Parish, thank you and if there's any time then we can probably take some questions I did not see any questions alright, thanks a lot everyone