 We're going to use the scale to add to our framework. And we're going to have some fun too while we're doing that. It'll be a fun morning. Otherwise, we're starting a little bit, and we'll be having a 90-minute session. So we'll certainly make up the time and hopefully you guys at the same time. So let's get into the meat of it here. Once again, I apologize for the display. I'm not really sure why that's working. Anyway, my name is Colin O'Neill. I'm a co-founder of Scaled Agile Inc. And I work with Dean Leffingwell, who is sitting right here at our table. Wave to Dean. Everybody wave to Dean. Hi, Dean. Dean Leffingwell was the creator of the Scaled Agile framework. Yesterday he put on a one-day workshop for about 60-some people. And they got sort of the condensed version of a normal two-day public offering. We also do private offerings as well. But in any case, I work with Dean and Drew, our CEO. We're three founders. And we've been doing this a long time, particularly for myself. I've been in IT for 27 years. I came out of the military before then. And in the last 27 years, we have earned certified scrum master, certified scrum professional, a safe program consultant trainer, a principal contributor to the framework, and work with some very large clients in the world, some of which have offices here in India. And also, I particularly enjoy Lean in terms of the enterprise, specifically a technique called value stream mapping, which is pretty important in understanding how to develop enterprise value at scale. All right, our agenda for today is basically there are three parts to this presentation. The first is I'm just going to talk about Agility Enterprise Scale and the framework and how it promotes that. Then we're going to go into something called the House of Lean, the Lean Principles that underpin SAFE. And this is a new material just published on the Scaled Agile framework website, and we'll talk about it in a few minutes. And it basically is the mapping, it shows a mapping between Lean Principles and the Scaled Agile framework itself. And then the last part of the presentation will talk about the results that organizations achieve by adopting these enterprise agile principles and techniques. Okay, stuck again. All right, so let's talk about Agility Enterprise Scale. This slide pretty much sets the stage of why we're here. Everybody in this room probably knows something about Agile, and we also know something about software. I suspect that most people in the room are developers, testers, QA folks, project managers, et cetera. You're somehow involved in IT. What we're trying to say here is that the reason that we're concerned about enterprise agility in the first place is because our world runs on software, and it is going to continue to run on software, even more so than it is today. Everything that does not run on software today will run on software in the future. We know that. We see that trend. It's happening every day in our lives, not just in business, but in our personal lives as well. So the change is driving new techniques, new techniques to create value and get it out into the world with people that can consume that value as fast as possible. The rate of change is increasing, and it's not a linear inflection. It's like the hockey stick curve. It's going up at a rapid pace. So the rate of change is forcing us to build software differently, to think differently, to act differently, to change how our organization operates. We literally cannot meet the demand of software in the world today by using the same techniques that we've used for the last five, 10, 15, 20 years. We have to change what we do. That's where agile comes in. We know agile has been around for more than a dozen years. Mainstream. We know that it's here to stay. This is not a trend. This is not a fad. You are agile practicing agile. You are agile practitioners. We know that agile, the techniques and practices within agile, the scrum, the XP, the extreme programming, Kanban, these techniques are useful in helping us deliver value faster. What we're also finding is that lean principles are really underpin our agile roots. And as an agileist, as an early agileist, I did not even know that. I did not know that lean was behind all of the neat agile techniques and practices that we were using through the years. Now we have a whole new school of thought, and it's called the Lean Enterprise, or Lean Thinking. And Lean Thinking now is driving more of a focus of agile, not just on the teams themselves, but on the individual teams of five to nine people, seven plus or minus two. It is now driving a different mindset at the top of the organization through middle management all the way down. Folks, please come on. We have some space along the walls. We might have a few empty seats. Grab them as necessary. You're not interrupting me. Trust me. So, the new approach combines agile and lean to really drive home this notion that we need to develop better software, faster, and deliver value to our customers even more than we ever did before. That's what's driving this. Now, once again, I apologize for the horrible picture, but good news, we have one more seat up here. One more seat right here. Good news is, can somebody hand me a picture here? And the bigger one, actually. Thank you. I'll take both. Thanks. So, all of you have a picture of the Scaled Agile Framework. And if you don't... Too bad. No, I'm sorry. If you don't, it's good news. You can go to Scaled Agile Framework.com. The big picture is there. Now, let me just explain real quickly. So, you can't see it up there, but this is the big picture. And when you go to the website, ScaledAggileFramework.com, it's really easy to remember. You click on any one of these icons, you go down into a detailed page that has kind of an overview, a preview, and then some detailed information about that thing. There's a great deal of information behind this picture. This is just a graphic, right? This is just two-dimensional graphic. So, it helps us, though, have a conversation. And that's really what we're doing here. Now, the ScaledAggile Framework is a publicly-facing, proven approach to developing enterprise software at scale. It's been around for a while. As I said before, Dean Leffingwell, our esteemed colleague over here, is the creator of this framework. It emerged from Dean's work in the field. This is not a theoretical exercise. This is practical... This is based on practice and practical experimentation in the field. It represents what works. There is nothing in this framework that is theoretical. It is all based on what is worked in the field. And that's why it represents a pretty good starting point for understanding enterprise agility. The other thing is that it's based on Dean's principles, and that's what the meat of this topic is about today. Now, the framework itself, there's a couple of key approaches here. There's a couple of key concepts, and that is synchronization and alignment, basically taking at these three levels, we have the team, the program, and the portfolio, taking agile teams, which we all know are extremely powerful constructs. Everybody knows the value of an agile team and has experienced that power. Once you experience it, you don't want to let go. You'll never go back to a waterfall world. So what the framework allows us to do is it takes those teams and it organizes them, it synchronizes them, it aligns them to create this even greater set of value that can be delivered quickly, that is integrated, that is fully tested, that provides the most value and benefit to our constituents and our customers at any given point in time. That's the power of the framework itself. We know that it scales. We have scaled this across the largest organizations in the world, including the Global Ten, the top companies in the world. We know it works. It's been around for about seven years. More than that, about 2006, right? Yeah, so eight years, my apologies. And the other thing that it does, the scaled agile framework, is it provides predictability to senior management. One of the problems with just focusing on agile teams, we all have experienced this, is that we have pockets of excellence around our organization. Agile teams are just fantastic. But essentially because they're scattered and we don't have them aligned and normalized in a way that makes sense to senior management, it's hard for senior management to predict what agile teams are going to deliver. In this case, we create an environment within which senior management can have predictability over time. We essentially scale a team's velocity to a program velocity to a portfolio velocity, and we understand better how much value in software we can deliver in certain periods of time. We also have four core values in the scaled agile framework. Code quality is number one. Is anyone surprised that quality is number one? What do we normally do with quality? Who wants to answer that? Who wants to try to answer that? What do we normally do with quality? Come on, folks. All right, we're going to do our first exercise. Everybody stand up. Everybody stand up. And I would like you to turn toward that side of the room. Everybody go, thanks, Dean. Thanks, Dean. For developing the framework. Thanks, Dean, because here's the thing. We wouldn't be here today without Dean. Now, everybody sit down. I wanted you guys to get a little bit moving here. So quality, I'll give you the answer. Quality is always the last thing we think about, right? It's always the last thing we think about. We make it number one. It is the first thing we think about. If you're going to deliver value, it better be good. The software you deliver better be good. So quality is built into the framework. We make quality, we fix quality. We do not let it vary. We fix the quality and we have other things that we can play with. Program execution is the second core value. What we mean by that is that agile programs, the middle tier of the scaled agile framework, is where the power of agile teams really is manifested. When we organize 8, 10, 12 agile teams into a program, we get them aligned and say, you will be absolutely amazed at the products that can be developed quickly and at high quality and delivered to our customers. And the customers are delighted. This happens again and again and again. The third core value of the scaled agile framework is alignment. We talked about alignment and synchronization. This is a key lean principle that we're leveraging. And then finally, our last core value is transparency. Trust and transparency as we know are core agile values. You cannot be agile without transparency and trusting the people around you. These are the fundamental principles that guide us. And these are not just platitudes. This is real. Yes? Yes. I'm going to do that very shortly. Good segue. So once again, a horrible rendition of the framework in this display. But you have it in front of you, so just follow along there. There are three levels, three tiers of the scaled agile framework. The idea is that an agile program consists of, let's say, 5 to 12 teams on average. 5 to 10 or 12 agile teams. So there's a one to many relationship here. And an agile portfolio consists of multiple programs, a one to many relationship there. So we're scaling up the stack. You see? Now, the alignment and the synchronization of these teams is what gives an agile program its muscle. We have learned from in lean principles, we're going to talk a little bit more about this, that when you take a number of people, let's take this table right here. Individually, they're good folks. They're developers, they're testers, they're business analysts. But when I align them in an agile team, what happens? When they get synchronized, when they get on the same two-week cycle, when they start to plan together and execute together and deliver together, what happens to this team? It's synergistic, right? The whole is greater than the sum of its parts. The same thing happens when we scale this up to the program level. We have agile teams that are on their game, and when we take those teams and we combine them and we organize them and align them around common vision and values and goals, we ultimately find there is incredible power there to deliver fantastic software really quickly. That's the nature of scaling teams to programs. The program level itself is based on this notion that there are things in the organization called value streams. A value stream is how value flows through the organization. It represents all of the activities and all of the parts of the organization that conspire together over time to create this thing of value, this product or set of services that we are delivering to our customers that people are willing to pay money for. That is what a value stream is all about. Many organizations are not organized around the value streams. They're organized functionally, vertically. And to that end, they are often inefficient, especially when we go back to that first slide that talks about the rate of change and how we need to adapt given that rate of change. So the closer we align our organizations in our software development groups to the value streams to how value flows to the organization, the faster we get quality product to market. There are things in Lean that we'll learn about called delays. Anytime you delay between those activities of that value stream, you increase the lead time of getting that value to market, that software, that product to market. And that means we're losing money. There's lost opportunity costs that we have to deal with when that happens. So understanding the value streams is key, Lean Principle, and drives how we organize and how we align our Agile programs. Agile programs exist to support value streams. They exist to help deliver value faster to our customers. The portfolio consists of the Agile portfolio, consists of higher order constructs, long lived initiatives that span multiple months and potentially years and span multiple Agile programs and potentially value streams. And they guide how programs execute. The Agile portfolio is responsible for guiding those Agile programs in terms of achieving the value that they set out to achieve. The Agile portfolio is also responsible for funding those Agile programs. And so in that sense, they are responsible for ensuring that the programs are delivering the appropriate amount of value. Now, we all should know the Agile manifesto. Does anyone here not know the Agile manifesto? Don't raise your hand because we will throw you out. Just kidding, we won't. But everybody hears an Agile manifesto, right? We know the Agile manifesto. But the Agile manifesto is real. Here we are, folks, 13 years after its inception. And of course, it was being practiced before then, but 13 years after it was written down and the values of the Agile manifesto are still valid today. They still hold true. These are timeless. We know that individuals and interactions are better than just having processes and tools. We still need process and tools, but we know that interactions and collaboration and communication is so powerful. So the framework is based on these fundamental principles. We know that working software is the true measure of an organization, of a software organization. How well we are doing is it, are we creating working software that customers can really use? We know that collaboration with our customers is key. We don't want to set up an us-them scenario. We know that. So we use these values as the underpinnings of the framework itself. And the framework then drives the ability to respond to change. It is suited for, ideally suited, for adapting change. And we know that the world changes very fast. We talked about the rate of change in slide one. Now, we also know some of these fundamental Agile principles. I'm going to go through these fairly quickly because we're going to get into the fun part in just a few minutes. We know that the incremental iterative delivery of software has a great benefit in what we do today. We know that. We know that we reduce our risk. We increase the level of integration. We reduce defects, and so the quality goes up. We know all of these things. We also get feedback from customers faster when we create these small packages of software. And we build on the previous iterations. We know that. We also know that we get value delivered sooner, so we can start collecting revenue sooner. This is actually a subtlety lost on many IT folks, IT practitioners. I was an engineer, and I grew up in the software world, and all I cared about was developing some capability within software. That's all I cared about. I didn't really understand the economics of developing that software. But we, as Agile practitioners, we need to start thinking about the economics. We need to understand what's driving the decisions of our customers and our senior management. And if we understand that better, we can react to the changes necessary, and we will better anticipate what's coming down the road. This helps us in many ways. So understanding that we get value, that our companies are collecting money for the products that we are building faster than in the waterfall world, because we are delivering value incrementally. And this is something that enterprise agility is very keen on providing. This value, this aggregate value over time, adds up to more money for us, for our companies, for our bonuses, for our salaries, for our benefits, et cetera. It's all good. We also probably have experience that because we get feedback faster from our customers, that Agile teams and Agile organizations can adapt quicker to the changes in the market or the changes in the customer, that the customer has, right? In the waterfall world, we set a plan and we laid out this plan for a year. And I did this, folks. In the 80s and 90s, I was a waterfall guy. And I was a PM. And I used a Microsoft project. Man, I could make that thing sing, right? And I could lay out these Gantt charts for eight, nine, 12 months. And they were really good. They work, well, they work for the time. They don't work today. We can't run our software development on Gantt charts. We can't run it on these detailed project plans. That's why we have Agile teams. It's to be able to change rapidly. Every two weeks, we can make an adjustment. In the Agile world, we make the adjustments. And we will meet the customer's needs faster and better because we can shift. We can flex to the very needs. Also, in Agile, as you know, we release early and often. We get working software out to people that can consume it. Maybe not necessarily the customer themselves, but folks in our organization that can essentially test it, integrate it, try it out, beta test it, all of those things. Using these smaller iterations, we get a lot of benefits from them. Eventually, we get faster feedback. We have more frequent leases. And we can fix the release dates. So in a pure Agile world, and we're talking about Agile teams, when can you release software? Any time, but certainly at the end of every two weeks, right? Every two weeks, you have a potentially shippable increment. We do the same thing in the scale of Agile framework. We do it at the next level up. We do it at a fractal above the team level. At the program level, notice on your chart there, we have something called a PSI, or a potentially shippable increment. So all we're doing is we're taking this two-week timebox, and we're essentially scaling up to a higher level or a higher order timebox of anywhere from 8 to 12 weeks. And that becomes our new potentially shippable increment because now we have 8, typically 8 to 10 teams in an Agile program, all creating this integrated software product that has a lot of capability that can be potentially shipped to the customer. Now, the reason we can do this, actually, let's go back to the last slide. The last bullet says the scope is the variable. We do not vary quality. We fix quality. And this is horrible. I can't even see. Anyway, this is supposed to be the iron triangle. Does anyone here not familiar with the iron triangle? Raise your hand. That's okay to raise your hand. All right, sorry. Well, this is a really horrible rendition of the slide. But here's what it's supposed to do. It's supposed to say that in the waterfall world, we fix the requirements, and then based on the fixed requirements, we essentially can derive a cost and a schedule. So cost and schedule become variable. But what happens in reality? Once we fix the requirements and we give management a cost and a schedule, what do they do? They fix the cost and the schedule. So now you have three fixed variables. Now what's... Or three fixed factors. Now what's variable? Quality. Quality becomes variable. So it's kind of a no-win situation. In the agile world, we turn that triangle upside down. Basically, we fix the cost and the schedule, and now we vary the scope. This is not news to agile teams. You do this all the time. You have a fixed cost. In other words, we know how much an agile team costs, and we know that we're going to work in two-week iterations, two-week increments. So we fix the schedule. What we vary is how much work you can get done in that time frame. So that's how we vary the features or the scope. Now let's get into the layers of the agile framework or the scaled agile framework, and then we're going to get into the fun part. I mean, not that this isn't fun. This is really fun, isn't it? I mean, like, I'm really entertaining you guys. I mean, my jokes, you know, and you're laughing and you're rolling on the floor. You're not doing that, are you? It's like, who is this guy? What is he talking about? We'll get to that. We'll get to be rolling and laughing on the floor here pretty soon. All right. Nothing beats an agile team. We know that. What are the benefits of an agile team? Number one, they're self-organizing, self-managing. We empower the teams, the agile teams, to manage themselves and we make them cross-functional. Someone asked a question yesterday in the workshop. They said, okay, how do you deal with distributed agile teams where, you know, some members of the team are in one location and other members of the team are in another location? And our answer is, that's not a best practice. We have learned over the year through trial and error that we want a team co-located. Even if you have distributed software development, let's say you have a team here in Bangalore and a team in Munich, you still want the entire team in one place. Now, you may have some proxies dealing with, like, product owner and things like that, but you still have the team co-located. So we have cross-functional teams that are co-located. They are empowered to determine how much work they can get done in a two-week cycle. That's the power of an agile team. Yes, sir. Yes, that's what we're trying to fix. You see, it doesn't work very well, does it? So we have a number of organizations that have experimented with this. They had, you know, maybe some developers and testers in India, and they had a product owner and a scrum master and business analyst somewhere else, let's say in Munich. It didn't work that well. Why didn't it work that well? Because the team wasn't able to communicate and collaborate effectively on a daily basis. So what organizations are doing is now, they're moving, let's say the team here, or the team in Chennai, has a scrum master. It has either a product owner or a product owner proxy, and it has potentially a business analyst, along with developers and testers right here. When we do that, we change the game. We actually give that team now the ability to interact as a true Agile team that can collaborate every day. And if we do have a product owner proxy, then it's the product owner proxy's responsibility to communicate with the headquarters and the product owner at headquarters. So that's the model that we're trying to move to. We recognize the challenge of that, but many organizations are realizing that's the only way they're going to have success. Good question. So what does an Agile team deliver? Fully tested, fully integrated software. Every two weeks, fantastic. We love Agile teams. They are the basis, they are the foundation of the skilled Agile framework. If you notice, the team level is at the bottom, because everything is built on those Agile teams. Without strong Agile teams that are using scrum and XP and Kanban practices, the framework really has no teeth. So Agile teams, we love Agile, we love all of the people that made it possible for us to be Agile today. We are standing on the shoulders of giants. Let's face it, none of this stuff has been, we didn't invent any of this. This has been out there. This is now being organized in a way that uses the power of all those techniques. Yes, sir. I'm sorry? Yes. How practical is it to deliver software in what? Ah, good question. That is a great question. The question is, how is it possible to deliver fully functional integrated tested software in early stages of development? The answer is beyond the scope of this lesson, but I will just say briefly that it's important to, that's why it's important to understand value streams, because essentially we take thin slices, thin vertical slices of the problem or the solution, and we create them early and then we build on those. So instead of building out, let's say the data layer or the business logic layer and then the UI, we do this vertical slice. So we want to take the smallest unit of value that we possibly can, build that, deliver it to somebody, get some fast feedback. That's how we do it. That's the quick answer. All right, I'm going to speed up the session here because we've got a little late start anyway. All right, so we're using Scrum, XP, other Agile practices like Kanban. The teams themselves, the Agile teams in the Scale Edge of Framework, because they're aligned and synchronized. They now operate under a common vision. It's like when you're out on the river and you're rowing, you're in a skull, and you've got, imagine, you've got 10 people in that boat. And imagine them all trying to row at different speeds and at different intervals. It's when that coxswain gets up in the front of the boat and says, row, row, row, right? Everybody's pulling in the same direction at the same time. That boat can go incredibly fast. That's what we're doing. We're aligning these Agile teams like we are aligning the rowers of a skull. And the value that's delivered by Agile teams is still in terms of stories, user stories, technical stories, infrastructure stories, et cetera. And when we scale to the program, essentially we have a team of Agile teams, but it's also self-organizing and self-managing. It becomes almost a virtual delivery mechanism. In fact, what we're really doing is we're creating the software development factory. Because we have these anywhere from, excuse me, five to 12 Agile teams and we align them, we are creating a capacity, a fixed capacity that we know we can count on to develop and deliver valuable software in short increments. In this case, we call that the PSI. So we have continuous value delivery. In other words, this is a continuous development flow mechanism. It's like a software factory. We're always developing, we're not stopping and starting. In fact, on the framework itself, if you look at that diagram, you will not see the word project on there at all. You will also not see the word phase. We are phaseless and we are projectless. This is continuous delivery flow. And that's what makes this different. That's what makes this more closely aligned to lean than any other approach. We use common sprints. We use common estimating techniques. We use face-to-face planning, just like Agile teams do. We come face-to-face an entire program. There's probably 110, 120 people in this room right now. That's the typical size of an Agile program, anywhere from 50 to 125 people. And we literally have all the people in the room, all these Agile teams, planning at one time. And there's huge value in planning face-to-face every 8 to 12 weeks, just like there's huge value in planning face-to-face for an Agile team. And we deliver value in terms of features and the feature benefits. So the capabilities, these higher order of capabilities that this Agile program delivers. When we scale to the portfolio, we change the game a little bit. We're concerned about governance. We're concerned about responsibility and accountability to the organization. We talk in terms of what we call EPICS, the values delivered through business and architectural EPICS. EPICS are long-lived initiatives that span multiple PSIs, multiple time increments, anywhere from 6 to 18 months. They might also span multiple Agile release trains, or Agile programs, in support of value streams. So we change the game a little bit. The portfolio vision guides all of these programs that are aligned under this portfolio. So now not only do we have teams aligned in a program, we have programs aligned in a portfolio. Extremely powerful mechanism. Anyone that's been involved in the military understands how this works. We have platoons, we have companies, we have battalions, we have regiments. We scale these things up, and this power then is projected in ways that are unimaginable if it were just 10,000 people running around. It's the same way. We decentralize strategy, but we decentralize the execution. We let the programs and the teams be autonomous in that way, guided by an overall vision. All right, now let's get to the interesting part. So we use this thing called the House of Lean. The House of Lean is a metaphor for lean principles. Yes, sir. Okay. So many organizations have integrated product tweets. Right? Let's take SAP, for example. There's perhaps an HR module in SAP. And how... So customers are willing to pay for that, right? So we start in the value stream analysis, we start with what is the customer willing to pay for? What product or services is somebody willing to say, here's money to do that. That's where the value stream ends, but we work backwards actually. We say what are all the things that need to go into that product that the customer is willing to pay for? Let's say in this case the HR module at SAP. So all of these components come together. We have framework components, we have infrastructure components, we have technology stacks, we have all of these things. And they're all fed by different parts of the organization. And even different parts of development. And so when we understand how that value flows and how we get this integrated product called an HR module, then we can understand what needs to be done. Now, how many people does it take to build and maintain that HR module and continue to develop new features? 3,000, 5,000? A lot, right? That's a lot of people. So if that's the value stream, we break the value stream down into areas that we can manage effectively in portfolios and programs that will ultimately deliver that value. So that's how it's broken down. That's the very quick answer. So a longer answer would take obviously much more time. Yes? Something a little bit top-down approach where your governance is more going up. How do we have innovation in this framework? So innovation happens at multiple levels. But ultimately the teams are the ones that create the most innovation. And we have a place for that to happen. It's called a special sprint. If you look at your diagram here, it's this little sprint that's with an HIP in there. HIP, HIP Sprint, stands for Hardening Innovation and Planning. And so there are innovation activities that happen toward the end of every PSI. And a PSI again is once again 8 to 12 weeks. Now, let's get back to lean. This is cool. So we have this house of lean. There's a roof, there's a foundation, and there are three pillars. You can't really see the pillars, but they exist. The goal of lean is to deliver value. That's all lean is all about. If you really boil it down to one word, it's value. If you are delivering value and all of your processes and your techniques and your organization is geared toward that, then you are a lean organization. The foundation of the house of lean, though, is leadership. We cannot do this on our own. We must have our managers and our leaders not only allowing us to be lean, but leading from the front, requiring us to be lean and making it possible for us to be lean in our own environment. Then we have three pillars, respect the people, Kaiser in mind over here, and product development flow. We're going to get into each one of these and here's where the cool part happens. Right. Let's talk about the roof of the house of lean is value. What we want in lean is to create the sustainable shortest lead time. Now lead time is from concept to cash or order to cash. The more we shorten that lead time, the better our organization is going to be. The faster we get revenue and the more we realize the benefits of what we're doing. So we want to shorten that time. Now we do that through a couple of things. Number one is we reduce delays or we eliminate delays between different activities to reduce that lead time. We also remove non-value added activities. We want to provide the best quality and value to our customers, the people that consume it and society as a whole. We also want our customers to be delighted and have the best experience they possibly can for what they're paying for. This is the goal of lean. It is called value. Now Mary Poppendeek, we like one of her quotes where she says that we need to figure out a way to deliver software so fast that the customers don't have time to change their minds. Now it's kind of funny, but if you think about it, isn't that where the value is? I want something today and if you deliver it to me tomorrow, I'm going to be happy because that's what I wanted. But if you deliver it to me six months from now, I'm going to have changed my mind and it's not so valuable to me anymore. And also Al Shalloway, our good friend, says that most project or most software problems exhibit themselves as delays. In other words, the delays between the handoffs between Agile teams or individuals in an Agile team or different parts of the organization, these functional stacks, those delays create the biggest problems. Now, this thing is freezing up here. The thing we're going to have fun with is for the next, I think 20 slides or so, is we're going to map the lean principles that I'm going to show you to the skilled Agile framework. That's why you have that piece of paper in front of you and a pen. So in this case, we're going to map the value of the goal of lean, which is value, into the portfolio. We're going to show you step by step how the skilled Agile framework is founded on and fundamentally supports these lean principles. So in this case, the portfolio, and of course you don't know the skilled Agile framework that well because we haven't taught it to you, but you can kind of see, you can get the lay of the land here. And so there are certain areas of the framework that lend themselves to being underpinned or being based on these lean principles. So to deliver value, we have this thing up here called these investment themes which support value streams. So if we understand the lean principle of value streams and how value flows to the organization and we see that a portfolio is in support of one or more value streams, then we see that how we're organized supports this lean principle of delivering value. We can also look at the program level. For example, we have PSI objectives. The PSI objectives are the things that the business owners hold the program accountable to. The program itself defines what those business objectives are for that PSI, that 8 to 12 week increment. And then we commit to those objectives. And the Agile team, the Agile team itself has objectives in terms of sprint goals, right? We have sprint goals and we have sprint backlog. So we commit to that. So this is one way that we can be sure that we deliver value. And this is how the framework supports this notion of value delivery. Also this thing called the Agile release stream. It is a long-lived metaphor that we use to show an Agile program in motion. The Agile release stream is always moving. It's this continuous development flow. That's another way we show how we deliver value. And we are held accountable by our business owners and our customers for that value. Now, the next principle of lean, the house of lean, is the leadership. It's the foundation. We recognize that in order for us to be a lean organization our management must be trained to help us get trained in lean thinking. Lean thinking is a state of mind. And we base lean thinking on some of these principles and we use them to create long-term, or better decisions, long-term. Now, let's have some fun. Let's look at some of these things right here. Lean thinking, these managers we call manager teachers, lean thinking manager teachers, become better at understanding these lean principles. Where do you think in the framework that this foundation of lean, which is leadership, is supported? So what I'd like you to do is take your pen and work with your teams. And I'd like to take three minutes and everybody map where you think, we're right here, we're in leadership, which is right down here. Where do you think leadership maps into the scaled agile framework? So go ahead, work with your teams. I'm going to give you three minutes and I'll time it up here. Okay? And you can make as much noise as you want. I don't care. I want you to talk. Be happy. Sorry? Okay, repeat the exercise. The exercise is, so notice in the last one here we mapped where this lean principle of value, we mapped it into the framework. We said how does the framework support the lean principle of value? In this case, what we're asking you to do is say how does the framework support this lean value of leadership? That leadership and leaders must be lean thinking, manager-teachers. Where in this framework do you think that is appropriate? And just draw the lines from leadership up to the parts of the framework. Do you think support that? What we think it is. So what we're showing here is we're saying that the lean principle of leadership being lean thinking manager-teachers is embodied in this notion of the program portfolio management as well as the product management team and the release management team. These people are, if they think in lean terms we know they're going to support us in a way that we can then create value very quickly. We also have this notion of business owners who participate in the agile release trends in support of the value stream delivery. And these business owners are fully fledged, engaged members. They are essentially work very closely with the agile program and the agile teams to make sure the value is delivered. When the agile program commits just like an agile team commits then they hold us accountable. But they are also part of the solution. Oops. That's my time. Sorry about that. So that's how we mapped. What were some of the ways that who wants to volunteer and say how you thought leadership was mapped in the skilled agile framework? This lean principle. Product owner as well. Excellent. Well done. Okay, let's move on to the next one. So the next principle of lean is respect for people. Yes, sir. Portfolio or program. Yes. So we go back to the previous slide. Product manager or product management team is the Uber product owner. They own essentially the solution at the program level. And then there's a team up here called the program portfolio management team, the PPM that owns and is responsible for the content authority of that program and the value delivered in support of those values. That's correct. The team owns their own backlogs and there's a product manager that owns the program back which are the higher order features. Alright, so respect for people. What we're trying to show you here is this is a lean principle. That respect for people is absolutely key to the success of an agile organization. If an agile portfolio or agile program does not show respect for people, the people will disappear or they will not do the appropriate amount of work. Our goal is and our job is to develop people because they're the ones that develop software and solutions. We want to empower those people and the teams to do the best to innovate and be the best they can possibly be. And we want to build the partnerships between management and the teams based on trust and transparency. So these are some of the values that go along with that. Let's take a moment now and using respect for people. The respect for people is up here in respect. Where do you think this lean principle is embodied in the skilled agile framework? How does the framework itself, what constructs in here, do you think contribute to respecting our people? So go ahead and take two minutes and map those again from respect down into the framework. And go ahead and collaborate with the people around your table. And for those in the back, just collaborate amongst yourselves. Two minutes. Okay, 30 seconds. Let's look at potentially some of the mapping. So in this case, respect for people, we have agile teams. They're self-organizing, self-managing. There's one way to show respect, right? So we build on this fundamental agile principle. What's another way? Is that managers develop individuals and teams. In other words, their charter is not to direct what those teams are going to do, but to create an environment within which the teams can operate in a very, very effective manner and use their own creativity and knowledge in which to execute. So this is a couple of ways that the skilled agile framework supports this lean principle of respect for people. Kaizen mind. Kaizen, the Japanese term that means change for the better. It's these small incremental changes that we do, that we implement to make us always better. And it's relentless change. We're never satisfied that we've achieved perfection. There's always something we can do better. So Kaizen says that we always reflect and we always improve. We do this at the team level through the retrospective at the end of every sprint. We do this at the program level at something called the inspect and adapt workshop, which is a higher level retrospective for the entire program. This is how we continue to improve. Now, how do you think, and I just kind of gave you some answers there, but how do you think the framework supports Kaizen mind, this lean principle of Kaizen mind? Take, now we're going to go down to one minute and 30 seconds. We're going to make this even harder, right? I keep reducing the time. You notice that? So one minute and 30 seconds. Go ahead and map how Kaizen mind is supported by the framework. Okay, time is up. Where do you think these mapped into? Where do you think Kaizen mind is supported by the scope and by the skilled angel framework? Who wants to shout it out and just booting up there? The inspect and adapt workshop at the program level, retrospective at the team level. That's exactly right. Architectural runway. Thank you, good. What else? Metrics? Yes, metrics at the portfolio level, right? We look at metrics at all three levels. Refactoring, that's right. Kaizen is about refactoring too, right? Making our product better. Quality. Excellent. Are we going to get our thing back there? Yeah. Yeah, that looks great. Well, gee, it only took us an hour to get there, right? Okay. So these are some ways that the skilled angel framework supports Kaizen mind. Where we can show these lean principles. Now, let's get into the middle column of the House of Lean. It's called Product Development Flow. Now, there's this fellow by the name of Don Rynardson. He wrote a book called The Principles of Product Development Flow. It's a very good book. And it talks about taking these lean principles from lean manufacturing and transforming them into principles that we can follow as IT people. So he basically says that flow-based processes are the key to the future of developing high-fidelity, high-quality solutions that can be delivered quickly to our customers. It's setting up this notion of the software factory where we have all of these assets aligned into this common vision and mission. So the Product Development Flow there are eight principles and we're going to go through each one of these and we have 20 minutes to do that and I think we'll get through because we've got a late start. The first one is take an economic view. Remember I said earlier that economics, that we as IT people need to better understand the economics of decision-making in our world. Because we are getting closer and closer to the solution from a business perspective. We need to start thinking like business people. We need to start thinking and lean in terms of economics. And so we have these variables that we're constantly challenged by but we have these principles now and we break everything down to economics because that's how we measure value is through this common economic framework. So without going into a lot of detail here where would you think the economics are mapped into the scaled agile framework? So go to your papers again look at principle number one take an economic view and where do you think we can get a better understanding of the economics of what we're building. Why it's important to have to build this thing now what is the value of building this thing now to our business and to our customer. One minute 30 seconds talk amongst yourselves go ahead and map that out. Where do you think the taking an economic view understanding the economics of something is supported by the framework this lean principle. Value streams understanding the value streams roadmap and vision absolutely and deliver on demand very good. Let's look at what we think at it. Based on committed objectives business value here teams commit to PSI objectives and the program objectives are based on the business value that is delivered. We also have sorry PSI potentially shippable increment it's a higher order increment of capability than at the team level program level and the agile release train of course and then we use this thing called weighted shortest job first which represents a lean economic manufacturing that we use to determine what are the most valuable features that we can build and deliver at any one time. Let's go to the next lean principle of product development flow which is actively managed queues there's this whole notion of queuing theory and if we study queuing theory and we relate it to software engineering we realize that we want to have short queues so when a team's backlog is 100 items long what happens to that team it's just too much work right they just can't really get their brains around there's too much to reason about so we keep that backlog short we have maybe enough stories on our team backlog to support one and perhaps two sprints and that's really all we need well we do the same thing at the program level we keep that program backlog short maybe 20 to 25 to 30 features that's all so this goes back to queuing theory we keep the queues short where do you think in the framework that we support this notion of keeping queues short go ahead and take a minute and 30 seconds map those, talk amongst yourselves and let's think about this here's one answer short queues based on little's law and we keep our backlog short team backlog and our program backlog short we also keep our portfolio backlog reasonable we use a portfolio Kanban system to make sure that we limit the amount of work and process that is being done within the program and the portfolio at any one time these are some of the ways that the framework supports the lean principle of managing queues principle number three is understand and exploit variability the idea here is that we structure our capacity utilization around the ability to flex to changing customer need and we work in uncertain conditions software is a very non-scientific engineering discipline scientific but there's a lot of uncertainty we're always adapting and reacting changing circumstances so when we create certain constructs when we use certain constructs to allow us to adapt to the variability and the uncertainty that is certain to happen in our world where do you think in the framework that we would support this lean principle of being able to react in an uncertain world so go ahead take another I'll make this one minute and 15 seconds okay let's look at what we think it is so sprint planning sprint planning allows us to adapt changing circumstances we do it every two weeks the farthest the field we can get is two weeks the most time we can waste at the team level is two weeks before we readjust our plan we also have something called the hip sprint the hardening innovation and planning sprint it's another way to be able to deal with uncertain conditions we have that little buffer at the end of a PSI to make these final adjustments notice that our planning horizons are fairly short for a team that's two weeks for an agile program it's 8 to 12 weeks and for a portfolio it's 6 to 12 months so we keep these planning horizons short enough to be able to adapt to uncertain conditions the next lean principle of product development flow is reducing batch size we keep the batches small and there are many reasons for this number one is there's a cost to holding on to something it's called the holding cost and the longer we hold on to requirements or design or code without getting some feedback the the less likely we are to have a quality product so we want to get that we want to keep those batch sizes small how do you think the framework supports this notion of or this lean principle of keeping batch sizes small go ahead and take one minute she's right one minute we keep making this faster because you guys are getting better and better one minute to map this principle into the framework look what we think it is we essentially reduce or balance the holding cost versus the transaction cost by managing our batch sizes in terms of spreads we keep those small we also keep the batch size small at the program level there's something called a system team which is responsible for managing the integration and the NN testing of the integrated system as it's developed by these agile teams and the use of the system team combined with DevOps allows us to reduce the size of transport of that integrated system into production but these are just a couple of ways who has some other ways that they think that the scale nodule framework helps reduce batch size yes sir the responsibility of the DevOps team is to make sure that the integrated solution is easily transported into the production production environment yes to make sure that we have that communication if we just throw it over the wall to operations that represents a delay and potential handoff that could be problems we experience that all the time so we want to get the DevOps integrated into our software development factory the next one apply whip constraints we keep working process low for economic reasons we want to make sure that we do not exceed our capacity and we want to be able to flex to learnings that take place during an iteration and during a PSI how do you think that the framework supports this lean principle of managing working process keeping working process to the point where we are not overwhelmed by too much work go ahead and take 50 seconds 50 seconds to map this time is up let's look at what we think it is we constrain whip by making it visible now this is not necessarily on your diagram right here but we use big visible information radiators or BVIRs in a Kanban like manner to identify and make visible working process at the team level and as well as the program level we also use the portfolio Kanban system Kanban is a great way to make working process visible as you anyone that's used Kanban it knows so these are the mechanisms that we use in the framework to support this lean principle called manage working process principle number six we have three minutes left and I'm just going to breeze through these last three principles because I want to respect this time box and get you out on time principle number six is control flow under uncertainty we talked about cadence and synchronization aligning those agile teams I'm going to cut right to the answer here that we do this through the implementation of the short time box so two weeks and eight to twelve weeks at the program level are the time boxes the predictable cadence that we establish for agile teams and ultimately agile programs and we limit the variance to these integration points that happen at the end of every sprint so the system team and the DevOps team work to integrate these assets as the teams are building them during these two weeks sprint so we don't have this big bang integration we have a continuous integration cycle so that's another way to deal with uncertainty in terms of cadence and synchronization principle number seven we have one more after this is get feedback as fast as possible in the skilled agile framework we are very keen on getting feedback and so we do that through the demo and the retrospective at the team level we also do it through this inspect and adapt workshop and system demo that happens at every two week increment and especially the system demo where all the integrated assets of those multiple teams come together for that PSI or that release cycle the last principle of product development flow is decentralized control this is a lean principle decentralized control by giving content authority to the product owner and the product management team to make the decisions about locally about what are the best stories and what are the best features to develop at that particular time that provide the most value to the customer additionally we use centralized control at the portfolio level to create or to define principles at a higher level that are more infrequent and then we allow the programs and the teams themselves to establish the objectives for shorter time boxes alright that concludes this presentation I want to just say that you can take you can take all of this, the pen, the paper everything there's a card here that explains that at the skilled agile academy we have regular training I will be teaching a three day course that results in a high certification here in Bangalore in about six weeks I believe it's April 7 through 9 so if anyone's interested in learning more about the skilled agile framework taking it back to your organization and becoming what's called a safe program consultant or an SPC that certification is offered here I did one here in August and Ranjan and a few other folks went to that and they are now practicing SPCs back in the organization and they can talk to you about the benefits of it so I just wanted to let you know thank you very much for your attention I hope you had fun, sorry for the late start