 Good afternoon. I know it's the toughest time right after lunch. After 45 minutes is when it sets in, and I knew it, it's gonna be the slot I would be eventually given. The third time, probably, I'm doing it at 3 p.m., so I know it. Good afternoon. Thank you. So as it goes, this is not gonna be something all bed of roses type of a session, which means saying, hey, it worked for me, everything worked, everything worked. We're gonna talk about some of the challenges. Again, it's an experience report, so which means to say what I have experience is not something that you could appreciate. What probably you will experience is not what I can appreciate in a 20 minute talk. But I wanna leave you with some amount of nuggets in terms of what we are trying to look at from a perspective of when you have grassroots, grassroots level team, adoption, and things going really well. People are kind of ready to adopt it and move forward. There is some breakdown happening at the senior level where there is a mismatch in terms of how the adoption really will take it forward. And how it all kind of boils down what are the different situations that it can come into. I'm gonna use or I'm gonna take the help of some anti-patterns, that's the intent of this particular thing to bring you. There's how many of you know anti-patterns as a word in Agile? Not just in Agile in software development. Okay, few of you, great. The rest of them is a nice read. A lot of authors have really talked about these anti-patterns. Some of them have talked, it's a pattern. It's about certain things that we will cover. I'm just gonna take three of them so that in one of time, as well as in something that we're gonna look at. And again as an experience sharing. Again, there's a disclaimer to this entire thing, right? Any characters in this particular thing, living or dead in your organization is purely fictitious. Because at the end of this session, you might think saying, oh, that was nothing new. I know this guy in our own office. I know this team in our own office is gonna be the same case. But then how you can kind of overcome that or something is something as a foot for thought for when you take to leave. Introduction was already given. I don't want to talk more about me. You can always, if you want to know about me, it's about dot me at Venkatra Mail. So you can read and please do connect. There's a LinkedIn connection in the bottom. The other handle is my Twitter. I'm not a very, I don't tweet daily per se, but I do a lot of retweets. That's my way of not endorsing, but appreciating certain things. So I am currently, it always happens, I told Naresh today. I'm currently in the middle of two jobs. So whenever I speak in this conference, I'm in that stage. So next time I don't want to speak probably because I don't want to keep hopping jobs every year. So I'm still in the Middle East region. I joined a Greenfield Hospital project out there to manage the portfolio side. And we want to get into the agile portfolio, but due to a lot of reasons, you know the Middle East oil crisis as well as everything, I decided to move on to some of the organization due to the downsizing. So that's where it stands for me right now. And I'm in the verge of the next job, which probably will be pretty interesting. And that's going to be a lot of agile work out there. Quick context, we all know agile is first word that comes to mind is cross-functional teams. And then we talk about pilot project, which means I have a huge 20 member, 30 member team which I can run my pilot project on, show it to the organization saying here is how we run agile and here is a success story, let's go agile all full through. And the reason why it's stuck off out there primarily is because this engagement that I'm talking about does not have a cross-functional team now. And it does not have an, the reason it's going to be that way is how the company was structured and how many this company grew from 60 to 200 Agilis and they had to hire the functional way of doing it. We'll see why. And then it's a startup kind of a mode. The pilot project was not possible because it's not cross-functional. You get me? Because if you, we will look into that particular slide and we're going to talk about it. I'm just giving you the context in terms of where it is. And many of you would by now be thinking, yeah, it's not cross-functional. It's not going to be having any pilot project. Half of your problem is right there. So it's bound to fail, right? But really that wasn't the problem. We ran at any given instant 80 plus concurrent releases. Release could vary from three weeks all the way up to six months. So majority of the mean, median mode, the majority of the stuff was contained around three month period. One or two releases were in the four month to six month cycle. Of course with intermediate drops to QA, to a staging environment, we were agile. We didn't want to go ahead and say, we'll do a full release. So it's just like multiple drops, demos and whatever you want to call it. But the first version or the minimum marketable feature would probably see the light out in six months. So that was the 80 concurrent releases of varying efforts. 200 plus Agilis, when the company started, it was around 60 people. When I joined them, it was just 60 people in the engineering and development and ops and everybody included. In one and a half years, the company moved into 200 plus engineering team, which means to say no products, no business, no sales. I'm just only including the engineering, which also included the ops. Of course these numbers don't relate to this, right? So this is one of the biggest things that you're talking about saying just the three member team you had and then you wanted to run the entire show. Yes, because somebody said in the morning saying, or even just spoke about keep it simple, keep it lightweight and keep a very lightweight process in terms of what you're trying to look at. And that's exactly what, as an HLPMO head, I wanted to ensure that we are able to manage this show with just a three member team. That's the context. The organization structure was something similar to this but it's a huge structure, forget about that. I'm only talking about the engineering side of it, okay? The green one talks about the grass root thing. You may be surprised. There was an engineering manager coming into the grass roots. Yes, just as an engineering manager and the dev team as per scrum guide and not the scrum team. I'm just talking only about the dev team, okay? So this green one was going fine. In what way? Something like this. We had functional teams of ABC and all the way up to Lian. So maybe around eight to 10 teams. Again grew from just four teams when I started to almost 14 teams. I'm giving you this context because this is where the real essence of why we had the problems is coming. And these are all the AT releases that I'm talking about owned by an engineering manager. When you say owned, though this release cuts across team A, B, and C. In this case, this release one cuts across A and C. The three stars do mean that the work of A is one third of the work of C. So you can relate that way in terms of, I'm just trying to kind of depict it in such a way. This is one of the reasons why a cross functional team was getting a little tougher there. Because the moment I put EM release one to a cross functional team, this guy would take six days to do the work and this guy will take two days to do the work. And eventually this person needs to take up. And again, we can again talk about saying no agile is all about generalists. He has to code Java all the way up to DBA and also the front end also about EM. Let's also take it to fact that India doesn't work all the time that way. You get very minimal generalists and they probably are sitting in the principle architect levels in other places where they can actually touch the code all the way and from the end system. And if you have a very big system which has big data, front end, core engine, everything else into picture, you wouldn't get a guy who can code the entire release out in one shot. You will, but you can't have organization of 200 people, all of them being generalists. So we did have in many cases some release teams, which means to say they pulled in people into a war room or kind of a small team space and say this release is very critical for the organization. It's a million billion dollar deal for us. So you guys are not moving out anywhere to your own home teams. You're gonna be sitting here till the time this real thing happens. So that was also tried. My only point is this is the generic way how the 80 releases, or you can call it 80% of the 80 releases were run in this year. Mary Puzzle looks saying okay, but then this was working. Perfectly working. Some delays in each of the projects. That's my responsibility as my Agile PMO team to really showcase where the releases are, what's the predictability and things like that. So this was the situation. Now where did we hit the roadblock? Everything, when I say everything was going fine, we had everybody locked into sprints. The teams really picked up their works. The first time that the team is getting into understanding how they have to pick up their work rather than trying to having somebody else allocate the tasks to them. Now they come into a room. They do the whiteboarding. They take the post-its, move from this side to that side, try to kind of do the complete planning. They go happy saying I at least can now have a voice for myself, right? It so happened that a couple of people in one of the, a couple of people in the senior league used to be having people randomly pulled in from teams to do a lot of random work, which means there's some new idea because it's a startup mode and you need to kind of beat the competition. So you need to try something quickly. So there used to be a set of people who is just walking and say, hey, I need three hours from you today. And the guy says no, he can't say no because a senior member, pretty close to the management, pretty senior level, all working very closely, hand in hand with the senior management and he has to showcase, you'll be nice one to work with him, right? As an engineer, you'll see I'm working with this guy, the senior guy, I'm gonna get the visibility of the entire management. They started, they couldn't say no because the first question was, but then what happens to my sprint work? I have given my capacity to the sprint, right? This started the big noise. Whenever they, that used to come, couple of people used to come and ask for these kind of resources, the guys used to reply back saying, no, I have sprint work. No, I need to complete the, I'm logged into the sprint, I have some deliverables to QA. I have some deliverables to this developer who's actually waiting on me. So what we started to do was we said, let's do this pattern. So I'm gonna kind of walk you through certain, sequentially how certain patterns and our anti-patterns of you can call them. Though we tried, really kind of did not meet the case. Sacrifice one person. Which has got to say, in this team, this sprint, you're gonna be sacrificed. Which means 50% or 30% tasks you can pick. Or somebody said today morning, I think Rich was the person who told about it saying, you're working 15% here, 30% here, 30%? We don't want to do that kind of a break up of that guy, poor guy. What we would try to say is, you will pick up tasks which probably is like a hyper-ready bug fix or anything of that sort that you wouldn't be really need to, but you're gonna be sacrificed because we don't want this noise. This is unnecessarily getting in because many times you have the CEO walking up to you saying, guys, I'm hearing you guys aren't ready to work with this on this. Then this guy looks at me and looks at him saying, what do I answer? So we said sacrifice one person. That also didn't help. Then it went to a point where the leadership went into some conference and came back and said, guys, I don't think we are doing too fast. Agility is all about speed and everything and the competition is beating us. I don't think this 90 day, 40 hours per week and out of which you take up 35 hours, you do haircuts and everything and put your capacity sheet is all not gonna work. I want these 30 releases in 30 days. Agile goes out of the window 101. So it's like non or fragile 101. That's the start of how I could see things really falling apart saying, guys, that's not gonna work. Now I took you to a room. You guys had made everything. You came out very happily. Now all is being distressed and you guys said, forget Agile, let's go the normal way. But then we still struggle said, okay, we'll still do this in a, we'll take this for this two months. We've asked for 30 days. Let's stop everything for 45 days and try a non Agile way. That became the death march. Out of the 30 releases, only 14 to 15 really were done in the 30 days and the rest of them moved out of the 30 day window into a normal Agile sprint mode, right? Next was, what happened was the transparency. We started to put everything up on the walls wherever the team space was available. And suddenly everybody walking across saying, hey, started to mimic it. The senior management started to become a little annoyed. They didn't understand that one teams, when I say not understand because it is permeating within the organization to say, hey, you don't want my born down to be seen to anybody else. I said, it's not gonna be for anybody else, it's for you. But why are we putting up in the wall? The other teams are able to see it. Team A's born down looks great. My team, my born down is not really great and it's not motivating for my team. I said, do you need to bother about team A's born down? That's the core thing about what we are trying to talk about in Agile. I mean, you try to coach them and say, why are you gonna, no, no, it's becoming a lunch talk. It's becoming a water cooler talk. That, you know, team B's and it's getting hitting the morale of the team. Transparency was getting a little bit touchy with the senior management also because when I'm gonna put up a plan of record, as you call it, POR, where you kind of mark that release. You saw that grid that I kind of wrote out, release some teams. You kind of give out a plan of record saying, this release, here is what the teams are working on. Here is the UAT date and here's gonna be the end date of release. All of it published with a delay, delayed, delayed, started to become a little bit more sensitive because those meetings were being attended by business people and they said, why is every project delayed? So when we said delay, it's probably like a week. In Agile, if you're not able to complete with an sprint, what do we do? We typically kind of put it back into the backlog, take it back in. So people started then buffer. There was quite a bit of things that were happening and a lot of, we said, no, probably Agile is not working for us and however our team tried to explain, tried to explain even for me when I started to really think about an in retrospect started to kind of look at what are the patterns that were happening. I started to read a lot about anti-patterns and patterns, right, because even when I was coding myself, design patterns used to be fascinating for me. I still have that Head Start book, you know, there's a very good book by Head Start, it's called the Head Start and they have nicely defined design patterns. So I kind of look at what the patterns is. Why is this happening over a six month period? There is always somebody who's trying to pull this entire Agile thing down or a set of people who are very uncomfortable with certain transition that's happening within the organization. So it's still not come up for me, it's here. Maybe I'll wait for them to put it on. So the bystander effect is nothing but, it's also called the bystander apathy, which means you have a person lying out there and all of them are just walking away. The person is lying there forever or you're not willing to help a particular person, though you know it's right because you're gonna offend a certain set of group. That's just an example of a bystander on the road, but a typical corporate way of bystander is, you know what you are probably trying to do is not right. From a senior management, there were a few people who were empathetic or rather not empathetic, it was empathetic towards what is happening, saying no, I think what you're doing is right, we should be doing it this way, but they weren't willing to go beyond that and help because it's going to disturb a set of people who are actually very upset about the transparency or very upset about how this entire thing is playing out. So the bystander effect really started to ensure that there's minimal support being available for the agile transformation. Let's go ad hoc way. Couple of, in my kind of look out what I kind of see from this perspective, specifically with the three things that we talked about, even after sacrificing one person, the noise didn't die down. Even after seeing that this kind of control-freakiness of trying to do 30 releases in 30 days and another 30 releases in the next two months and this has to be done, is not going to work out, is actually burning out the teams more than trying to be really rhythmic and trying to get things done. We still had a lot of transparency issues being debated, bystander effect coming into picture. From my perspective, I was thinking, saying this is not how a leadership should operate, tomorrow I'm going to be in the shoes. How should I operate this in terms of, with all credit, given to the management who tried their hard to bring back things. This is a three-year journey. I'm not talking about all these things happen in the mid 1.5, but we still stood ground for the next 1.5 to say, we will showcase, show the word, we will show the way in terms of how it has to be done and why this way of doing is much successful than doing an ad hoc or any kind of a randomness that we are trying to look at. Leadership is about being participative, which means don't take these calls of randomness or doing a death march, but involve the team, involve the real people into understand. Doc was just saying about taking their inputs or taking estimates coming from them and not you drive down saying 30 days, 30. Did you even check with any of the engineering leads in terms of whether that's doable or you're going to be just putting a mandate on top of their head saying, because the rest of the world is doing. Being participative involves a lot of courage, which means to say taking a lot of no's, taking a lot of feedback from the team saying, this is not going to work. This is definitely not going to work. You're going to burn out my entire team. It's going to going worse than how we were in Ajay. Over a period of time, I started to hear from a lot of people, especially the grassroots saying, when the sprints were much better. We at least could deliver everything over two weeks, even small slips here and there we used to make it, but this is getting like, you know, this is getting really out of my hand. I'm not able to kind of deliver it at this period of time. And putting it just in a two week box is not working because we're not really doing anything to do with Ajay. Letting go and yet in control, which means to give it to the team, but at the same time have certain conditions clearly defined. So guys, I'm trusting you to do this, but you need to come back and give me this output. Trusting you to do this, you need to kind of raise certain issues upfront to me. You can't go and tell me at the end of the sprint that we were not done. So those are the things that need to be giving in, in terms of you let the team go make those decisions. He just finished the thing saying, the decision is to be taken by the team who's doing the work than by somebody who's not doing the work. So letting go of control is so important in a leadership thing, but at the same time be in control. It's a very, it looks very, very, very different, but it is doable. It is very much doable when you are going to be taking a hands-off approach and letting the team know that you're going to be there. I also had a similar manager in the past. She used to have this approach. She used to be completely hands-off, but at the same time, visible in all meetings. That let the team know that saying, she's going to always cover us. So I'm going to be open with her in terms of whether I'm facing any challenge. If I'm not going to be meeting my timelines, I have every right to walk up to her room and she'll be kind of helping me with that particular thing. So that is exactly where letting go, it in control, not shooting the messenger. How many of us have been in this position where we always have a grudge against somebody or something against somebody who's actually bringing us the bad news? The bad news is actually very good. At least you are given a two-week, three-week timeline by which you can go back to the client and try to buy a little more time. Rather than giving you always good news, Vishy today was talking about watermelon metrics. It all looks green from outside. The moment you keep going in, it's red. It's easy to kind of report that way, saying all releases are on track just that the date is moving. Instead of it, you can report very honestly saying it's delayed, right? I had a conversation with one of the business guys out in the Europe side and he kind of mentioned saying, when is it coming 15th of March? He said, thank God, no problem. We have only committed 15th of April to the client. I said, why? He said, apparently everything is three weeks to four weeks delayed, so we always buffer it. That's not how you have to operate because that's not going to beat the competition at all. That's going to be taking something out of your hand. So, not shooting the messenger is one of the key things that a leadership should follow and precisely what I would kind of re-notive. Couple of personal takeaways for me as an experienced sharing report. Of course, this is not something that you should also be taking away. It's though the transformation was successful. I would probably say it still continues the way it is. We have done significant amount of releases. A lot of teams were able to deliver on time, deliver on the quality of the product and everything. One of them is to not do a jail by the book. Information radiators are supposed to be on the walls. Who said so? Can be within the teams. There could be a monitor within the team. You don't need to put it up on the wall so that 10 different people who don't really know what it is in a collaborative open space office, putting a random information radiator doesn't work. The team needs it. The organization does not need it. So, there are certain things that you go overboard and try doing it. There are personal experiences for me. It might be incorrect for you. But then for me, when I do it the next time, I'll probably look at the nuances, the sensitivity of these things, which are gonna be very, very important. Next one is focus beyond the team. When you are an agile coach or an agile transformation person who's in the organization, your focus is few stakeholders who are immediately in the line. The organization chart that I showed you. And the team. 80% of your focus will be just on the team, trying to get them into the velocity and velocity and velocity and everything of that sort. 20% is reporting to the senior management, getting their buy-in, getting their things priorities and going forward. For us, this problem did not start anywhere here or here. It started from outside this agile team. So, what this image really tells, it looks very calm, right? When you look at such a thing, always they say five things in the world is very, very calm. One is the sea. You, though it's very rushy, the lake or the sea where you see water gives you a lot more calmness, especially on a very tsunami type of days, but then the rest of the days, if you stand at the seashore alone, you will find a lot of calmness within you. But there's a lot of undercurrent. I think Vishesh today talked about the iceberg thing, about actually the iceberg moves with the current and not with the wind. So, you have to understand what goes beneath this entire thing and not just your team and your senior management or direct senior management. There are other players at work who could be equally influential and you need to understand that those noises can make or break your agile transformation. Third one is, do not go alone. Not to the sea, not to the beach. I'm just talking about do not go alone into this entire transformation. Fighting a lone battle with 10 different people having 10 different agendas. You need to be very clear in terms of who's gonna be a decision maker, who's gonna help you out, who's gonna hamper this. When you say who, it's not a person. It's the kind of the unit that you operate in. Otherwise, it's gonna be a lot of trouble for going it alone, burning midnight oil, trying to do an agile transformation of 200 people is not so simple when you just have 10 people who will probably not be able to get convinced with it. A 10 is to 200 is not a match, but the 10 people are the decision makers. So, do not go alone into this. Make sure you have the buy-in from the senior management or the management or the directors and VPs and whoever it needs to be. Otherwise, you're not going to be taking your adoption anywhere. It is just, and again, this is no brainer, but at the same time, many of us actually face more problems at this level than just at the team levels. Because the teams, once they get into a rhythm, they understand what it really needs to be to get it done. So, as I said, just three points. One of the important thing, if one thing that you wanna take away is don't be a bystander or don't become one, right? What will happen eventually is if you don't take them along, you are going to be ending up being a bystander. And that is always going to be a problem because tomorrow you will get one person like you within the organization. It's easy for you to be replaced. Four agile certifications and seven years of, eight years of agile experience can get you into any agile coach, jobs which are on the market. But to get another 10 different management teams who have actually built the system is not going to be easy for the organization, right? So, you need to be understanding that your responsibility is to take them along, try to understand that it's a change across the organization and not your change. It is your responsibility to take them along and not be a bystander and not become one. That's the probable one word that I will probably leave you with. You can read about the bystander effect on Wikipedia, but that's more to cover with how the social, psychological thing. But on the corporate side, a bystander is one who's probably losing help because you cannot be supported when the larger group or an important group is going to be affected by the decision. Any questions? Sure, I'll let you take some. Even otherwise, I'm available all five days, so you can catch me up in tea breaks, coffee lunches, please. It worked. It did not work in the sense, you know. It is not going to be viable when you really want to break the system altogether because it's just sacrificing one person is not really always finding it hard. But that's a good approach. Even Alistar, you want to read about the block of Alistar Cogburn. He clearly mentions about this as one of the patterns that is a good pattern to have in terms of it because if you have a eight-member team and randomization comes in, it's always better to shield seven at least and leave this one guy to take care of the randomization because at least you have around 90% of your sprint work getting done. If everything is getting randomized, you're going nowhere. At the end of the day, you will not be able to ship anything out of it. So it is all about trying to get this one guy, typically in organizations, most of you would do, right? One of the person is associated with any high priority bugs or real-time bugs that come in. We call the guys on-calls. So one person is on an on-call rotation every sprint. That's more or less what we're saying. In addition to that on-call, we used to do a sacrifice one person. When you say one person, it could be sacrificed one person's percentage time available but we didn't want to get into this 20%, 30% problem. Really didn't want to get into it because many times they came back at the retrospective and said, this 30% isn't working. I spent my entire 100% into randomization. So we stopped doing this and saying, guys, you guys are known, knowledgeable. If you have free time, do not waste it. Everybody's anyway watching. So the team is, you know, it's self-organized team. So they know that the guy just doesn't have any tasks. So whatever high priority he either shares with them or he or she kind of takes it up, picks the greatest high priority bug and starts working on it. I wouldn't say it's not working. I'd probably recommend it. From my perspective, I'll say I'd recommend it to reduce noise. Yeah, sure, I can. I have one question. Please. Any specific book that you recommend for agile anti-patterns? No, no, no. I think internet has enough things about it. I'm not the, I Google up most of the times by Kindle books and it's a different question but then for this I didn't read any specific books. Narish, you might want to say anything. So I just wanted to use certain anti-patterns because I really started to, kind of it took me a little bit of time to in retrospect I sat down and kind of looked at saying, we did almost everything. It was closer to the safe kind of doing it, right? You know, it's a scaled agile across the company and it is not something that should have gotten into such kind of problems because it was running smoothly. We could see AD releases going away. All the time there's continuously demand coming in, releases going out, demand coming in. So the only thing I sat down and thought was what could be the typical problems? What are the different anti-patterns? And then I kind of said figure it out that these already exist and it's just that I was not aware. Probably I could have handled it a little bit more if I had read through it and nobody gives you a single silver bullet answer for this but I could have thought through it. Probably when you said three member team, my hands were tied up and full. Adding two more people wouldn't have solved the problem but I should have thought about it. So as I said, I won a part of the problem. It's not blaming anybody because the management did a lot of effort to really get things back in place but became a bystander or you end up becoming one or you don't ever end up becoming one. You need to be very careful about what it really means by. Thank you. I'm available for any further discussions and questions also.