 All right, welcome to this enterprise day. This rocket is carrying the Mars climate orbiter. It's December 11th, 1998. And the purpose of the spaceship being carried by this rocket is to study water and water distribution and atmosphere on Mars. After launch, it's going to spend 286 days in space, traveling 669 million miles or a million kilometers. It's going to arrive on September 23rd, 1999. Upon arrival, the main engines will fire for 16 minutes and 23 seconds to slow into orbit. And then it's going to use the solar panels to drag against Mars' atmosphere to gradually convert that wide elliptical orbit into a nice circular orbit. So here we are, December 11th, 1998. The spaceship being carried by this rocket costs $193.1 million to develop. The launch costs $91.7 million, and there's $42.8 million budgeted for mission operations. $327.6 million total. This is part of NASA's smaller, cheaper, faster initiative. 286 days later, September 23rd, 1999, nine o'clock and 46 seconds universal coordinated time, the main engine fires. 9.04 a.m. and 52 seconds, communication is lost. This is expected. The spacecraft is going to pass behind Mars' shadow. It's going to block communication with Earth. But it's a little bit early. It's one minute and eight seconds early. Communication is expected to be re-established at 9.27 a.m., so I can only imagine that the mood in the control room was tense as they waited for those minutes and seconds to tick by. 9.24, 9.25, 9.26, 9.27, 9.28. Communication is never re-established. And two days later, the mission is declared a loss. $327.6 million, countless years of effort down the drain. Now this is NASA, and NASA being NASA, they investigate and they figure out what happened. What happened was that the trajectory was just a little bit off. It entered orbit too low, and instead of dragging against the atmosphere and forming a nice orbit, it instead burned up in the atmosphere and was lost. They investigated further. NASA's good at this. They take their root cause analysis very seriously. And what they found was that one team that was producing information for some of the trajectory calculations produced their information in a pound seconds of force. And the team that was working, that was depending on them, expected the answers to be produced in Newton seconds of force. So it was a U.S. metrics measurements versus metric measurements problem. The moral of the story is that large systems are hard. And every time you have cross-team coordination, you're subject to delay and error. And if it can happen to NASA, which is famous for their code quality practices and their attention to detail, and spending huge amounts of money on these problems. If it can happen to NASA, then it's gonna happen to you too. Cross-team communication is hard, and yet as agile has become more and more popular, more and more proven, it's being used on larger and larger problems. How do we make agile scale? How do we grow agile to work in these larger problems? Well, before I answer that, I wanna make a definition. I wanna define what I mean by large scale agile. Large scale agile is a system of interdependent agile teams. Teams that have to work together in order to get their work done. They rely on each other to achieve a joint success. So if you have an IT organization with 500 teams, that's a lot of teams. But each team has their own stakeholders. Maybe they do a bunch of sequential projects. A team takes on a project, works for its stakeholders, and then delivers the project, goes off and does something else. If you have a situation like that where all 500 teams are working independently, that's not large scale agile. It's big. It's a lot of teams, but each team is working on small scale agile. You don't need to coordinate. Conversely, if you've got 20 developers in a company, and they are in multiple teams working on a single product, that's large scale agile because those teams have to coordinate, and now you have the problems of cross-team coordination. You've got the delay and error that results from cross-team coordination. So large scale agile, despite the name, isn't about the size of the organization, but rather about the existence of the need for cross-team coordination. Large scale systems are air prone, and I would suggest avoiding them if you possibly can. Rich Sheridan, who gave the keynote on Tuesday morning, he's the CEO of Menlo Innovations, and he's got 70 people, 70, 80 people in his organization, all on one team, which means that he gets to avoid these problems of large scale agile cross-team coordination because they all work together on all of the projects. They do a lot of very rigorous pair switching and code ownership and code quality practices to make this work. But eventually, it's very likely that you're gonna be on a product that has a need to involve more people than even that. And I think that for most organizations, 70 people is gonna be an outlier. I don't think that most organizations will be able to get up to the level of rigor that Rich is talking about. And you're gonna need these large scale ideas. Existing approaches to scaling agile tend to focus on what's safe and acceptable, and it's even in the name of one of them. We've got safe, less, nexus, dad. I think we're gonna hear about dad next. The problem is, is by focusing on what's safe, what's palatable to the enterprise, I think they're missing some of the spirit of agile. Now this isn't a dig at safe, even though I'm saying to avoid safety. This isn't a dig at safe, or the other methods that do this. That's an understandable attempt to satisfy the needs of the market. But this isn't where agile came from. Agile isn't safe and acceptable. The original idea is, I mean it's not that kind of safety. It's about doing things that are rigorous, creating great results, and that is actually a very safe thing to do. It's a very safe thing to produce software using something like extreme programming, which has a lot of attention to code quality. But it's not acceptable. It's not something that you can take into an organized organization and say, if you do this, you will never fail. And in fact, the early ideas were anything but safe. We had, they were bold, they were extreme. It was in the name of one of them, extreme programming. They rejected the status quo. Ward Cunningham told me, and I don't remember the exact details. I didn't write this down at the time. So I may be misquoting this, but he told me that Kent Beck chose the name extreme programming so that people who weren't willing to try it, so people who wanted to sell stuff to other companies wouldn't use it because the name was too extreme. He succeeded, unfortunately, maybe. Nobody uses extreme programming anymore. The people who wanted to sell something but didn't really know what they were doing, but wanted to make a quick buck, they migrated to using Agile and Scrum. That's not because Agile and Scrum are bad or wrong, it's just because they're safe. They're easy to sell. Can you imagine anything less acceptable than Agile in the early days? I was there, and I remember the countless flame wars that erupted from this work. We were telling people, don't plan things in advance. Don't figure out everything you're gonna program before you program it. Don't understand all, don't try to figure out everything that you want to build. That's lunacy. That's absolutely crazy. It is not acceptable and safe, but it works. And it works better than the other things people were trying. And so now the enterprise does want it. And they still want it to be safe and acceptable. And there's a contradiction here, isn't there? We have ideas that aren't acceptable, but a desire to package them so that they are. But you know what, let's not worry about that. Let's not worry about the enterprise. There's a lot of money to be made there and other people will solve that for us. For now, for today, let's think about what's going to work. Not what's effective or not what's acceptable, but what's effective. What's really gonna make a difference? What if we rejected the status quo? What if we rethought team coordination and planning and ownership? That's what this talk is about. Now this isn't just theory. My current client is over 1,000 people. I can't say how big the engineering organization is in this company, but I am allowed to tell you that the office that I'm currently working with has about 300 people in it, the primary office I'm working with. I'm typically, and that's typical, I typically work with organizations that have up to 200 or 300 people in the engineering organization. I'm usually brought in by senior execs, typically at the C level. And what's neat about being brought in at this level is that the folks who bring me in, the people who work at this level, they are excited and looking for inspiring ideas. They're excited by cutting edge, excited by innovation. And the work I do is intensive. I usually work day in, day out with a company for several months and then I follow up for a year after that and then I usually stay in touch in the years that follow. What this means is that I get to see what happens when my ideas run up against the hard rocks of reality because we always have beautiful ideas that look perfect and wonderful and wrong until we try them and then we learn new things. So I get to see the consequences of my actions and as a result, what I'm doing today and what I'm talking about today is very different than what I originally wrote on the subject six years ago. That said, even though this isn't all theory, it's not proven either. When I was working with teams doing team immersion, I was seeing that things were pretty predictable. Given a certain context, there was an obvious set of practices to put into place that would lead to good results. It wasn't easy and for those of you who are team coaches, you know that this is not easy but there's a lot of books on the subject. I wrote one, too. And you pretty much know how to do team level agile. At the enterprise level, no, not at the enterprise level, at the large scale agile level, these multiple interdependent teams, I'm learning new things every single time I work with one of these companies. So the ideas I'm gonna present to you today are not proven ideas, they are just the latest in a sequence of ideas. I am slowly assembling a suite of principles and practices but it's not done yet. I also wanna, I'm not gonna mention any company names in this talk but I do wanna say thank you to the people who have worked with me in these various companies. They actually have done a lot of work to help develop these ideas. It's a black screen, there's nothing wrong. There's nothing wrong, this slide is blank. Thank you. So I can't say the names of the people who have helped develop these ideas but you know who you are and think. Of course, everything needs a name, right? We need to know what to call this. We've got SAFE, we've got LESS, we've got NEXUS, we've got DAD. So what should we call this? Let's call it bold, bold, be bold. Oh, now we do have a problem. Okay, so bold, what does bold mean? Now that we've got the name, we've gotta figure out what it stands for. Let's try big, audacious, lifelong dream. Terrible names, forget it. Let's just call it the shore model. March 2016 edition. There are no courses, no certification, no fancy website. This is just me talking to you about what I've seen, what I've experienced and what I think. And I hope you'll take these ideas and be inspired and try some ideas in your organizations and then tell me about it. And there'll be you talking to me about your experiences and about what works. And I'll take those ideas and I'll steal them and I'll try them out and then we'll have the March 2017 edition. So yeah, just some ideas based on experience and a desire not to accept the acceptable mediocrity but instead to try to create something great. So what if we rethought all these ideas? What if we rethought team structure? This here is a picture of the teams and dependencies at one organization I have worked with. I am not lying. This is totally true. By the way, could I get some water please? Every card, thank you. Every card on this picture is a team. Every line is a dependency. And if dependencies result in delay and error, you can imagine that there was a lot of delay in this company. Is this something unusual? I don't think so. I think this is pretty typical. I would guess that most people have not gone through this exercise. It wasn't easy to create. We affectionately call that the spaghetti diagram. It wasn't easy to create that spaghetti diagram. It took us about four hours of about 30 people all working together from the various teams. And if the organization had been any larger, I think it would have exceeded the ability of our brains to figure out how to group things. Because we did, believe it or not, we tried to group it so that things with the most dependencies were closest together. But I don't think this experience is unusual. Those of you in the crew, how many of you are in an organization with more than 20 teams who are interdependent? How many of you think, keep your hands up. Keep your hand up if you think that your diagram would look something like this. Put them down if it's nice and clean. I saw two or three people out of the 20 that raised their hands put their hands down, maybe 30. I think this happens because of a very obvious thing to do. You've got a team that's working on a product, and it's a nice cross-functional team. Let's say it's a software as a service website. You've got a nice cross-functional team and they are doing everything on the site, and the product is successful and the team grows. And eventually it gets to the point where you just can't be effective as a single team anymore. So you split, and how do you split? Well, the people on the team are programmers. I'm a programmer myself. And there's an obvious way to split things when you're asked to, and that's to split it the way programming is done. You split by layer. And that works fantastically in software where communication between layers is perfect and instantaneous. But for human systems, what you've now done is create a dependency for every single thing you want to do. Every time you want to add a new feature, you've got to make a change to the front end and to the back end. That's the typical split, right? Is to have a front end and a back end team. Now every single thing you do requires those teams to coordinate. This maximizes dependencies. So there is a common Agile alternative. It's feature teams. This was originally introduced by Craig Larmann and Boss Bodhi in one of the original books on scaling Agile. The idea here is that we have a single backlog and then a bunch of teams that can pull from that backlog. The teams collectively own all of the code. And whenever they finish their current feature, they just go to the backlog and pull the next one off. They can work on anything. This is a very Agile idea. Cross collective ownership, just go take whatever's next. It's very Agile. And I don't think it works. At least I don't think it works very well. What I've seen with feature teams, and I'm not the only one to notice this, is that it seems to lead to code quality problems. And it's very, very tempting when you're designing methods, particularly when you're designing enterprise methods to pretend that code doesn't matter and that all we're gonna do is structure the system. But we are building software and we have to pay attention to the fact that we're working in code. If code quality suffers, then our ability to get things done suffers. Then you start hearing people muttering about technical debt and legacy code and searching the want ads when they're supposed to be working. We have to pay attention to code quality, otherwise we can't get our stuff done. And feature teams seem to lead to problems with code quality. The thing is that collective ownership works very well inside of a team where you've got the peer pressure and the pair switching and the test-driven development, all this stuff sort of happening to keep code quality high. Hopefully you have those things. Otherwise you probably have code quality problems. But when you have collective ownership across teams, something very human takes over. We're basically chimpanzees, we're primates, and we love to form tribes. And then we love to throw poo at each other because that's what chimpanzees do. We form tribes and then we throw poo at the other tribes. Menlo innovation doesn't have this problem. And I think that's because they have one team. They have very rigorous approach to pairing across all their projects. They have a really rigorous approach to code quality and test-driven development. They have one team. But for feature teams where the teams are fairly stable but then they're pulling features from this common backlog, it's fairly easy when under pressure, when under time pressure. And we are always under time pressure, aren't we? Always. It's very easy when under time pressure to see something that's poorly done and to say, well, yes, we collectively own this, but that team wrote that code and that's their problem. We've got other things to do. Or conversely, to say, we've got a lot of pressure, we've got to get this stuff done. Yes, I know what we just built isn't that great, but one of the other teams will fix it. It's ironic that these two statements will come from the same team because they are mutually contradictory. Michael Feathers has said the same thing. He has a great talk-up. I recommend that you look it up. It's called Conway's Law and You. And he talks about how feature teams, as one part of a much bigger talk, he talks about how he has concerns about feature teams and code quality as well. So we need to rethink our teams. Before we look at that, I want to talk about dependencies. So what we want to do is rethink our teams to deliberately minimize dependencies, but I do have a specific definition of dependency. A depends on B if A needs B to do work for them in order for A to accomplish their goals. Just using another team's software isn't a dependency. And if you have a lot of dependencies, then you probably have a lot of delay and error as well. Now, I know this is a bit of an unusual definition. If you use Microsoft Word, in a sense, you depend on Microsoft, but you don't really depend on them to get your work done. They're not a source of delay for you. They may be a source of error, but Microsoft Word is pretty good these days. The primary approach I take is full ownership teams. This is actually a fairly well-established agile idea. What we do is when we want to have a, when our team grows and we want to split it, rather than splitting it by layer, we split it into separate teams that can own an entire segment of the market from UI all the way down to database, whole thing. So for example, if we have our Software as a Service web app, maybe we split it into three different market segments. We've got the landing page and sign up an account management team. We've got what you see when you're signed in team, that's the actual product. And then we've got maybe the administrative team that handles administrative work that the company does internally. And you can see how you could continue to split. The what you see when you're signed in team could eventually split into this part of the product and this part of the product and this part of the product. But even so, they'll own the whole thing from front to back. Every step of the way, we're trying to maximize ownership so that each team is completely in charge of the thing they own. They don't have to wait for anybody else to do anything for them. Those of you who have tried this know that I'm leaving out something very important, which is that this doesn't work on its own. In a large organization, you're typically going to have a lot of stuff that doesn't fall into this full ownership model. You're going to have some common needs, for example. Typically, you're going to have legacy code that can't be split up. You're going to have shared components, services, or databases. And you're going to have specialized knowledge that doesn't make sense, or you simply don't have enough people for every team to have one of those people. So you might have, for example, security needs or a user experience design that you don't have enough people for every team to have a user experience designer. So I have four techniques for you. The first is full ownership. It's the most powerful technique. And this is where I advise you to start if you're looking at your organization and how you can design your teams to minimize cross-team dependencies. We're looking at cross-functional teams, vertically integrated, so they've got all the skills on the team. We're going to accept some duplication of effort, and this is hard for programmers. But if you've got two teams and they're solving the same problem, let's say they're parsing a configuration file. And both teams are solving this problem. It's very tempting to say, hey, let's make a configuration file parser and pull it out into its own team. Let's dry it up. Let's eliminate our duplication. That's good coding, right? Well, yes, it is good coding, but it's bad team structure. Because building that parser is probably only a day or so of work. But introducing a new team and a dependency and a bottleneck so that anytime you want to change the parsing of the config file, you have to go to somebody else and wait, that's going to cost you more than that day of effort you've just saved. So what's the right amount? When do you split your teams apart? When do you pull those common things out? I don't know. I know that something that's a day of duplicated effort, that's not worth it. There's not enough benefit. The delay you'll get from that extra team is too high. If it's a year of extra effort, if you're doing some sort of highly scalable text search database and multiple teams need one of these, does it make sense to pull that out? If it's a year of effort? Yeah, I would say so. You're going to save more than a year from having a team do that for everybody. What about a week? I don't think so. What about a month? Maybe, a quarter? Probably. I don't know where that line is. That's something that I've yet to learn. But I do suggest that you not just automatically look at every duplication as something to pull out into its own team and create a new dependency. And something I want to emphasize here in full ownership, when we're talking about cross-functional vertical integration, we're talking about all the skills needed on the team to work on all the code, and the code base isn't shared across teams. Team owns their code base entirely. Of course, sometimes code base can't be split across teams. So in this situation, I've got a couple of ideas. One is collective ownership. So you've got teams that are each responsible for their own thing, but they collectively own the code base. You can have the boss body style feature teams. Or you can do what Menlo does and have mega team. That is more people than normal on the team. All of these are something to use sparingly. In fact, and before I heard about what Menlo was doing, I would not have said that you could have more than about eight to 10 people on a team if they were pairing. Less than that if they're not pairing. Probably three to five, maybe six. Not people, three to five developers. Three to six developers on a team, plus the other folks on the team that are not developers. What happens when you have a lot of people on the team is that so much work starts happening simultaneously that people can't keep track of it. I asked Ward Cunningham what he thought the largest number of people on a team could be, because he lives in Portland and so we see each other fairly frequently. And he told me that the largest team he had seen that was doing pairing was 30 people, but only 12 of them were actually contributing to the effort. I've personally been on a team that got up to 10 people pairing, 10 engineers pairing, and that was starting to feel uncomfortable. Rich mentioned to me at dinner on Tuesday that the largest, although he has a 70 person team, the most people he has working on a single project has been 30. So that's probably the limit for mega team. And if you're gonna use these ideas, use them sparingly. I think to do it well requires more overhead and less autonomy. Y'all have a very stony face look at you out there. So I'm gonna say it one more time. Mega team. Thank you, I love that. The company I'm working with now every so often, somebody just says mega team and everybody else goes mega team. We don't actually have a mega team. Sometimes you need to have a shared component. And the technique that I'm using for that is facilitated self-service. The key idea here is that if you can't use it right now, it doesn't exist. You treat the other teams as external to the organization. If Microsoft Word doesn't do what you want, what do you do? Either go find something that does. You build it yourself or you change your plans. Similar idea here. If some other team doesn't have it right now, you don't plan on it. You don't look at their roadmap and say it's gonna be ready on this date because you know what, it's not gonna be ready. You know it's not gonna be ready. And that's gonna create delay and air and when it does come out it may still not do what you really want. So if it doesn't exist, you build it yourself or you change your plans. There's various techniques for doing facilitated self-service. You can have an internal platform as a service for DevOps type of stuff. You might have your DevOps team build some sort of infrastructure maybe based on something like Amazon or using your own servers or whatever. If you have, let's talk about that software as a service web app example again. Maybe the team continues to be successful. Awesome. And they grow and they split off an accounts team because the account management is very complex. There's lots of sales and business rules and all these things that have to be managed. And so they provide an API to the signup team and to the do stuff while people are logged in team. But what if that API doesn't do what you need? Well, one thing that the self-service team can do, the accounts team to do, they can provide a lower level sort of raw API that doesn't do anything for you. It just gives you the data. And then it's the responsibility of the team to interpret that data well and they might need to do some caching if it can't be retrieved very often. It's more work but it prevents them from being stopped by a dependency. And then the fourth idea is consulting services. When you can't have a cross-functional team, when you've got stuff like security or user experience where you just don't have enough people in the organization for every team to have one of these folks or when the skills needed just aren't used that often. Like security, maybe you don't need somebody full-time doing security on your team. And because we're talking about full-time team members, what do you do in that case? Well, then you can have consultative teams. You can have a community of practice or a standards body. Sometimes you'll see this for like front-end, the front-end JavaScript folks might have a community of practice that talk about how to do JavaScript well and they may set some standards. Or you might have the backend team or you might have the architecture team producing standards. You can also have rotating embedded experts. The team actually provides experts to join other teams as needed. I like to see, one thing I'd like to see more of is something I call roving bands of feral architects. Architects and organizations tend to be these sort of ivory tower people presenting proclamations down from on high that actually don't work all that well because they're not grounded in experience with the actual problems that you're facing. So an architecture team that's consultative in this model might provide architects to go join teams and actually work with them and help work through those problems and learn from that, bring those ideas back and share them out with the rest of the organization. You can also have on-call consultants. One organization I'm working with does that with their user experience designers. They actually go out and can ask the designers for help. You can have sign off and review. I saw that with a security team that was really good at not being a bottleneck. What they did is they provided standards and then they would do a sign off on teams before they could shift or you could provide documentation and training. Various ways of being useful to other teams without getting in their way without being a bottleneck. There's a fifth idea that's coming from the company I'm working with right now. You all know who you are. Thank you for your help. And this is something that's basically the consultative model taken one step further. I really like these ideas. They want full ownership teams but they've got a big legacy application. And so they decided to create a couple of teams. They're gonna have a legacy extraction team whose sole job is to help other teams pull their piece of the big legacy spaghetti code app out and bring it into their code base so they can be full ownership. And they have another team which is the legacy quality team whose entire job is to deal with the fact that this is joint commit rights, collective ownership. And they'll be focusing on code quality of that system to make it easier to split things up. Also have some teams that do some very difficult technical stuff but to be full ownership there is a small UI piece but it doesn't make sense. The company doesn't have enough UI developers to put one on each of these teams and actually it doesn't make sense to have UI skills full time on these teams. So instead what they're gonna do is establish a UI enablement team to help train up the people on these teams to do their own UI work and possibly also provide some infrastructure, some copies, some examples to copy and so forth. I do have some assumptions here. I'm assuming some basic agile concepts. We're talking about the team as the primary resource. Organizations love to talk about the resources in their company and what they really mean is the people, right? They'll say, I'm gonna assign a resource to this project. I'm gonna assign a resource to that project. They're saying, I'm gonna move Prashant over there and I'm gonna move somebody else over here. The, in this model the team is the primary resource so when you have a product or something that you want done you're gonna say I'm gonna assign this product to that team. And then the people on the team stay on that team full time. They're 100% assigned. The teams are long lived. You don't start a project, put a team on it and then stop it. Instead teams own products, full ownership of their piece of the market. For as long as that product makes money or otherwise produces value. And the team has all the skills and technical resources in terms of computers and cloud systems and so forth needed to do their job. We're talking about a lot of autonomy here. A lot of independence of these teams but there is a need to maintain the overall system. And one of the ways that I've seen this done is through an architecture team. The role of the architecture team is to be out in the world. Those roving bands of feral architects is one technique. Looking for mismatches between teams and responsibilities. Looking for the situation where there's been too much attempt to reuse something and putting that back into the teams or when there's big problems that multiple teams are solving that would make sense to pull out into a new self-service team, facilitated self-service team. And most importantly, they're helping the system continuously adapt and improve. But notice that I didn't say that they are continuously adapting and improving the system. They are a supporting role. They're not dictating. They're not shouting down the architecture laws from on top of the mountain down to the huddled masses. So to summarize, five techniques, full ownership, joint commit rights, facilitated self-service, insulting services and full ownership and enablement. What if we rethought teams and focused on eliminating cross-team dependencies which is one of our primary sources of delay and error. And most of the stuff I see about Large Scale Agile ignores this problem entirely. Probably because we're talking about big changes here. And when I work with companies doing this, we do big changes. We actually look at the entire organization and redesign what the teams are very collaboratively with the rest of the organization and then go out and do it. One technique for, once you've designed the teams, one technique for getting people to go onto those new teams is something called team self-selection. Where actually teams, people choose their own team subject to skill needs. It's a really neat technique, there's a book out on it, a new book that just came out on it. And I don't remember the name of that book. Shane, do you remember the name of the book that I'm talking about? Sandi Mamoli and David Moll, I think the book may be called Creating Great Teams. And team self-selection's been around for a while, but it's really starting to gain currency. I've done it myself just once so far, but it worked extremely well. And I'm gonna do it again very soon. All right, let's talk about idea flow. What if we rethought idea flow? Idea flow is what most people call requirements. But when I'm talking about idea flow, I'm talking about how ideas flow throughout the organization from initial conception, wherever they might be in the organization, through prioritization and winnowing out and rejecting and throwing away all the way down to teams actually making the change and shipping the software. There's several problems that stand out to me about the way idea flow is done at most organizations. At many organizations, there is a value for the illusion of progress. So we wanna see progress being made even if it's not very effective. There's a lot of local optimization. So people are moving resources, by which they mean people, onto whatever the emergency of the moment is. They're surging in response to pet projects. So maybe sales has got a big customer that they want to convert. So they'll say, okay, everybody drop everything and go work on this and they'll move their resources, by which they mean people, onto another team and completely destroy all the consistency and code quality that they were trying to create. There's also a tendency to focus on schedules over value. They say, when's this going to be done? Or more often, this will be done on this date. And tell me what you need in order to get that done. And then they'll move people onto the team for a little while until the next priority comes along and they'll move people back up. That's a great way to destroy team cohesion and quality, by the way. Let me show you something neat. Imagine you've got just a single team. Imagine you've got a single team with three things they could be working on. And each one takes two months. And if you earned an organization that values the illusion of progress, they will work on all three simultaneously. So they can demonstrate that they are making progress on all three goals. So each one takes two months and we'll assume a perfect world where there is no cost of task switching. In which case, it will take six months to do all three. And then at the end of the six months, six months, you'll make some money. By the way, this perfect free task switching, it's a lie. The actual time required for this is more than six months. Task switching is very expensive. But we'll ignore that for this example. Now let's say this organization had an epiphany and they realized that they didn't care about the illusion of progress, but instead they cared about being more effective. If they did, they could try working on one MMF, one thing that can be delivered at a time. In that case, they'd work on the first one and ship it. And while they're working on the second one, the first one would start bringing in money. And while they're working on the third one, the second one would start bringing in money. And by the time they got to the end, the third project would still take six months. But the first one would only take two months and the second one would only take four months. And at the end, they would have gotten four or six months of free money. That's astounding. And this is obviously a made up example, but there are real examples out there of how this can really change the return on investment in your organization. A book that I recommend is called Software by Numbers by Jane Klin-Lan Huang and software by numbers. So one thing I strongly recommend is working on one minimum marketable feature at a time. A minimum marketable feature is the smallest thing that we can ship that brings value, that actually has some sort of concrete tangible result for the organization. It's not always bringing in money, but it's doing something useful. Another thing organizations love to do is move people around. That leads to a need for something called resource shaping. How many of you are familiar with resource shaping? How many of you like resource shaping? One person, two people. Do you sell resource shaping software? Okay, just checking. Resource shaping, I am gonna go out on a limb and call it the worst idea in the history of software development. Because it's this idea that we are gonna very carefully plan our projects so that the person with this expertise is gonna come up and work on a project and then right when they're getting done and we're ready for the next person, we'll bring the other person up and they'll come onto the project and then we'll bring the next person and the result is this nice smooth flow of steady progress. And that would work perfectly if software was perfectly predictable and nothing ever went wrong. That never happens. So instead what we get is people are delayed, so there's this big trough where nothing's happening and then people will come on all at once and then there's too much going on and then somebody's starved and it's a big mess. So the agile idea is very simple. We have teams as our resource. They work on one thing at a time which means that our resource shaping is very simple. We are either working on your stuff or we are not working on your stuff. We are 100% on the current MMF until it's done and then we are working on something else, some other MMF and 0% on your project. That makes resource shaping extremely simple. It's just what are we working on right now? Now neither of these are large scale issues. The one MMF at a time, the 100% or nothing resource shaping which it can't even be called resource shaping just the way we work is what people can and should do on single team projects as well. In large scale systems we have the problems of surging. We've got the need to respond to enterprise sales needs perhaps or some new idea that the CEO came up with. So one approach that we're looking at is actually I've used both of these before. One approach is to have a sales response team, a team that's dedicated just to serving the needs of people who are trying to make enterprise sales deals and they will build whatever is needed for those teams to close their deals, dedicated team for that. Another thing that I've seen is at one company the CEO was particularly entrepreneurial, had all kinds of new ideas. Actually I've seen this a couple of times. And so they built a new market exploration team. And the entire purpose of that team was to take all the new ideas that the CEO came up with so the rest of the teams could continue working without being interrupted. And so rather than being a team that was working on product X, they were working on whatever the CEO cared about at that moment which changed on a fairly rapid basis. Even with these things you still have a need for rapid responses. Let's say you've got a really big enterprise deal and the enterprise sales team isn't gonna do it. You actually need to demonstrate the ability to do something new in your software. In that case, something I've put into place is a rapid response queue. This is a dedicated work for the important stuff that must be done right away. But in order to prevent this from overwhelming the more strategic ongoing work of the company, we keep it to very limited scope. Each thing must be able to be completed in, oh, let's say less than two weeks. And we have a tight work in progress limit on this queue. Once you've got three things in the queue in progress, that's all you can have. Then everything else has to wait and just go through the normal prioritization mechanism. Now this doesn't address all the problems that I see with idea flow but before we can talk about what's next, let's talk about how we could rethink ownership. By the way, for those of you who are looking at your watches, the schedule says 9.45 is when we're done but we're actually done at 10. I checked so don't worry. I came up to Noresh last night. I said, Noresh, I've got more than 45 minutes of content. What am I gonna do? And he said, don't worry, that's 15 minutes for questions. I said, okay, I'm gonna steal that. And then if you have questions for me, just come talk to me in the hall. Let's rethink ownership. So the idea of the product owner may be the worst idea in the squad. Somebody said, thank you. One person who owns the backlog, as Shane Hastie mentioned in his workshop yesterday, the idea that one person can do this very challenging work is laughable. And also I don't like the idea of one person having the ownership, like making all the decisions about what's going to be done. The people who are in this role are often overworked and frankly underskilled. They usually don't actually have the knowledge or authority, the real authority in the organization, to own the backlog. Instead what they do is they go out and they ask questions of other people and get permission. And because they're overworked and underskilled, they leave out important things that the rest of the team needs to knows needs to be done, but they haven't gotten permission for it. I've actually seen very commonly that one product owner is assigned to multiple seniors and they are just not able to get anything useful done when they're overworked like that. This product owner idea has infected large scale agile. We often, you often see the idea of a master portfolio backlog that decomposes down into program backlogs, that decompose down into team backlogs. This is a very rational thing to do but I don't think it's a good idea. And each of these have an owner. We've got the portfolio owner. We've got the program owner and then we've got the product owner. Somebody who has final say over the work of the team. But the problem with this is that this is sure to leave out important priorities that are too small to make it up to the radar of the portfolio owner. Let's say you've got a self service, so let's say a self service team that is responsible for your database that you do a lot of searching on. This is a hard problem and scalability is always a challenge for growing companies. The team sees this coming. They say we need a minimum marketable feature that is about increasing scalability and the value of this, this isn't a technical MMF, this is a business MMF. The value of this is that our company doesn't go out of business next year when we stop being able to serve customers. They see this coming, but it's not on the radar of the portfolio team and often it's really not on the radar of anybody, it's not scheduled into the team's backlog until things are already falling over but this is a hard problem and it's not solved overnight. Any of you been in this situation? Couple of hands. Most importantly, there's a really foundational principle of Agile which is that the people closest to the work know the most about the work being done. And shouldn't that be true of the market as well? We're talking about full ownership teams. Shouldn't these full ownership teams know the most about their portion of the market? This is a bit of a leap of faith. If you're familiar with the Agile Fluency Model, Diana Larson was here last year and she presented a workshop on it. If you're familiar with the Agile Fluency Model, what we're talking about here is optimized value teams. This is something that is not appropriate for many organizations. It's difficult for many organizations to accomplish because it requires that you actually bring into the team business expertise and that takes an organizational structure shift and that's hard. But we're bucking the status quo. We're saying what if we don't say we're not looking what's acceptable or easy, we're looking at what's effective because that's how Agile started and that's what I wanna do today. So yeah, let's go ahead and say we have three star teams. They may not be fluent but they are working towards proficiency at this level. So we are giving them authority and ownership over their slice of the market. So let's say that you are working towards three star fluency, now what do you do? Well now we don't have to have a master backlog and tell the teams what to do. We don't have to push our MMFs to the teams. Instead we can trust that the teams know their piece of the market better than anybody else and have them generate their own backlogs entirely on their own. So let's bring it all together. There is a need to have strategy. You don't want every team to just go off and do their own thing. You do need strategy that ties the organizational priorities together. So one thing that I've looked at is the idea of a product council that is responsible for the organizational strategy. What are the big ideas that the organization is pursuing? And what they do is they create a list of, at my current client they've decided to have them create a list of press releases. Each press release is something that they want to be able to send out when the work is done to the press. This is what we have done. These are strategic things that are gonna make a splash. And then teams use this list not as here's what we have been told to do but instead as inspiration. As they are defining their own backlog, as they are deciding on their own list of MMFs, they pull from this list of press releases to help them come up with those ideas. But they can choose to do something else. For example, a database team may choose to work on scalability instead of whatever the top most important press release is about. They know their market better than anybody else. Teams work on one MMF at a time using whichever process they want. Remember we are talking full ownership. Teams can decide their own process. Presumably they break the MMFs into stories but honestly I don't know and I don't care. As long as they are working on one MMF at a time and shipping those MMFs from an organizational perspective, that's how we know that they're being successful. And as long as those MMFs are also satisfying their charter which I haven't talked about. But I'm assuming every team has a charter that says what the team's purpose is, what their market is and some measures of success that the team has generated for themselves but have been approved by management. Team uses whatever process they want, full ownership. They ship whenever they want full ownership. They define whatever MMFs and stories they want, full ownership and they do have to justify their decisions back to the product council. They provide demos and they explain why the MMF they're working on is the most important thing they could be working on right now. Some initiatives will require cross-team coordination even though we're talking about full ownership teams. You are still gonna have some big ideas that are gonna require lots of coordination between teams. On the product council are program coordinators whose job is not to manage the program but to help the teams involved coordinate with each other and to help them understand the big picture goals of the product council. There are a limited number of cross-team initiatives in flight at any one point because if you have too many, the system will bind up. You need slack in the system for these things, for everything to work together. So we strictly limit the amount of work and process, cross-team initiatives. Now this is a newer idea in smaller organizations where we've had this product council and the teams working independently. They actually just organically coordinated on their own but with my current client they're quite large and so we're introducing the program coordinator but I do need to tell you I have not tried this idea yet. So I don't know how it will work out but I can guarantee you that if I were to come back next year with the March 2017 edition of Shore Model then it would be different. What if, how it's gonna be different? I don't know. So the program coordinators are going to help coordinate these cross-team initiatives and of course there's always a need to search. Some organizations have it worse than others but there's a need for, when a big project comes along to have more people working on that, that my current client, the VP of product who reports to the chief product officer is particularly concerned about how they're gonna do this because historically they have solved their problems by moving resources, by which they meant people from team to team and we're saying you can't do that anymore. So the product council is going to have a couple of surge engineers. These are people who are really experienced in organization have exposure to a lot of the different code in the organization and the product council can put wherever they want. This is another new idea and honestly I am not sure it's a good idea. It's very in line with this company's culture so we're gonna try it but I'm generally not a fan of moving people around like this, I don't believe, there's the Mythical Man Month, programmers are not interchangeable parts, we'll see how it works. And let's also not forget the rapid response queue. Again, there's gonna be some initiatives that come along from sales or from the CEO that they want to resolve right now so we have the rapid response queue which consists of MMFs of strictly limited size and a strictly limited number and unlike the press releases that the teams pull these are actually pushed to the teams so the product council gets to assign MMFs to teams. This is another new idea, we'll see how it works out. I've done the rapid response queue before but the ability to actually override the teams decisions, I'm not so sure about, got 90 seconds. It's easy to get it caught up in the pretty pictures but remember there's three main ideas here. Talking about rethinking team structure, we want full ownership teams. Talking about rethinking idea flow. Stable teams, one minimum marketable feature at a time and we're talking about rethinking ownership. Teams that are expert in their market, leading to teams that design their own backlogs inspired by strategic ideas but not dictated or controlled by the strategic ideas. Their inspiration, not a straight jacket. And above all, reject the status quo. Steal these ideas, make them your own, let me know what works and project that acceptable mediocrity. Avoid the merely acceptable and seek greatness. Thank you.