 All right, welcome. Good morning, everyone. It's still morning, right? So this talk is Scaling Agile, a guide for the perplexed. That basically means what? Who's perplexed? I need to hear somebody. Confused? Need something to look beyond the basics. So what we're going to do is to peel back this topic of scaling Agile. You've heard, you just finished hearing from Scott Amler, who is the Disciplined Agile Delivery Framework. I see the folks from the Scaled Agile Academy over here. And we have these different frameworks for scaling. And what we need to do is to figure out a path that will allow us to build a foundation for scaling. If you're doing team-based Agile, how can we start to go beyond a few teams, multiple teams to several teams together, maybe several projects, several programs, and maybe even on to a portfolio and such. So a few words of introduction to myself. I've been in this field in the Agile space for 16 years. Did I do something? Okay. 2016 was the 16th year of my Agile journey. And over the last few years, it's been increasingly concentrated in the space of taking Agile beyond the team to business agility, if you will, and also to helping organizations scale Agile. So without further ado, I'd also like to find out more about who's here in the audience today. So let's quickly self-assess on a scale of one, two, and three. If you have been doing Agile for six months or less, let's count that as a newbie, like level one, you know, novice level. So let's see the hands, show of hands. Who are the level ones? Any level ones? Okay. Level two, six to 18 months, you know, six months to about a year and a half. You've done a few projects. That's an intermediate level. That's level two. Who are the level twos? Fantastic. And level threes, everybody else, all the experts in the room. So it looks like we have our even distribution between the level ones and twos and threes. So I'm going to have to massage my talk and make sure that I cover a few of the basics. Some stuff for the intermediate and definitely some things for the experts among you as well. So let's start with some of the basics. You guys know, the twos and threes, they are intermediate and the experts know that Agile is not just one method. It's a term that applies to many team-based Agile methodologies. You see some of them on that chart, extreme programming or XP for short, SCRUM, Kanban, and now you're in the older, further along in the way we used to see things like feature development and such. This particular survey, the state of Agile development survey has shown us that even today at the team-based level, SCRUM continues to be the predominant methodology. So you were looking at about 52% or so. More recently, the question has become, how do we take team-based Agile with SCRUM or with Kanban or with some hybrid thereof, like SCRUMban maybe, and scale it? And so we've seen the emergence of scaling frameworks, like the discipline Agile delivery framework, scaled Agile Academy, scaled Agile, and also SCRUM and scale and such. So we're going to have to talk about how to make a path for demystifying some of these. So here's our agenda today. We have about an hour, 55 minutes or so. I want this session to be interactive. So at the beginning, I let you off when you didn't answer a question. But as we go along, I'm going to have to ask questions and I'm going to stay quiet till you answer. Is that okay? So I have to ask you one question to test this out. Does everybody have a conference bag? Put your hands up if you have a conference bag. All right, very good. I want you to open that conference bag and look for a book that says, Scaling Agile Eileen Jumpstart and Hold It Up in the Air. You might not have realized it's there. Not the happener's one, though that's also a good freebie that you can take. And if you don't, there you go, hold it up in the air. So this book that you already have in your bag is going to form the basis of what we're going to talk about today. So don't fret if you don't see the slides or you don't want to keep up with the slides and such. In that book, you'll have everything that I'm talking about today. Does that look good? So let's ask the question. Everyone got the bag? Everyone got the book? Okay, fantastic. We're in good shape. So our agenda is why should we scale? Let's answer that question first. Why should we scale? We have team-based methods. We're doing agile, maybe scrum and it's successful. Why should we scale? We shouldn't be looking at scaling agile methods for its own sake. Let's figure out what is the business rationale for scaling methods. Once we can establish that, then we have to say, well, how can I jumpstart in my organization? How can I get ready? How can I move forward very quickly with scaling agile? And I'm going to present to you an overview of such an approach, which is also captured in the book, and also an iterative scaling method or an approach, if you will, to scaling that has these three components, assess, align, and accelerate. And then we'll look at reflecting and progressing and then I'll leave you with a summary and next steps. How does that sound for a plan? Good. Okay, very good. Let's move on. Why scale agile? It turns out that if you look at organizations, and this could be private sector organizations or public sector organizations, organizations that are able to pivot. What does pivot mean? Change direction. There you go. Organizations that are able to pivot, change direction, and implement quickly. It's not enough to just change direction. That's just thrashing. So if our organization, at the organization level, regardless of the size, regardless of the domain, if you're able to change direction and implement quickly, then we can achieve competitive advantage. Would you say that's a good thing? In fact, long-term sustainability in existing organizations is dependent on this. Can we adapt to our changing environment? Can our businesses and organizations keep up with the change that we know is very rapid in today's world? So that's something that we should look at. Then the question becomes, can agile methods help us achieve this organizational pivoting and competitive delivery, if you will, execution? So I want to present to you a couple of examples. These are both U.S.-based because unfortunately I haven't been to India in the last few years. So there are several folks, including the guy in the Phillips who's talking about this. Anyone here from Phillips? No Phillips? They're all getting ready to talk at 12.30, I think. So there are India-based examples. But here's an example that is from an insurance company. Anyone here work in financial services? So example, which company, sir? Fidelity Investments. JP Morgan. Yeah, that's right. You guys are title sponsors, right? It's a good conference for you? Okay, very good. So who thinks that financial services is sexy? Put your hands up, you have to keep your job, right? So who thinks that Google is sexy? Only one or two people? Who thinks that Uber is sexy? So we tend to associate sexiness, organizational sexiness or exact delivery of an execution with the product development companies. Right here, I'm going to present you a relatively, in general opinion, unsexy company, which is an insurance company. This is nationwide insurance based in Columbus, Ohio, in the U.S. And they have gone through a transformation for the last six or seven years. And here are some of the results. Last year, they had a program of 27 teams. And the 27 teams working together under a lean and agile framework were able to execute, deliver value to their customers for seven months without a single severity one defect in production, right? Now what does that buy you? That says that they have very high quality, right? And high quality, as Deming said, equals high speed. There's no way that we can go fast. There's no way we can execute quickly or pivot unless we have high quality. So these guys have been able to implement agile now on 140 teams or 140 teams enterprise wide. And it is delivering an amazing amount of organizational agility. Now here, that's one example. Here's another example. This one is also another unsexy type domain. And this one is with the government, again, the U.S. federal government. We're all used to complaining about the government. Who thinks your government is doing a good job? Who thinks the government is horrible? Oh, New Zealand. You've got to have a small country, right? Any big country. Okay. So your government is doing a good job, Mr. Julio? Okay. Okay. All right. The second question. Who thinks the government is horrible and not doing a good job? Just a few people? Okay. Other people don't understand the question. All right. So it's fashionable to complain about government. It is fashionable to say, well, the government doesn't deliver my services. They use my tax dollars. It's interesting that in the last few years, the U.S. federal government has started adopting agile. Is it a blanket solution to all the problems? Not at all. But there are two things that I can call out. One, a few years ago, there was the first ever federal CIO. This is the executive level position created by President Obama and his cabinet. And his name was Vivek Kundra. And he put together something called the 25 point program. And there were essentially two pillars to that 25 point program. One was a large scale consolidation and movement to the cloud. Infrastructure moving to the cloud. That reduces a lot of ways redundancy and that kind of stuff. And the other pillar within the federal government that started a series of events in the federal government was something that he called iterative and incremental delivery. Now that's just code for agile. So he didn't use the word agile, but he called it iterative and incremental delivery. And here are some of the results. And this is about four years ago, $3 billion reduction in life cycle budget reduction. This is in the federal government. If the government can do this, then certainly all of us in the private sector should be able to do much better because in the government they have a lot of constraints that we don't. Now another one, you see that picture over there. The picture over there is a very sensitive national organization. It's called NGA, the National Geospatial Intelligence Agency. Those folks are scaling using the scaled agile framework. And they have used agile methods to deliver organizational agility. It's not just IT. IT is just a small part of what they do. They are national intelligence agencies who can't talk too much about what they're doing. But this is public knowledge. You can go online and you can look at a few elements of how they've used agile to achieve organizational agility. So we know it can be done. The question is what is different between these organizations, the nationwides of the world, the NGAs or other organizations who are like folks represented here, Philips and such and other organizations that are struggling to scale their adoptions from a few teams to multiple teams. So we have to look and see what are some of the barriers to agile adoption. This particular survey again shows us that the number one barrier to agile adoption. Once you have agile working on a team, let's say you've got one scrum team and you want to roll out five teams or a little further beyond that, the number one barrier to adoption is the ability to change organizational culture. And this particular survey, this is from 2015, this particular survey has been done every year for the past 10 years, I think. And every year, the number one barrier to adoption has remained the same. It's the ability to change organizational culture. We say, okay, that sounds simple, but at the same time complex. What does it mean to be able to change our organizational culture? So let me ask you guys a question. Has anybody here, and actually I shouldn't say anybody, I'm sure some of you have heard of something called Conway's Rule. Who knows what Conway's Rule is? Tell us what Conway's Rule is. Or the structure of the code reflects the structure of the organization. Or if you take another perspective, the process that we have will find a mirror or will create a mirror structure in our organization. If I have a waterfall process, how long have we had a waterfall process? Since 1974, 40, 50 years of waterfall have created a siloed organization. So it's all fine and well for us to talk about cross-functional teams. But what remains is a siloed organization on top of our agile teams. So if you look at the slide over here, we got some agile teams. Who has a team that looks like this? Cool. Everybody is there. You've got a scrum master. You've got developers. You've got testers. We call this a cross-functional or an integrated team. Who has a cross-functional integrated team? Let's see a show of hands here. What methods are you using? Is it scrum, XP, Kanban? Scrum. You've got a scrum master. Are you a scrum master? Put your hands up if you're a scrum master. Let's give this lady the scrum master a big hand. They've got a hard job. And you have a team that looks like this? Okay. Very good. Now the problem is Conway's rule is also ensuring that your large organization is a siloed organization. And there's no way for us to achieve larger scale organizational agility until we're able to change that larger fabric of the organization. Would you agree with that? Okay. Now, if we have a situation like this, you have development, K, QA, and operations, we see some dysfunctions. Here's a typical dysfunction. Scrum. What is the team size recommended by scrum? Five to nine people, right? So seven plus or minus two, nice little mathematical formula over there. Who has been, put your hands up if you've been on a scrum team of over 15 people. Put your hands up. Just a few people. Okay. You guys, what is it? What's your scrums, this team size of your scrum teams over here? Yell it out. Eight people, seven people, awesome. Sometimes two. Well, that's a little too little. So here's something that we see is that the team size tends to blow. I was working last, or not last week, last month with a team that had 35 people on the scrum team. Their daily standup, which is supposed to be, took more like 15 minutes, almost an hour. Obviously, by the time 50 people speak in such. So teams, when we have an organizational misalignment, this tends to happen. Here's another thing that will happen. Have you seen this? QA taken out from, rather than having an integrated team, where we're supposed to have a developer, analyst, tester all working together, we take our QA people and we put them where? In the basement. Anybody here from QA? Nobody? Where do you hang out in the basement? No, you're integrated. So maybe this doesn't apply to you guys. So what we tend to do is that we backslide towards Waterfall on occasion, organizationally. And we say, oh, QA, they need to be separate. We'll put them in the basement. They'll do some stuff. And we'll send them idly what hours if they find all the bugs, right? Okay, here's another one. Who works on more than one project at a time? How many projects do you work on? Typically, two projects. The industry average, if you take North America and Europe, I don't know about India, is three to five projects, even when there's claim they're doing agile. That's an industry statistic that shows that people are allocated to three to five, between three and five projects, not just to one, the way that we're supposed to have on an agile team. And the multitasking causes what? Delays. Yeah, context switching and delays. So you guys know this. So the question is, how do we fix this? So I'm going to show you a short video. And I apologize if you saw this in my Tuesdays talk, but I promise you that even if you saw it on Tuesday, I'll give you a different stand today. The question is, what do we do to make sure that our larger organization can also become agile, not just our teams, but our larger organizations. So we're going to look to John Cotter. And John Cotter, of course, is from Harvard Business School. And here he is talking about the 21st century organization. Hello, I'm John Cotter. And I'm here to talk to you about winning in a faster and faster moving world. A world where more threats are coming at us from all kinds of different unpredictable directions, but also in which there are more windows of opportunity, opening and closing faster than ever. I am convinced that we've crossed a line in which the old methods that we've used to deal with this no longer work. And I want to talk to you briefly about what seems to work in this faster and faster moving world. To understand this, I found you need to understand how organizations naturally evolve over time and how that has gotten us to where we are now. All organizations start with a structure that kind of looks like a dynamic solar system or a molecule. Their advantage is that they can be very, very fast, very agile. They can run around existing competition. They start with a set of entrepreneurs. It doesn't matter if they're trying to make a new type of microchip or a new type of chocolate chip cookie. They attract people who work on various initiatives. There could be anything, playing around with crazy ideas, talking to customers, doing things with allies. And they can drop those initiatives and start new ones. If they're successful, though, they have to be able to make and ship a product or deliver a service. And as soon as that happens, you start to see growing something that we would recognize. It looks more like a hierarchy. It has jobs. It has processes. And if they continue to be successful, of course, it's that part that has to grow. And it grows. And for a brief time, you've got both, both systems that tend to be hooked together well because of the entrepreneurs who play a part in both. And sometimes the old timers that have jobs over at one side and they're still in that entrepreneurial system. But as successful as they are, you know what part grows. And it grows. And at a certain point, it doesn't like the old entrepreneurial, unpredictable, whipping around system. And so it systematically eliminates it. And you end up with what we all know, a typical modern organization. Now, in a slow enough moving world, that can work fine. And it does. But as the world starts to speed up, it doesn't. And so what smart people do is they augment it. They add strategic planning committees. They hire strategic consultants. They put together interdepartmental task forces or project management organizations to first create and then to execute strategies. And if this is done well, it works up to a point. But as the world speeds up more and more, it doesn't. So they continue along this same path. It happens naturally. You add another committee. You add work streams. You add more strategy pieces. And after a while, all of this addition, addition, addition actually slows you down. And the whole thing starts to sink into the muck, which obviously does not win today. It raises the question of what could win today and actually, you just saw it a minute ago. Now, let's rewind the tape. Okay, start there and go back. Go back some more. Now, stop. There it is. Something that can be reliable and efficient now, yes, we've proven it. A set of processes and procedures and methods can take you from wherever you're at and you start growing that entrepreneurial piece from the center on out in an organic way. You keep the two pieces connected in a very solid way and you end up with this mechanism that can be both reliable, efficient, fast and agile and win today. Here's the bad news. Any organizations have succeeded in doing that about 0.001 percent. Really, seriously, here's the good news. It doesn't have to be that way. Okay, so it doesn't have to be that way. So we're going to talk about how we can succeed with building an organization that is both fast and efficient and I'm sorry, reliable and efficient and agile at the same time. To follow a hypothetical company, let's call this company Acme Corporation and we have some three protagonists over here. One is the CTO, the chief technical officer. His name is Manish. Any Manishans in the room? Manishans, okay. Manishans busy. We have a PMO, a program management office head. Think of this as a program manager. Her name is Shalini. Any Shalini's in the room? No Shalini's, okay. And then this one should be, there must be at least one Raj in the room. Any Raj? No Raj. I guess we run out of luck. There's a Raj. Rajeev, okay, close. Okay, so Raj. And so let's give Raj a big hand. He's our scrum master over here. So what we're going to do is to follow Manish, Shalini and Raj's journey through an agile transformation and outline approach as we go. So there's Manish, there's Shalini and Raj and what their job from their boss who's the CIO of the company is to implement agile methods at a larger scale, right? So they have a few agile projects going on and they start looking at the scaling agile. And one of the things, the first thing they go out and say, okay, what's on the market? And there are different options, right? I think Scott Amler had a t-shirt that said something about options. What did he say? Did he talk about that? Choices, yeah, choices are, choices are good. So, well, okay, they say, well, choices are good. However, if I have so many choices, it's going to be hard for me to zero in and figure out which ones to pick. So let's go out and take a look at the survey and see where can we start. Look at these are the scaling frameworks out there. This is from the version 1 2015 agile survey and it says that the number one technique for scaling is what? Scrum of scrums. But what is the scrum of scrums? Anybody know what a scrum of scrums is? Yes, sir, at the back. Exactly. So we have a daily scrum meeting on each individual team and then they say, well, if I have five teams then each one of those five teams is going to send one or two people and we're going to aggregate that information in a regular meeting called a scrum of scrums. That's not really a framework. So I don't know how people put it up here, but they say, oh, 70% we're doing scrum of scrums, so we must be awesome. If you look further down the chart, you see the scaled agile framework, you see less, you see that and such. So they say, okay, well, where do we start? Why don't we go out and start to deconstruct this framework into a tiered diagram? So pretty much any of these frameworks, including the scrum of scrums, will break out into three levels, though I think the scaled agile folks are now at a fourth level above this, but here you say we have some agile teams at the base level. We've got scrum teams or XP team or a Kanban team, and then we have the scrum of scrum teams that will aggregate the information across those teams if I want to connect across these four teams. If I have multiple teams that I need to work together, then I can have a program, and you can see besides the the famous methods out there, which save less data nexus, there are also industry specific or company specific techniques like the Spotify. Who's heard of Spotify? You've heard of Spotify. It's a music company. You should go check out their video. They have a they talk about how they do agile development at their company, and they'll also talk about program level aggregation and results in a flexible organization. There's also something called the agile PMO. I'm going to show you that later. And if I if I want to aggregate the work of multiple programs at a portfolio level, where I can make financial decisions and strategically drive my organization, then I'm looking at a narrower set of choices. Say, well, okay, now that we're going to understand that screaming frameworks have this tiered view, where can we start? Can we run an experiment? Can we do agile or roll out agile in an agile fashion? So they decide to follow its iterative scaling scale scaling strategy. iteration mean repetition. So when we say iterative, we mean you repeat a few steps over and over again. If you're looking at process improvement, we implement plan do check act, which is Deming's improvement cycle. For scaling, we say let's assess a line and accelerate. We'll do this over and over over again. And to do that over and over again, in conjunction with an iterative scaling strategy, we'll have an incremental rollout plan. So we'll keep iterating, but we'll also roll out agile in increments. After we do an initial assessment, we'll align, we'll accelerate, we'll reflect in progress, and we can lay out a timeline in Acme's case. They say, let's set out a six month timeline for our initial pilot, another six months for the next stage, and then another 36 months, 18 months for the full scale agile rollout. Now, this is of course our recommended approach. There are other people who try to go from step one directly to step what is this for, and that's okay. That might work for them, but over 15, 16 years in the agile industry, I believe this is the best way to do things. Incrementally roll it out. You might accelerate if your organization is moving much faster. You might be able to go from here to here in six months, but following this incremental approach, I think, is the best way to mitigate your risk and to increase your chances of success. So Acme says, okay, we're going to do this, so let's go out and assess and see how well we're doing on a few key elements. From a business perspective, if I'm looking at organizational agility, here are three metrics that we think are important. Time to market. Time to market means that how reliably am I delivering solutions from the inception into production, from concept to cash. So time to market. We were going to measure that across all of it, so Acme says we're going to take a look at that. We'll also look at cost, more standard metric, and also customer satisfaction. How satisfied are my business customers with the stuff that we're delivering? So they go through the initial assessment. Time to market is 300%. Not very good. So they're doing really badly across the competitors. Turns out that cost is high and so is customer satisfaction, which is low. Anybody have been in this situation? You have? Okay. So this is sometimes one of the reasons why we adopt agile methods, because we know that agile methods can help with this business scenario. When it's taking too long to deliver the stuff, when our customers are not happy, and it costs too much. So they say, okay, Acme says, and I'm going to quote one of my actual customers, they say, Manish says, now we know we're bad. We're world-class bad. But there's one thing good about this. What's good about this? You know. And you know there's only one direction you can go from here, hopefully. Which is, oh, we can get better. So we're here. We know we're bad. We're going to benchmark from now. We're going to go up. All right. So we say, let's align. Let's kick off our pilot program. A pilot program is an experiment to see in the six months how we can run agile. So at Acme they say, let's run six months pilot program and establish the role of an agile champion. Any agile champions here? Somebody in the organization that is responsible for perpetuating and evangelizing agile methods. Necessary role. There's money to be spent. Before we can speed up, we have to slow down. Let's slow down. We have to train our people. We have to get them to understand agile. We have to realign a little bit. We have to establish the voice of the customer. Put some product owners in place. Figure out which projects we're going to launch. Figure out who our product owners are. Product owners are people from the business that will represent the needs of the business to our agile teams. And then we have to figure out, you know, how to take these projects and get them launched. Six months of our five projects. Acme says, let's go off and do this. Things start to turn around. As they do this, they say, well, one of the things we might need to make sure is that all of these projects, just like we benchmark our performance, we should benchmark a basic process. Different teams can experiment. They can try different tools. But we're going to have a common thread running through these projects, the pilot projects. And here's the base project process that they decide on. They'll have an initial discovery or launch. This will be about a month or so, a couple of weeks. Maybe some people call this sprint zero, iteration zero. And then they'll have two-week sprints. Each one of the sprints has a familiar cycle, right? So sprint planning, sprint demo, daily stand-ups and such. On the delivery side, we say we have automated building test, metrics, some XP practices for code quality and start. And we're going to measure just three or four, three things, simple things. Code quality, team velocity and user story cycle time. Who knows what cycle time means? What is cycle time? Anybody? Yes, sir. The time between when a story begins in development to the time it takes us to do what? Deliver it back to the customer. So they say, well, let's get it to done, not necessarily production, but let's measure the user story cycle time and getting it done, which means coded, ready for production, shipable back to the product owner. And that's going to allow us to measure the speed at which these teams are going. Looks good. They got some version control tools, some technical tools. They get moving. Six months later, they say, let's look at the results. Pilot program starts to look good. Time to market is down by 70%. Cost reduction 20%. Customer satisfaction commensurably up by 50%. Customers are happy. Product owners are getting results. Our pilot program is looking good. Who's lived this? Anybody gone through the cycle? Just a few? So I'm not making this stuff up. It happens. This is a synthesis of about 10 or 15 years of agile adoption. So next step, they say, pilot program has proved out. Things are looking good. Let's go to the next step, an expanded pilot. It's time to accelerate. We proved this out. We built a team. Let's accelerate. And in accelerating, let's look at some key scaling fundamentals. Limit work in process. Do just the minimum amount done that allows us to move quickly without that context switching and waste. Grow small stable teams. Build a network of these teams and then manage the flow. Let's take the first one. Limit work in process. This is Bangalore. So your traffic looks worse than this. Is that correct? Who had to deal with traffic that looks worse than this picture over here? Coming in. How often do you deal with that? Every day. And what time do you start your commute? Eight-ish? Does it look like this at eight? Okay. And then it continues. Does it get worse or better as you go through the day? What's that? Worse. So at what time of day does it not look like this? When is the traffic okay? What's that? 7.30 to 8 o'clock. Based on where I'm coming from if I leave my house let's say at 7 a.m. It's okay. Put your hands up if you think you can go fairly smoothly on the highway if you leave your house at 7 a.m. Okay? All right. Now if I want to avoid the traffic on the way going back what time should I look at that? 11 p.m. Okay. Okay. 2 p.m. What's that? 2 p.m. in the afternoon. Okay but I can't leave work at 2 p.m. in the afternoon. That's my tea time. So what's that? 9 p.m. So put your hand up if you're 9 p.m. if you leave your office you'll have a decent commute back. Just a few people. Some people said 11 p.m. Or sometimes 11. So what starts to happen is that at around 7 a.m. more and more traffic starts hitting the road. And why is this? Everybody's going to work. And the utilization of my highway goes up. And at about what time does it start to get really bad? 9.30. We're gone beyond the 80% threshold. And the cycle time, the time it takes me to go from point A to point B has gone up exponentially. Beyond the 80% threshold there's something called Little's Law that says once 80% or more of that highway is used the time it takes you to go from point A to point B it goes up exponentially. And this is why we need a working process limit. If we don't have this working process limit we just have continuous flooding of traffic on and on. And then you have to wait it out till 9 p.m. or 11 p.m. So once a highway or any shared resource this queuing theory tells us this on the top what is the top right there's something called Little's Law that says cycle time is a function of the amount of work and process whether it's cars in the highway or projects in the portfolio or user stories in your project. If I have too many user stories and I'm working on too much stuff it's going to take too long. My cycle time is going to long. If I have too many projects then the delivery of individuals' projects will go, you know, the cycle time will go up exponentially just like my traffic on the highway. Does that make sense? So what's the answer? If I want to speed up I have a numerator and I have a denominator. If I want that cycle time to go down what do I need to do? Pardon? Either I need to reduce the work and process reduce the numerator or increase the completion rate. If I have a team increasing the completion rate means making the team go faster. How much faster can I make the team go? Not much. I can... What can I do to make my teams go faster? What's that? Whip them? Shout at them, yell at them. The beatings will continue till the morale improves. So shit. So I can either do that which doesn't work too well or incentivize. Like what? Free trip to Thailand. Anybody get a free trip to Thailand? Nobody. Okay, other incentives. Yeah, those short-term motivations don't work. So really the only realistic pragmatic option I have is to reduce my work and process and I'll prove to you that it works in a second. So let's say at Acme they say these are the things that we're going to do anything that's a sick project. What's a sick project? A sick project is one that's taking long, is going on forever and however in the U.S. but there's a whole sort of zombie apocalypse. So this is like a Vikram and Betal kind of thing situation. That thing just keeps coming back. You can never get rid of it. So this is a zombie project. And there's only one way to... I can get my portfolio to move faster. That's to get rid of the project. Take large projects and break them down into smaller one and then prioritize what's left. Simple steps. They're simple in theory but they're very hard to implement in practice. Why? Why is this hard to implement in practice? If I say here's a project it's not doing good. If we've been spending all this money we need to kill this project. Somebody's career is linked to that. It's usually the pet project of some really high priced executive and it's their pet project. So it's really hard to do this unless you have a systematic project to do this. So Acme says we're going to crack some eggs and make some omelets. We want to make sure that these things are perpetuated in the organization. We'll set up a portfolio management committee. They go through these steps. Terminate the six projects, split large projects into small ones, prioritize them and limit the delivery framework to two months. They end up with a portfolio that looks like this. Before they had an unprioritized portfolio with 400 projects in flight. Once they prioritize the portfolio only 100 projects are in working process. They're 1-4. They've killed 100 projects and they've queued up 100 and the backlog of projects is 100. Now look on the top right again seems to it. Who's heard of this odd even scheme? Anybody heard of odd even scheme? Tell us how it works in New Delhi. Anybody from New Delhi here? You know of that. So what is the odd even scheme? I think they're just they're going to restart it in April. So is it your number plate and the date? So it's my registration number if it happens to be odd and the date is odd then I can try it. Okay is this just a weird KGVAL scheme or did it work? What do you think? What's that the first one? So apparently there's some some benefit to the scheme. If you go and look at the results look at the even if you account for traffic limits like speed limits and in New Delhi the the speed average speed and this is from Uber, Delhi went up on average by statistically significantly 4.5.4 percent. This means by reducing the amount of traffic on the highway cars went faster and it wasn't just KGVAL. Okay so it's a good scheme they prove it. This is why they're going to restate it again in April. All right so if you go to if you go to Delhi in April you'll have the odd even scheme back in existence. That makes sense? Okay so rebalancing the portfolio can have amazing results even you know even when you deal over a mass metro system like this with such complexity as New Delhi. Okay so that's our work in process limit section. The next thing we have to do is to grow small stable teams. So rather than bringing teams together or putting projects together and then breaking them up and going through what we call the Tuckman model of team formation. Any PMPs here? Project management professionally. Yes sir let's give him a big hand he's a brave man. Yeah so in the PMP in the PIMBOT the project management body of knowledge they talk about the cycle that a team has to go through and the cycle is forming, storming, norming and performing. Europe PMP as well? No okay he just happens to know let's give him a big hand as well. So this is team formation we form a team they have to storm they have to work out procedures then they norm they start to get working together and then and only then can they become high-performing and my question to you is if we have to do this every time a team comes together why do we break the team up again once they're high-performing and so what our goal should be is to create stable teams and rather than bringing people to the work we should bring the work to the team. That backlog that you saw that 100 people project backlog this is what it's looking like here's the stuff that's in flight here's what's queued and here's in the backlog and here you have three teams these are standing teams some people call them standing teams some people call them stable teams and the idea is that these teams stay together now they might be on the periphery one or two people coming but the core of the teams always stay together and we bring the work to the team make sense? okay so limit our working process create these stable teams bring the work to the team who has something like this anybody? and you're which which company sir? EMC the data company you recently got bought out by somebody Dell okay how's it working out for you? no change okay so you have these kind of standing teams and the teams stay together so let's follow our Dell model or the EMC model which works really well I think Evan Laiborn he talks about this as well you know this is a this is a product-based model rather than a project-based model you can put projects together as necessary but this one is really good for product development once we have these teams let's combine them in a network can we scale them through what we call an agile PMO right remember we want to go from one stage if you have individual teams can we now start to put together a structure and I'm going to show you one example which is an agile PMO there are other scaling examples we'll talk about in a second in from the from the scaling frameworks but let me show you I don't have to do oh here we go I'm glad so this is a group called an agile PMO let's watch them in action so is this uh Jill is this representative the reconfigured board is this the consolidation this is the consolidation except I would say that everything from 417 is actually correct this is not correct because we we need more weeks over there so let's talk I don't have more do I need to because I'd like to take two minutes to talk about that is do we need any further updates in the current iteration from any of the from the start presentation probably we need to go through there okay so those people in that room were what we would call an agile program management office and we're going to see different names for that in second in the scaling framework but what it meant was that you got one or two people from each team you have one or two executives the guy in the shirt who was saying I need two minutes to talk about that he was an executive and he was he was organizing this group called the lean agile or the agile program management office the lady who was near the board she was this chief scrum master the equivalent of what we would call and save the release train engineer that's if you have some of your family would say right and so what they were doing in that meeting was they were managing cross project dependencies and so if you look at the board it's what we would call a portfolio alignment wall or a program wall each column is a time box the equivalent of a sprint each row are features moving through and each card on those are high level work products the dots on each card these dots represent dependent teams dependent teams then they got a dot we put a team up there and by doing so this is that particular program had 21 teams working parallel four were agile teams 17 of the teams were waterfall teams and they were getting together and putting this wall together for the PMP folks this is the equivalent of a master program schedule right it's a program level deliverable does coordinating work across the different projects and they can lay it out and they see the results okay so that's the that's coordinating work managing the flow let's get back to Acme after having done this the results spectacular right time to market across up by 40 percent cost of cost down by 25 percent and customer satisfaction up by 39 percent looking good what do you think all right so they say well now let's reflect in progress and now we're ready to look at some of the scaling frameworks because we have built the foundation we have some stable teams at the bottom level we have some cross team coordination through our agile PMO and now what we can do is we can start to look at the scaling frameworks so they say let's take an example who over here is familiar with the scaled agile framework so a lot of you guys know our thing at the bottom level all of those teams are scrum or XP teams in the scaled agile framework this program level what we call an agile PMO the coordination group is what what do we call it in safe an agile release train or an art and the chief scrum master the lady who was in that video what do we call her a release train engineer right so we say we have built these blocks save has other things where you have an architecture one way and stuff and once we have the program level elements you can also pull together at the portfolio level all right so if we wrap up if we follow that approach limiting the work in process building out stable teams creating that network or stable teams and then looking forward here are the options that we have we have scrum or scrums we have agile PMO the Spotify and then the frameworks over there when it's dad safe it's less and nexus and the elements so the techniques that I've the elements of the techniques that I've showed is what you see on this on the screen over here right so summary and next steps strategy introduce that strategy incremental rollout and your fundamentals to take forward reach in the book reach in your bag take your free book and if you're a CTO PMO lead or scrum master team lead this is what you need to do I think we're at time what do we have any questions how much time do we have five minutes time okay five minutes two minutes which one okay okay two minutes two minutes of questions any questions we might not have any questions any questions that's not my business okay so I think both the safe guys and the dad guys are here so as a third party what I've given you is a foundation that you can build on we call it a jump start put these building blocks in place and you know I think both the safe folks are there I would like people to make an intelligent choice like Scott Abler says choice is good I've given you the building blocks to make your own choice that make sense right let's take one more question and we'll do I think people are waiting for the next week yes so you see my email address the website's over there and make sure you read the book thank you very much and enjoy the rest of the conference