 I respect everybody's time, so I get started at 4.30 sharp. Good evening, my name is Venkat. Venkat Raman is my full name. I, till last Monday, I mean this, till this Monday, I've been working with Inmobi and right now, I'm on a break. So, this specific thing was, is going to talk about an organization which is evolved pretty rapidly in terms of number of people, number of releases and stuff. So, we moved from a very simplistic, so that's just a context of the thing that we moved from a very small team and minimal releases to a big bang, hundreds of people and close to around 100 releases at any given point of time. So, that's the entire talk about. So, the fact was, we said, we moved agile. It's pretty simple, scrum is agile, so that's, that's how everybody kind of views it. So, nothing else is really important. All we need is ARC, which is the artifacts role and ceremonies and we just get started. So, we said, okay, here are the few jargons, then you can kind of sell it out in the organization and you can, you know, get started and all the teams get started. So, that's the typical thing and I don't have much to cover. I'll just, since it's a case study, I'm going to kind of walk you through what the organization, how is it structured, what did we try to do and as somebody was pointing out in the morning, it's all about experimentation. It is not that you keep experimenting at somebody else's cost, but then when you say experiment, you're going to be taking care of finding out whether that experiment really worked, do you want to really proceed in the direction and things like that. So, that's all what I'm going to talk about and when we say scaling agile, this entire theme is about scaling agile adoption. So, we had scaled agile, we also had adoption challenges. So, I'm going to cover both of them. A couple of recommendations that I'll have in the end which are not generic recommendations. They sound generic, they are very common sensical, but then there are specific reasons why those recommendations are only being put up. So, the organization overview is like this. So, I incidentally read somebody's quote saying, if this organization is not cross, if your organization in agile is not cross functional, you are dysfunctional. Agreed to an extent, but I wouldn't give it to that fully given the fact that over two and a half years or close to two years, nine months, we worked with a non-cross functional team. It released hundreds and hundreds of feature requests that really need to get out of the organization. For all you know that, we had really the need of being this way. So, the reason to put it this way is also the fact that that's how the organization is structured. Each of them, the reason why I'm stressing this also is this is the picture that you have to have in mind when I'm going to talk through the entire session. That's very easy for you to then relate what I'm talking about. This means that they have, to the ratio of this to this, the team size is a little different, which means it's a workflow. You get in, create a campaign, trying to kind of go all the way till billing. There is a clear workflow which happens and every single team, right from a UI team or be it the serving team and be it the data team, be it the billing team, everybody is what you see out here. And there are slides which will come up as to what we tried and what we had really finally landed up with and it worked fine with us. And as the organization has changed, we are now becoming a little lot more cross-functional or we kind of ended up saying, let's go cross-functional because that's much easier for us to take care of the portfolio. Now, project program and portfolio, some color of the same diagrams. Just try to kind of give you a perspective. Each of the lines out here, the red, green, amber is nothing to say about the status of the project. They are, what I'm trying to talk about is feature releases, which this team, this and this and that team really need to kind of work together to really make things happen. That's the way of how you look at the releases. Similarly, here is, this is how it goes. Now again, the diagram doesn't talk about who does what and who goes first to production and who goes next to production and things like that in a complete chain of events as to workflow who actually lights up in production, who consumes, who's a producer. So each of the team becomes a producer-consumer by itself. Now, that's always going to be the case when you are in a non-cross-functional team. You will have somebody who's a producer, you will have somebody a consumer and then you will have to kind of coordinate and for this managing this, I'll let you know that we had, I was there and there are two more team members and I'll tell you the number of engineers, number of people who are working there when we get to that particular slide. They're just giving a perspective that if you set your framework, if you set your things relatively light and simple, all you need to do is to just get the teams motivated to move in that particular direction. Now, what do we talk about a portfolio and program and project? A project for us was primarily to do with saying very sea-load within a single team. There could be releases which are very tech-related releases where, you know, enhancement or, you know, moving on to a next version of Hadoop, moving on to a next version of, you know, the database or things like that, or moving, scaling your system within your own single team. That's going to be more or less like a project for you. A program could be something like an SDK. You want to ship an SDK, which is like a program for yourself, it's not. It's one of the releases within a big portfolio. So that's what we typically call the program and a portfolio. Portfolio is nothing but all the 70, 80 releases or the feature releases that we typically did at any given point of time. And when I'm telling you that there are 80 feature releases that are running, feature request, or you can call that to be typically, which are running, they are running in execution state. They're not in different states of operation. They are in an execution state and the number is around 80 plus. So that's the typical portfolio cutting across 10 different themes of the portfolio. Now, given that's the case, started off with some executive expectation saying we need predictability into all the 80. This is the number of releases that we are working, but then we need predictability. If not 80, at least I want 80% of the 80 releases to be having clear predictable dates. Build credibility because of the predictability being low, the credibility with the business teams or the field-facing teams where the field commits something to the other person saying, this feature is going to come out in the next three weeks and there is going to be a slippage. You have to communicate back to the field. The field is the person who's facing the customer and the customer is going to be very unhappy with it. So there is credibility loss within the company itself and not just outside. Provide visibility into what's happening, which means to say at any given point of time where will I find information? So again, this is a startup growing at what, 45 engineers and close to around 250 people in the organization. That's when I'm talking about the executive expectation and manage the dependencies that we saw in the last slide in terms of what we need to do and the challenges. And we always, Pete Deemer also says and a lot of other people say, start with the pilot project. Now in this case, I don't have a pilot. I can't pick up team D and say, let's go agile. Let's do your backlog, let's do sprint and stuff. What happens to the rest of the people? They are all chaotic. They will be working in their own stuff. They wouldn't know. So there is no opportunity whatsoever except for one or two teams who had very minimal work that we could kind of negotiate and get it done. There was no possibility of picking up a pilot team. So it is like launch it across the 45 people at one go, which is like six teams. 45 people, 16 at one go. Okay, who all do we need in the release? So when I joined, I was the first project management hire. I called in a person say, let's talk about this release. He'll say, I'll call that person also. Then he brings in. Third person would say, he's also required for this because the end point is that guy. So it became into a point where we started to do a searching of people to see which who all need to contribute. Now it doesn't mean that that's how the organization would be when you are in a pretty startup mode. You know, you kind of huddle. You decide something that you would do and then you move on to your desks and you start working. But somebody needs to really tie these pieces together when you are having 15 releases at any given point of time. I'm talking about 2011 June. I made this change long, sorry. I made this change long back. I'm too aware of it. So the code was lying according to lean principle, and I think that's not being used as a waste, which means somebody has done the code, shipped it into even, you know, SVN or Git, but it's never been pushed to prod. It's just sitting right there. This is my, I'm really sorry. This is my overall priority, but this is my team's priority. So when you saw those number of teams, the reason why I asked you to memorize the diagram, this is the overall priority of the feature release, but then my team is working on something else. I have clarity on my team's work, not sure when it's being done in the other teams. This requirement is not yet frozen. So we didn't want to pick it up till the time somebody really gives it. Too many meetings. Somebody had kind of told the organization or anybody who's walking, I'm saying, oh, we're moving to agile, which means half the time we'll be spending in meetings. So that's the typical mentality people came in with. So I had to really write an email to people saying, here's what you spend in a week, here's what you spend in a day, beyond which you won't find any meetings in your calendar and really people started to believe when their calendars looked empty. And we also started to set certain timelines by saying, let's not put any meeting between 11 and 3, let people work whatever they want to. You want to have any meetings, we'll do it a little bit above and beyond that. I just merged this into a trunk. You want me to roll back? Which means say, oh, you guys haven't picked it up. I have just rolled it into my main branch. So these are the certain challenges that we face because of the problem of no pilots, because it's not like we can't get everything and we have to bring people together and make this. Again, I've mentioned things which are not probably uncommon, it's more or less what happens at work for you. So the meta issues that started to kind of realize was no form of prioritization criteria as well as prioritization. So there were people in the organization who really are kind of in the front-ending with the field. So they used to kind of give the prioritization saying, if you don't do this, we are not going to have a good face in front of these things. We're going to lose this particular account, we're going to lose this, we're going to lose that. So all that prioritization came up overly and there is no specific criteria which is written on investment as a criteria or be it, you know, number of dollars which is going to be saved and things like that is going to be the criteria. Then there were other meta issues such as changing technical contacts between teams once finalized. And now the word contracts was little, we had to put it in because once the producer has decided a contract, a consumer has to kind of, you know, adhere to it. Similarly, when that guy becomes a producer, the next guy is a consumer, he needs to adhere to the contract. So the word contract was actually put it in place in 2011 saying it's not going to be agreement, it's purely a contract between you guys. You need to kind of, you know, ensure that you are there to it. Technical infrastructure, not really there. Some teams were really doing it, some teams weren't doing it. So we had to kind of, you know, standardize saying everybody gets onto Jenkins, build has to come from Jenkins. So operations had to put their foot down saying unless the build comes from Jenkins and I have a link, I'm not going to push it into production. So it started from there. Of course they became the really bad guys in one of the meetings and saying operations are like putting us too much of pressure and stuff. We said, let's do this for two months, let's see. Let's experiment. We started to use the word. Let's experiment. And then the moment they saw the production box coming down, the number of rollbacks and the production coming down, the operation started to publish data saying two months back here are the number of rollbacks. Two months later, because of Jenkins, here are the less number of rollbacks, people started to believe it and they started to make it a way of life. The moment a new project started, first thing is they'll assign a guide to sit next to them, finish up the Jenkins setup and then they'll try to get that particular thing. Communication within the team and beyond the team, these are all meta issues and goal of the organization was the goal of the team. Kind of, you know, you call this in Corbett, one of the nice thing as, you know, cascade, goals cascade. So you need to have the goal of the organization really cascading to the goal of the team. Otherwise what happens? They're all sea loads. Somebody talked about the sea load. Harry talked about it, right? Remove the sea loads. Otherwise what happens? Everybody is sitting in one corner of the place. They have nicely taken the process to there, suiting them and saying, 10 days you told me you won't disturb me because you are on a sprint. Now let's not talk about it. I'll talk to you in the next sprint. So that's not the point we're trying to talk about. Guys, if there is something that's going to break the goal of the organization, you continue doing something else, it's going to really be not really working well. I'm missing the big picture, which means to say everybody who's actually in that columns that you saw on those teams were only focused saying, I will take care of my stuff. I really don't know where it's going to affect. Who's going to be pushing it to production? I have no clue. I have pushed it. As he said, I have pushed it. Now it's operations case. Even now there are certain pockets where people would kind of go and do that. They keep saying, sorry, you wrote the code, you are responsible for it on production. Operations will help you to push it. They will help you to get your graphs ready they'll help you to get your monitoring ready. Sorry, they're not going to be owning your code. So the guy who's on the on-call really gets woken up and not the off-sky. Both of them are sitting at the on-call at 2 a.m. if there is a problem. So that's how we have kind of, you know, taking care of the big picture. Visibility, this is the reason to put a couple of stars and I have a few other stars coming in. Many times, you know, you think that too much visibility. Let's take this room, bloated with post-its and bloated with graphs. You know, burned down charts and everything. Without the people really knowing what it means, it's like going into an art gallery, which is a modern art. I'm not joking about it. There are people walking and saying, that burned down is not good, which team is it? Something like that. Don't even come to them. They have their own problems. They are blocked on some other team. You have to stand and explain. The person has set up a perception in his mind. The senior management has set up a perception in the mind saying the burned down is bad. Second time he sees the burned down same way, this team is really not doing good. Of course, the team is actually really, really doing good, but just that you are not able to interpret the graph correctly in terms of what they are trying to do. They are blockers, which only the teams know and they are working on it. So, visibility too little was the concern that was raised when I joined, and visibility too much suddenly became a point of comparing two teams' burned downs. So, you need to educate. I didn't have the time to really go ahead and educate every single guy in the organization. We had to do a lot of things on the job because we were just running full steam in terms of what we need to do. So, at that period of time, you need to do that, you know, unlearn and relearn, and a lot of stuff that needs to really happen. Lack of simple process to tie the entire piece together was clearly there. So, a lot of people had already been on one-week sprints, but then their sprints were very different. They just pushed everything, whatever is ready by the end of the week, and it wasn't the committed thing that really went out. So, if something slipped, there was not being even communicated. There was not a process to clearly do this is the way we will do. Some people skipped code reviews. Some people had code reviews very diligently. That was blocking a lot of stuff, and that guy wasn't even aware that the code review was sitting on him. So, these are the typical meta issues that we have found. And one other thing that came out is what is the value of doing this versus that? So, which is not just the prioritization value. I am talking about why should I do this? Why should I update the APLM tool? What is the value of doing this versus what I was doing before? A lot of other common queries. We are just fine. Why agile? We don't need anything. We like doing every week. We are doing releases. There is a lot of resistance in the organization. I am a developer. I am not sure when will this hit production. Maybe I will know a couple of things which ideally we spoke about. Why is team to burn down things. So, the first and foremost thing that was done is to do with gap identification, which means to say there is inter-team dependencies. There are two guys whom you saw. It's not about people issues, but then since they had their own tasks stuff, but they are checking into the same code base and they are not talking on a daily basis. Inter-team dependencies because he has to either merge on top of the other guy or that guy has to merge on top of him. Absolutely no communication till the date really came close and they kind of put their hands up saying we have not merged. So, that slipped. Cascading effect because he is a producer. So, the consumer slips. Further consumer slips. It just moves on. This release because this guy is delayed. He was planned in some other release. That is also going to get delayed continuously. Inter-team dependencies we spoke about. Visibility at all levels. We are figuring out because this was causing a lot of perception which had to kind of be broken by regular status reports and stuff which is very minimal. No funky MS project reports and stuff. It is a plain simple Excel that was used for six months. Just simple Excel for management because we had no walls unfortunately to do post-its. I mean the walls were very away from even touching because there was cabins and stuff. The office space was not set up for agile and it was rented off as all this stuff was a problematic breaking down wall. So, wherever we could find, we used to go ahead and block the room and kind of do the white boarding. So, that is something there. And the plan of the record which is what I was trying to talk about. The single unified view of all the 15-20 releases. Where are they? So, we had multiple states of things. One is called in, you call it, the number of the release states were also defined because a lot of people saying nobody has started coding on it. But how are we going to say it is an execution? So, we had to define certain states and saying we pipeline the release for approval. The approval is done by the chief product officer or the head product head. Also with the chief engineering guy. So, this is now approved. We get it into ideation. I will show you the couple of people who will be involved in it. And then it moves into execution. It moves into under review. And then it moves into closed. Which means these are the specific. We also had to write up and educate people saying you are not in execution right now. Let us not call this and create more panic out there. So, there is a lot more processes, the lightweight processes that have to be set up. And again, none of the SCRAM or XP or anything talks about these things. I am just trying to talk about these are all peripheral program management office things that you still need to do even being an agile company given the fact that this can kind of ruin your entire rollout. If they are not convinced that you are doing a correct job or you are giving them the visibility, no support. Absolutely no support. You will be on your own. You are going to be kind of burning all fingers. Agile SCRAM training and gradual adoption focused on a critical few first. When I say critical, those teams if they delay because as somebody said, it took two days for deployment. We had a similar situation. Now the deployment is three hours. Of course, it requires three hours because we have seven different sites where the deployment servers need to be brought down and brought up. So, that is also being worked on. That will be becoming one click install. So, all that stuff need to be really going ahead. Now, I will just stop here and kind of give you a perspective of what all experiments we tried. We move into the experiment part. Now that we saw the team diagram. We had multiple ABC, cross functional, non dysfunctional teams. Cross functional teams. So, we had to try a lot of approaches in terms of how they will work. First thing was a virtual team. Trying to say, here is the PM who will write up the release, the product owner in terms of Agile. The product manager will write up the release, PRD provided clear survey, I mean, clear success criteria and stuff like that. The architect plus PM plus couple of leads who are on the team. Again, non hierarchical doesn't work. In India, let's be very honest about ourselves. We still have titles. We still have the groups. What we are trying to say is, we don't want to bring the entire team to this meeting. So, these three people really sit and understand when we say stack. So, you looked at those stacks, right? The diagram that I was trying to talk about. These three people really sit and think about which all teams will contribute to this release. And then they kind of break it out into the story. So, this becomes an epic. These are all the stories under the epic. Automatically, if you see, this gets auto populated into the team's backlogs. So, the moment you create a story on team A, that goes into team A backlog, team B backlog, team C. So, if you really look at it, team A's backlog is an allocat. So, if you go and order for a roti basket, that's how they get it. They're not kind of in a product teams. They are not feature teams. They are actually a team who's actually joining out in terms of how you want to kind of, you know, get the feature releases really out. Now, this has changed over the last three, four months in terms of how we need to do it. But as a case study, I'm trying to represent as to how we had to do it. And I had no chance of kind of, you know, reworking these two feature teams. And we tried that also. I'll show you it in the next slide. What happens is the auto pushes to the stack's print backlog. They get to done. Whenever the teams really get to done, these virtual teams actually used to sit together in their cubicles and one person from here. This each of them is a release by itself and they get to do. Next is, we said stack sprints, which means to say all of them, when each stack completes, they'll just go ahead and make dark releases into production. We'll try to kind of, you know, not have the virtual teams. They'll be all sea load. They'll only meet when initially when the requirements are going to be clarified. But then they are on their own. They have their own 10 days sprints. They'll come back and let us know, they'll let the PMO team will coordinate in terms of when the things would be deployed to production. Might be dark releases, which means to say nobody's consuming that API, but my API is live. When you start consuming, it'll work. This was the other approach that we tried to do, given that a lot of people had raised the noise and saying, I'm attending too many, in this case, I'm attending too many virtual team meetings. Like the same developer is sitting on three releases and he says, I'm attending three meetings in a day. I don't want to do that. I want to just do my teams, my stacks, stand up. And I'll give you the update. PMO team will take care now. So that's one of the approach. Second approach was stacks sprints. Now it's not that all three, I'm going to show you the next one. All three was done in like today morning, then we scrapped this and did this next day morning and then we scrapped it and say Monday morning we'll do it differently. No, it was done over a period of two years. We had to try experimenting multiple hybrid models that really worked. Each of them had their own glitches. I'll explain to you as to why, what happened in this case. In this case, as I said, the biggest advantage was that they could work together, they had the common goal of the release, they understood what the release is all about and they could work together. The other disadvantage of the same guy, if he has just two days of work in a sprint, he will be working on four different things. Which eventually he will still work on even in the stack sprint, but then he will be working, he or she will be working on four different things and he has to attend four different standards. Which means to say, you know, one hour, one hour first is going to be in the meetings and things like that against the 15 minutes. The next one had a problem where there was a lot of sea load approach. Like I am done and then it's all falling, if I have to take 10 days off, I had really had three members in my team and it goes for a big task because I was not there to coordinate, so I have to rely on the engineering manager to take care of stuff. Everybody again looked, in the T approach they looked at their depth. The breadth was not very much considered because the incentivization was also not very clear on terms of whether it is a T or a, you know, it is going to be the breadth. So, you are always going to be very very focused on your team, you are going to be taking care of your team and you are still going to be kind of raising flags in terms of how you really want this to be. So, we arrived finally at something to do with a mix of both. Which means to say, of course there will be sprints which will be stack based sprints. There will also be virtual sprints, virtual teams. They can sit in their locations, but then we will have release based stand-ups which then will not be on a daily basis. It might be twice a week. Given the fact that then we started to use a lot of other communication mechanisms, like currently or on JIRA, we said people have to extensively start communicating there, but it is mandatory for everybody to attend the release stand-ups that happen, you know, every at least twice a week to raise any flags. Usage of communication in terms of messengers in terms of saying, I am blocked, who is going to unblock me or call out clearly saying, hey, team B's, this particular person is or you create specific chats which are going to be doing that. So, we kind of worked around that particular piece given the fact that that is how the organization is structured. You have to work around it. Either you kind of break it completely and say we will make feature teams and then every problem will be solved under the sun. Now, when I talked about this grouping, one thing that I am just latching on to what Harry also said, we made sure operations was part of, Dev QA was anyway part of the team, but operations was part of the sprint plan. Operations team were part of the sprint planning. They started to love it because they knew what was coming. They went ahead and even ahead of it, they went ahead and coolly did all the monitoring in place, kept their graphs ready. The moment data started to flow, the graph started to populate. Within an hour of production push, they used to come back and say, breaking, we are either rolling back or rolling forward. Who is going to push it? So, that particular thing was not happening before. Operations took their own time. They were not even aware. They were just given one ticket saying, push is to production. And then they kind of were the bottleneck and saying we are not able to understand what you are trying to do. Why are you making us kind of do this? So, slowly in over a six month period of time, operations were part of the sprint planning and now they are part of the team. So, that is how we try to kind of do in terms of what we need to do. And we use both push and pull, which means to say in this case, this becomes your push, which pushes to the backlog. And the pull is going to be on the Kanban thing that you just probably heard was hearing the other side in the ballroom. We also had, so, we still use Krumban, which is what we are trying to talk about. Krumban is, how we are using Krumban? Most of you would know what Krumban is, but then what, Krumb plus Kanban, what we are trying to do is, we are doing a push, which means say the release comes up. PM writes up the release. The teams break it out into stories, pushes automatically to the backlog. This is your sprint backlog. This is all your sprint backlogs. And maybe this is your product backlog or you can call the team backlog. Eventually out of this, you will do a sprint backlog. So, team A might have 40 items coming from 10 different releases. They will pick up the top 10 or 12, which they need to really develop. That is what their sprint backlog would become. Now, when they really start their sprint, that becomes an engineering focused stuff, is where they will start using their Kanban board in terms of trying to see where the bottleneck is. Many a times, the developer is also very busy and he or she is not able to do the code reviews. So, code review gets into a little bit of, it does not move for ready for QA until, so this was one of the things snapshot I took it out, but a lot of people are saying waiting for code review, waiting for QA, waiting for deployment. So, code reviews were starting to get the blocker. So, we clearly said moment a code review pull request in Git comes in, whoever has been assigned or who wants, who is actually free has to pick it up. Or in the stand up, we kind of discuss that saying, guys this has not been picked up, somebody has to pick it up. So, they immediately kind of put their hands up and saying I will do the code review on this. My code review somebody needs to do, the guy will say I will do it, I will do yours. So, it just goes in that fashion. So, we can kind of minimize that number of working progress limits that we had to clearly get there. All of you would be able to see that it is all infinity right now. This is a snapshot taken pretty long back where we did not have any whip limits. I think when James, the Kanban person clearly, Anderson says that it is a Kanban without a working progress limit is no Kanban. So, but at least we had to kind of get the board up for people to visualize some, make it visible. That is the whole important idea behind what we are trying to look at. So, talked about this team is about scaling adoption right. So, you know scaling agile. The duration what I am talking about in the case study is between Q4 2011 through Q4 2013. The team members moved from 60 to 200 in a span of two years. The company had 200 million funding. So, we had a lot of ambitious goals given by the board. So, the teams, I am talking only about the engineering plus technology which is ops in terms of it. There are still people about architects and lot of other people who are part of this. 200 plus if you want to really take it. Team size, teams increased from 6 teams to 14 teams. Because we started to have new business lines, lot of new portfolios, so new teams were formed. Existing people has 2, 3 people have migrated and new people are hired so that they knew the system. PM team increased from 4 to 10. We are going to have more feature releases coming in. Everybody is going to write their own 5 or 6 PRDs asking I want to get this done. So, eventually when we sat actually in a quarter to really review, there were 130 asks per. Really had to do a filtering for 2 days to really get it down to say 45. Saying less of them is not going to be done in this quarter. And out of that 45 eventually 22 got done. 22 got prioritized and got into the queue. So, that is the PM team increases. Consequently, the number of releases moved from 15 to 45 to 80. So, scaling is not just one directional, right? So, here is a team scale, number of team scale, PM scale and the number of releases suddenly started to blow up. And they were brought on a different business line. So, one business guy is unhappy that his thing is not getting serviced. In multiple forums, people make a noise saying, yeah, yeah, all love goes to that portfolio A. I do not get any love. So, immediately the next day meeting would be called saying, why can we kind of make two or three of these? This portfolio B items prioritized. So, there is a dynamic prioritization change there which we have to fight out from a perspective saying, you guys are stopping in midway. There is going to be a lot of flurry. There is going to be a lot of flutter happening. Let us kind of take it cool. The reason for portfolio B not being happening is XYZ. Let us not kind of take one instance of a meeting to kind of change scores and things like that. So, the good news is that the first framework that we have just put out saying, there will be a PM who writes up the stories and just gets into the backlog and gets moving. Seamlessly scaled, any number of teams added, any number of people added, it just moved on. No changes were done except for the fact as I said engineering practices were expedited because that became a super, super bottleneck for us. Builds taking time, all the other stuff, including continuous integration taking time, all the stuff really where the fundamental problems more than prioritization or backlogs or the team. So, that is one part of it. And what is the current focus is value-driven prioritization given the fact that there are 10 product managers and even more. You cannot have 130 items. Somebody has to kind of really do that value-based prioritization saying, this has a higher value than that. Give me that particular value, then you win. Otherwise, you are not winning in this particular meeting. Capacity visibility and planning, given the fact that you would be surprised saying why was the capacity not being really bothered about. What we ended up doing was relied on the team to say, here is the 10-member team, here is your backlog, here is the priority, let us get started. And we did not do a, I mean we kind of, you know, started even not look at burn downs. We started to focus very heavily on done-done which is good to say, are you pushing it to production? Has the code review done? So it is more towards to do specifically non-tool-based, tool had the story in it. But we were not looking at the burn downs and saying, what is the, why is the burn down low? And after a period of time, the teams themselves started, stopped to look at the burn downs. They started to rely more on team communications and in terms of, you know, how the releases were being pushed to production faster, how the dates were being met. And it went into a point of how fast the teams operate. Aligned teams to business units, that is exactly what we were trying to look at. Continuously improve engineering practices. This is something that I cannot be without stressing. I mean, that is 80 percent, I would probably then, I will stand here and tell that 80 percent of blockers were due to engineering practices and engineering blockers. Product managers were very hardly mentioned in terms of they being the blockers. Every single engineer had anything to do with engineering being the particular blocker, adapts Crumban across the entire organization and I will show you the six print planning that we are trying to talk about. Now, we could come back and say it breaks agile saying, why should I plan for six prints? I should always be working on freshly looked at sprints every single minute. What we are trying to look at here is not planning. When I say, it is not committing for six prints. It is about committing for the first or maximum two sprints and bucketing for the next six sprints, next four sprints. The reason is, you really do not have otherwise we have to land up in the same problem. I do not know when that other team is going to pick up. I really do not know when, I will be done here but I really do not know when this guy is going to pick it up. I really do not know when this team N is going to pick it up. So, what we had to do eventually was to, we had two sides of the wall in the room and one side we said, write all the apex, write all the stories. Stories were on team A, B, C and D and believe me, I would probably recommend this very heavily because it worked. Almost everybody who came into the room and left thanked my team as well as they were talking about it for months to come saying, that particular meeting I would love to have it next quarter. I will explain to you how this particular slide I will stop here and explain a little bit because this is something that you can even do irrespective where, you know what kind of teams you have and things like that. It is very, very essential that when you have especially dependencies making this kind of a plan and this kind of an execution is going to help you out. Trust me, this will not remain the same in three days. Agreed, but you already have, you at least have something on the wall. Rather than somebody giving you orally and committing saying I will pick it up next print and you will think saying next print starts on 20th. This is going to start 20th and no. And then you will have to follow up with them on the next print. Now what they are doing is they are at least putting something on the wall and they are going to give you if something moves, you are going to be knowing if something is moving. What happens is on one side you take the A pick, 14 A picks or 15 A picks whatever you want to make all the team A, B and N stories whichever teams are going to contribute. Then take those pieces up on based on the priority. Take the other wall and make the team based allocations and move each of the story to this side. Eventually what happens is you will get up all these are stories. This is a story for release one. This is a story for release two. You can see that release one is being done here but it is not being picked up by these two teams here because release two probably was extremely important for the team. So they had, I am just giving, I could have put on like 10 stories out here to complicate stuff but I am just giving you a pictorial view. Now what happens is at least for you this becomes your Gantt chart for people who have been in the traditional side of things and even Ajayal, I am not saying that you shouldn't use Gantt chart. I am saying this is, this becomes your clean Gantt chart. It finishes and goes out here. Maybe there is an end to end happening at that end. So you clearly know that when my sprint three which is going to be 45 days from now is when this release is going to light up. That's your probable 50 to 70% confidence timeline if this plan is executed. Now when do we do this? We do it once when you gets a set of priority from the product, you do a particular meeting and then there are 40 or 30 releases which have been approved for execution. You take that, you do this planning. Now things would change when this guy for example could not take up release one here. This slides down. You kind of figure out then kind of do this exercise week on week with that particular person. Make sure the communication comes back to you. So this is a very simplistic Excel based thing that you could do. Of course the translation, I mean all of this would be eventually in your own Ajayal life cycle management tools but I am talking about first one day planning with all people in the room when I say all, at least the engineering managers of the leads in the room. Trying to get a perspective based on T-shirt sizing in terms of how long would they take? Would they take release one? Is it going to be one sprint work or is it going to be two sprint work? I have just not depicted two sprint work. When you are saying if it is going to be one sprint work or two sprint work they will come back and tell you. Because a simple thing, there is one of the teams always used to have two to three day of work. That's all. One sprint work is maximum two to three days. So they always will finish it within a sprint but there are teams who will take three weeks. Some teams will take even six weeks given the fact that they have to make a service. The service needs to be then kind of consumed by somebody else and then they have to really validate, get the data, make a lot of UI changes. That team owned both the UI as well as the service so it took them like three to four weeks. So they will not be able to finish it within one sprint. They will be able to finish it only in two sprint. So they come and give back, get that story into multiple stories which can be consumed within the sprints and then they show you saying this is release one, this is release one again here. This is a story of release one. So this is, again I just put out a simplistic one. You could do it on a whiteboard. I mean post it. You don't need to really use a tool but eventually you can translate it here for tracking because the post it won't remain in your room forever. So I am moving on to the recommendations. I will take questions at the end of it. First things first, if you don't have this, whatever you can do in the world can never kind of you know succeed. For that you really need to know you have to consistently get the buy-in from them. It's not like you have handed over the baton to you and you can do whatever you want to. It's consistently that you need to kind of you know get the buy-in by finding out what exactly are they looking at what data really they need, what data you need to project, educate the people in terms of what it needs to be. Solve the right problems and think what you think they are the problems are. You go and put 50 different dashboards for the consumption of the team but the executives are completely not happy with that they want a different dashboard which gives them a confidence level in terms of something that is really happening is what you need to be. And there will definitely be criticisms and feedback so you need to be really be taking them with an open mind as well as with a lot of at times with a lot of pinch of salt where you know that they are not coming in with the right data they are probably having perceptions by giving them the right data. As we saw it right so there were just glimpses of the experiments that we did there is quite a bit of experiment that we had to do from a perspective of what we need to do. Choose the best that works for you keep it you know make things happen that's the whole point right saying just because you don't believe in it saying hey this won't work and somebody else doesn't believe in it you can't just drop the ball you have to convince them to say let's try this. So some teams really came to me and said let me go Kanban. I cannot do something in 2 weeks you are making me split a story so for even a beat rally or beat jira beat any other tool if the story has dev tasks and QA tasks and stuff and dev and QA cannot finish within a sprint you have to make 2 stories because the stories cannot span between sprints. It's only the task that will span. So you will go and make part 1 part 2 and people wonder what is part 1 part 2 so all these answers you have to make sure that you have in your mind so they allow a perception of the tool itself saying the tool is not good man. So the fact is all these perceptions you have to beat in terms of trying to experiment saying guys you want Kanban okay fine given that it has no boundaries but now when you are going Kanban I need clear dates from you because you are not time bound you can't take a story and tell me no date on this story. So there is you have to kind of do that experimentation do that play with them make it happen they want it you have to give it to the team don't give it to them they are going to always feel that saying this guy is thrusting something on me I am not going to be happy about it focus on architecture and design this is one thing which is you know seriously missed out you always end up after coding suddenly it breaks and say realize saying our system was not scaled for taking this traffic this QPS is what we can support this boxes support this QPS this is not going to be beyond this nobody had thought through saying this architecture or this particular stuff this is the next number of traffic hits on this particular box so that's something that we need to talk about it general recommendation is that you have your architects think about every major release that's happening work left shift which means to say you do a spike sprint you need to understand certain graphs they will do some kind of tweaks they will make a call to the new Hadoop API all that stuff they will try to do and say this works this doesn't work for this to happen it will take us two weeks so you cannot release anything within two weeks till we go live so all that stuff you need to coordinate with the architects who might not be part of the engineering team in many organizations they are part of the separate technology organization you need to work with them bring them ahead try to kind of you know do that particular left shift for them give them that particular bandwidth don't commit anything without they giving a sign off that's another reason why you saw it's a PM architect engineering person all three together discuss whether this is scalable or not scalable the moment you drop the architect from the equation you're going to be running into a problem later and they'll say it never came to me nobody kind of told me I would have told you immediately that it is on scale so these kind of things we should kind of you know avoid the other one is yeah I have spoken by Harry I don't want to kind of you know talk about it this is a very nice article which has been written in the site called dev2ops.org it's called the wall of confusion just finish something throw it to the other end keep throwing and then they will kind of catch it and they will push it and something will break everything where it completely goes loose so unified vision but individual goals you cannot have an engineering goal being thrust on an operations goal for them uptime of 99 point xxx whatever it needs to be is their key goal engineering does not probably have that goal they have x number of defects less or you know 0 defects and lot of other stuff operations why should they be measured on a 0 defect goal right so they will be measured on their uptime so they are more worried about 0 defect code right so there is all of these things happening so you have a unified vision in terms of keeping this uptime in order to keep this uptime everybody has to have a unified vision at the same time having individual goals that it needs to be there and Brad don't touch this is my territory you know many times ops won't give you any access of the pseudo access that's because of holy grail basically somebody will be really annoyed if you ask them for a access into the production boxes that mentality I have seen over at least 6-7 years in multiple organizations it's very hard to break because you feel very close to heart that I have admin access I mean I am a Jira admin I don't feel anything about it it's a burden on me because every time there is a small field that has to be created it will come to me it has some new user has to be added it will come to me so it's not a very enjoyable job to have an administrative rights and being very happy about it it's just a matter of you know not my territory no it's your territory you need to understand what's happening on the other side also shift left which means to say bring them in get the operations guy also in the sprints get them even working ahead saying hey you know what we need an upgrade of scribe we need an upgrade of XYZ open source stuff can you guys work ahead of it and try to get this for us collaborate I mean I don't want to kind of you know focus on problems and people many a times it happens that there are people perceptions that lead to you know I don't want to talk to this guy so I don't want to code merge now I don't want to talk about it till somebody really hard really go and do a code merge on top of each other so that's not what we really want to do that as I said right many of the recommendations are very common sense but then these I found as fundamental barriers to really get things moving in an agile organization quality which is one article in Scrum Alliance one of their one of our major sponsors please go read about an article written on definition of done is very beautiful beautifully given the entire gamut of stuff that needs to really happen measure which means to say just keep that keep pretty simple in terms of what you want to measure you don't want to kind of go and give every single ganchard every single burned out burn up all that you know all the jargon just because you want to show your agile you don't need to really do it this is one of the nice things that you could look from so many things that you could do and give people as a matrix just to please people will give you a nice weekly report which has 15 different matrix who is looking into it nobody at the end of it if you look at it test coverage, escape defects performance defect ingestion story point velocity available capacity stretch factor time spent versus bugs versus feature what is your cycle time cycle time is important in our cases where you want to understand when the release really came in and when the release started in execution and when it when the last guy really pushed code to production team A started to work first but team B is the final guy who pushed to production is our cycle time you want to kind of really look at those kind of matrix then portfolio level executives might want to look at a pie chart in terms of saying in this portfolio how much of ours are being used up are really getting the return on investment on that is 50 member team really required to do this portfolio is only 20 member required all the stuff would really come in of course these slides will be available I believe so you don't need a crowd sourced thing that I had used so I want to give the credit to lot of people who might have who would have joined to this crowd sourced in agile boot camp that really happened keep them visible which is what even the last session on Kanban was trying to talk about saying keep them visible if you want to show a problem keep them visible that is extremely important out of sight is out of mind which means to say if you don't put that blocker out on the page or block it you are not going to be bothered unless otherwise there is a red button you are not going to be really bothered about it many tools just if you block even a single task it goes all the way up and blocks the release so you could kind of you know use simple excels all the way up till post it really make things happen of course the oh you are doing agile okay fine I know scrum that is about it so that is the typical way and that is also correlated with the survey that recently came from version 1 which says 54 percent people still use only plain simple scrum and XP is very much down at 2 percent this is not a very old one this is actually a 2013 one hybrid which is scrum XP hybrid some kind of continuous integration I will do some code reviews and code refactoring stuff whatever I need I will do no harm it is good at least some this numbers have actually increased from the last year I have been tracking this so I know for a fact this was somewhere around 8 percent has become 11 so it is 52 became 54 so it is still growing up and I am at more or less at the end of the slide so just telling you that the survey also confirms the biggest biggest bottleneck is ability to change the organizational culture and we faced it too trying to fit agile into a non-agile framework as you see the management support is pretty highly rated as the barriers if you do not have a management support you are going to be really really not doing well then lot of other stuff which is you know project complexity personal right sales fine but then first thing is changing the people's mindset is one thing that if you really do it you are more or less one half the battle at that particular instant for that you have to show them a lot of value you have to show them that it is easing their life and not kind of complicating it by making you feel 10 different tools and stuff this is my summary slide which talks about saying if you are an engineer by any chance still an engineer your problems are largely technical focus on them do not worry about too much and use the guiding agile manifesto and principles do collaboration do all that stuff meet your PM talk to them using the agile planning and estimating techniques please play an important part when you are doing story planning story point estimation randomly do not give 13 randomly do not give 8 think about whether it is really an 8 in comparison with something else some games also become like a game because we have called it a game right so people just come in and played a game but it is not really a game you are a commitment at the end of the week end of the sprint planning line managers and again what is my role that is a big peat has written an article about managers in scrum management is please insulate the engineers from all the prioritization noise that you are creating that is a recommendation that I would probably give saying you do not need to at the end of the day he is not going to deliver because you are going to be randomizing that is him or her which is going to be the thing so I the expert in anything was once a beginner so please begin now if you have it from my perspective it was phenomenal journey for us with just 3 people with 180 to 200 team members with 80 plus releases we still made the ship not like a titanic but then it moved that I added 10 more people that moved faster just a matter of what I am trying to say is keep things very very light visible I mean whatever you saw is what really happened there are no bookish stuff that I have put it in all the stuff that I have written it please what happened over the last 2 and 2 years and 9 months out there so that is all I had to say today hope you enjoyed it and thanks Ellen for providing me the laptop today otherwise I would have probably not been standing in front of you today thank you have a nice evening