 Good morning Wow, it's a full haul some of you over there. We will come that said also. Don't feel ignored Thank you all for coming on time. We had a little bit of delay in the kids But hopefully everyone's got the kids. All right without taking too much time. I would like to invite Craig Larmine It's an honor to have Craig Larmine. He did a keynote for us back in 2006 and we are extremely delighted to have him back I'm gonna hand it over to Craig. I'm gonna come back and spend some more time with you at a later point All right, please welcome Craig Namaste My name is Craig University Canada man, but a little bit of Hindi That's why I still speak English I Started living here in India in 1978 so let's start with a bad joke a man walks into a bar goes up to the bartender and orders a triple shot of whiskey and he's sitting there drinking and Plop something falls into his glass and he looks at it an Eyeball a glass eyeball and he looks up to the interior of the second floor of this bar and There's a late lady leaning out over the balcony and she says oh my goodness my glass eye has fallen out I'm so embarrassed. Can you bring it to me? Yeah, so he walks up the stairs Takes the eyeball out gives a tour and she sticks it back in and then she says Please let me buy you dinner for compensation. Okay so they have dinner together and They're hitting it off and they're really actually starting to enjoy each other's company comes time for dessert a Paratheef and then she looks at him with a winsome Winsome glance and she says, you know, you're quite a interesting guy. Why don't you spend the night with me and The guy says Wow, that would be really nice. I'd like that. That'd be fun But you know women don't usually treat me like this I'm a pretty plain looking guy and women aren't usually so friendly to me like this Do you treat all the men you meet like this? and She says oh, no Only those that catch my eye It gets worse I'm going to talk for about five minutes on a little bit of introductory stuff my scaling background and a little bit about large-scale scrums framework one and two and The majority of what I'm going to share will be about the competitive contract game and Component teams to aspects of scaling. I'd like you to understand more about Let's start with a little bit about scaling background Years ago. I wrote this book and it helped introduce agile to the world along with a lot of other people who helped introduce it and one of the Statements incorrect statements at the time when books like this were published years ago was that agile and scrum are for Small groups, but they can't work in the large and I knew that was not true and I wanted to focus in the area of large multi-site and offshore application of large-scale scrum and So I started on this journey of focusing on really large-scale product development with large-scale scrum For example in 2004. I was invited to Act as the lead coach of lean developments at Xerox where I worked for several years Although what I know about lean thinking is just a very small fraction Compared to the inside of people like Mary and Tom Poppendike but nevertheless They are involving the creation of these digital presses which might involve 500 to 1500 people software mechanical optical Engineering and these will involve tens of millions of lines of code Thousands of moving parts and we apply lean thinking principles and aspects of scrum to creating these I serve as chief scientist of accompanying all valtech and we have a offshore delivery division here in Bengaluru and starting in 2006 I started to live here in Kauramangala and With my colleagues at valtech India helped to evolve agile offshore development in the application of large-scale scrum along with other companies here such as ThoughtWorks and so forth this is a picture of valtech India and Starting in 2005. I started to be invited to work with large telecommunications infrastructure network equipment providers such as Siemens Networks NSN Ericsson and so forth and then also large-scale Investment banking groups so basically large hardware software systems and large financial systems And then started to help introduce the organizational design changes for large-scale scrum working in these groups I don't primarily work as a teacher I rarely give courses or that kind of thing most of my work is The real work where I'm working with real product groups over Usually several years where I move across the sites in order to try to make this really happen because I'm more interested in in the real experience rather than just being in a classroom and talking and Our customers started to become interested in these tips and so forth And they started to apply the large-scale scrum ideas that we were forming and that were then described in the books That we ended up writing and this is kind of the sort of range of experience that I've been focusing on So just to quantify it years ago, for example, I got an email from a person who said Craig We're doing a really really big a large-scale agile adoption and we want to know if you can help there's going to be 15 people Don't know if we can manage it But that's not what I mean by large. I mean sort of 800 to 1800 people Usually with five to ten sites. That's to quantify the kind of world that I'm thinking of and that I work in and Wanted to share our experiences and experiments with the creation of large-scale scrum and the organizational design implications and so then wrote about this in two books with my co-author bus Voda who Served on the leadership team of a large telecom networking product and a very experienced person and really the Organizational design implications of really creating large-scale scrum in a big group That's a Kenji. I think he's here somewhere as well. Yeah, hi and this was at Toyota in Japan and So we ended up writing these two books. What's really? Volume one and volume two Laying out the thinking tools and the organizational design tools for how to really do large-scale scrum And then the concrete practices for large-scale scrum and the second volume in terms of product management Change all of that stuff But before I take a dive into talking a little bit more about large-scale scrum in detail I'd like to start with a cautionary note in the late 1950s as far as bus Voda and I can tell was the first really large software-intensive product development From we think something like 58 to 61 it was called the sage system and it was done for the US military it ultimately involved hundreds and hundreds of programmers and It was significantly over the original estimates in terms of people in duration And after it was all over one of the senior managers was interviewed and asked about this big Product development that involved hundreds of programmers and this person was asked Sir if you could do it all over again What would you do different and this is what he said? Find the ten best programmers and write the entire thing themselves and I couldn't agree more our books on large-scale scrum the subtitle is large multi-site and offshore and I usually say don't don't don't because Almost always the motivations for large multi-site and offshore are based on horrendously flawed assumptions and local optimizations which make everything worse not better but You're still gonna do it and I work with all kinds of clients around the world that are Still gonna do it and I'm interested in helping so I'd like to spend a few minutes talking about large-scale scrum frameworks one and two Just so that you have some Introductory awareness to the concepts and that this exists as a completely fully formed system of thought an Organizational design these frameworks one and two although they are not the focus of this brief introduction this talk today frameworks one and two are described in detail in these books That lay out the thinking tools organizational tools the frameworks in detailed and large the large-scale scrum chapters And then all of the concrete operational elements to make it work are explained in this second volume Which isn't based upon speculation But based upon years of working in product groups with large customers who have actually made this change And then we've shared the experiences and tips Let's start with framework one Briefly in a picture. This is framework one and it works for a one product owner and up to somewhere between five and ten teams and then there's a tipping point where it no longer works and Whether the one product owner can work with three teams effectively or six teams effectively depends upon factors such as are they all co-located are the teams experts in the domain are The teams long lived and have been around for 20 years and know the customers well For example like a bunch of teams at Xerox or on the other hand like at my company Valtech India where we're taking on outsourced Development and the teams don't know the domain. You know this story very well and you get exposed to Insurance products for six months and then you're on to travel Systems for six months and and you're there's all kinds of barriers and so forth and in that case It's going to be a lot less teams with one product owner and in other contexts a few more But at some point between five and ten it tips and then no longer one product owner can work effectively with some number of teams There's a single sprint planning part one. There's a single sprint review. The sprint is for the product Not for the team. There's one product backlog for the product not for the team There's one product owner for the product not for the four teams Other than that, I'm not going to elaborate the details of how the ceremonies work in large-scale scrum framework one But you can read all about it Briefly framework to Framework two is when you've got more teams than four or six and one product owner and The essential element that we need to introduce at this point is some kind of decomposition mechanism in Additional software intensive product development that usual way that people decompose is Architecturally in which people then organized around software components note just at a almost Philosophical level that then we're organizing inward around our architecture rather than organizing Outwards towards our customer which you can get a flavor of right away is starting off on the wrong foot There's a lot more I'll say about this later on So instead of organizing around architectural components decomposing we decompose around what we call Requirement areas Imagine that you wrote all the customer requirements on hundreds of cards through them on the floor and then asked your Customers to come in and do affinity clustering and group them into families that make sense from the customer perspective we call these Requirement areas and this is the way that we decompose and large-scale scrum framework to from the customer value perspective not from an internal Perspective and then we add a new column to the scrum product backlog and we categorize each Customer-centric requirement into one and only one of these requirement areas Then we introduce the idea of a filtered view onto the product backlog for each area each requirement area And then you can have you can think of having different area backlogs. They're not really separate artifacts It's just the one Google spreadsheet, but with a filtered view you can think of a view on the backlog for each area Then we introduce a new role in large-scale scrum framework to called an area product owner and that area product owner focuses on that one customer requirement area such as Protocols and they will have a set of scrum feature teams that are dedicated to them So it's a decomposition mechanism, but focused around Customer areas of value rather than architectural components and then very briefly Framework to is a set of parallel framework ones for each requirement area, and we've seen the scale to hundreds of scrum teams and so I know from direct observation that it can work up to a thousand two thousand people and Large companies such as Ericsson for example are doing a company-wide transformation Based upon these frameworks So that's just a very brief introduction to this entire system of thought large-scale scrum to let you know it exists And there's resources that you can apply But I want to move on to the main thrust of this keynote When we are scaling fake scrum or scrum, but more politely is common and This is a it when the entire company is seven people fake scrum is rare but when you're scaling and the R&D group is 700 people and there's all kinds of existing really fossilized Organizational design elements in place Then when you suggest introducing scrum into that context, then it's extremely common I observed that what happens is fake scrum And it's very important to understand that you cannot adopt the implications of real scrum bottom up in that context It has to happen at the higher level Because it involves changes in the organizational design structure the existence of departments the Existence of manager roles all of this will be dissolved and there will be very deep change at a very deep level in the management Systems and you can't do this bottom up So for example shortly after this keynote here, I'll be heading off to London to work with an investment bank And as I always do I'll be starting off with C level management and managing directors for multiple days That's the level that you have to start with if you want to adopt large-scale scrum You can't do this bottom up where you'll just get fake scrum because it's really about changing the organizational system and one aspect that you'll get a fake scrum is in these large-scale Adoptions is related to the roles responsibilities and interactions that are not addressed properly In other words not real scrum is introduced Another way of framing what I'm introducing is that when scaling People often do not grasp the implications of just regular scrum with one team or the plain old agile values for example, I Want to talk for a while about the competitive contract game and its implications at scale and it all relates to Simply the third agile value Customer collaboration over contract negotiation. I'm sure you're all familiar with this value But how many of us have actually deeply reflected upon the implications of what this means in practice? especially in terms of large R&D organizational design So I'm going to spend some time opening up this box and unpacking it now Customer collaboration over contract negotiation So what happens in large-scale product development or let's talk about two different cases external products for the market and Internal products where you're creating an internal system within an investment bank for example so the first case you've got some kind of external customers and You're building some kind of a product. This is the boundary of the company and there's two cases It's really a mass market product like Like the iPhone or you're building a product for an external customer. Let's take that case for example you've got some customers externally and internally you'll usually have some kind of role such as Sales that gets involved in interacting with these customers and then Negotiate some kind of a commercial contract often around scope date and maybe even cost and Then this is then communicated to another group product management not project management and And Sometimes these are exactly the same people Sometimes they're not the same people and when they're not the same people There's often some kind of handoff here and there's often some kind of an internal contract that's Created or forced from the sales group on to the product management group It gets even better Because not only is there an internal Contract forced from that group on to that group then this group interacts with another group R&D or IT and Another internal contract is forced on to that group into this group. So there's this Transformation of the external contract into these internal contracts. That's one case The other case is that you're all only inside the company there it's an internal product or an internal system and then the customers are users such as traders and an investment bank and then for example, you might have an intermediate group such as the change group and they'll form some kind of an internal contract with the internal users and Then there'll be an interaction with what in for example banks is usually called IT But it's the same thing as R&D and then there'll be some kind of internal contract Created with these groups. That's the context that I'm talking about And this is related to the context of this third Agile value now. I want to spend some time Exploring this in more detail What's going on here? We call the traditional contract game or the competitive contract game and in this game There's time and there's essentially three major milestones start and When you finally can release and a third milestone in between Whose time is come whose date is completely arbitrary? it could be here it could be here and There's two key players in this game Actually, there's sometimes more players like we see here in this diagram, but I'll simplify it as two players which I'll just call business which might be product management or the change group and R&D so we got business there and R&D here or IT and The context of the traditional contract game is that at this milestone point will be defined through Negotiation contract negotiation internal contract negotiation some kind of an internal contract between this group and this group and This internal contract will define scope what should be in the release and often a date and Often cost as well and the idea is is that after this milestone This group will go away and wait for the end while the R&D group Implements the contract so the idea is that there's Negotiation between business and R&D during this period finally the negotiations of the internal contract are finished Then this group waits until it's all done at the end They've got their poker chips and they're waiting to cash them in at the end Now the some other context to this game is that because business goes Goes away after the point from the business perspective after this point. There's a reduction of flexibility Because if business during this period wanted to add things remove things change the order Redefine things this group will resist. It's possible to make a change. I'm not saying it's impossible But there's friction. It's considered the exception rather than the rule and largely that's because hey We agreed to this and we're going to be accountable for doing that And so we need to minimize the change after this point. Otherwise, we're going to be in trouble So there's a reduction of flexibility and kind of related to that is a reduction of control from the business perspective now the reduction of control is related to this reduction of flexibility another aspect of the reduction of control from a business perspective is That they don't want control The thought is well, why would I as a as a business person care to be involved in this phase? It's all a bunch of half-done work. I don't see it finished until after eight or 18 months It's a bunch of project management R&D nerdy tasks. Why would I even care about being involved in this phase? so there's a reduction of control for several reasons and there's also a reduction of Transparency from the point of view of business and the reasons for that are one Because there's a been a work breakdown structure of the customer centric language into technical tasks and For example different groups involved in it such as Analysis tasks and architecture tasks and testing tasks. So a customer requirement such as support trading credit default swaps gets Transformed into a very different language of tasks across a lot of different groups thus making it difficult to see what the progress is from a customer perspective Also, it's difficult to see the progress because there's high levels of work in progress and There's a third reason which I'll come to in a minute So that's the context of this game Now another aspect of the game is that attached to this contract will be a manager from this group and depending upon the scope of this it'll be a super project manager called a program manager or a more humble project manager and This person will be attached to this group and in Canada where I come from we call this person a sacrificial lamb Now this is a game and games have moves So what's the first move in this game? Well, the first move is played by business and it's during this period here during the contract negotiation phase now business knows historically that they don't always get what they want and Secondly, they basically get one big chance to spit it out during this phase and after this point it's going to be difficult to add things and change things and Because traditionally there's low transparency and they don't have control and they don't always get what they want And they've got a lot of money on the line. There's fear and distrust and a feeling of risk And so for all of those reasons the first move of the game is More more more more more more more more more more more more more more Now let's come to the second move of the game this person the program manager and The other R&D managers in this traditional model and game will be held accountable for meeting this by this date and in fact, there's even sometimes implicit or explicit ceremonies that we call The commitment ceremony where essentially at this point this person holds their hand over their heart and they say I commit or I promise now as you know because many of you have a background with an Sanskrit-based language you probably know that the word commit comes from the proto Sanskrit And it's a word that was kept secret in the valley of Shangri-La for thousands of years Because it's a magical word and by saying it you make the inherent variability of R&D go away And suddenly we're making chapattis on an assembly line This is called the belief in magic one of the four obstacles to the adoption of scrum and In traditional development, I've been in I've been observing groups like this for 35 years And for 35 years, I've seen this game played and I've seen the commitment not met It's got nothing to do with scrum. So therefore we have Hundreds of thousands if not millions of existence proofs that saying I commit doesn't solve the problem But an interesting question is that it does it create any problem and What problem does this apparently solve? We'll come back to this So there's a commitment game and then this group is said you're Accountable for meeting the contract by this date and If you don't do that it will be viewed negatively and if you do do that it will be viewed positively Consequently since the first move is more more more the second move is what less less less So we go more more more more more less less less less More more more more less less less less less That's the context of the game. So notice it's a two-party Competitive game because they've got different objectives and whenever you have a competitive game, there's a loser user. So the system is fundamentally sub-optimized really for solving the customer's real problem. And this group will pad and therefore introduce economic inefficiency because the whole game is not about us, is not about optimizing for success. You know what we're optimizing for? Reducing or the ability to shift blame when something goes wrong. You're optimizing for the ability to shift blame when something goes wrong. And I remember some years ago when I was working in Hangzhou, China with a telecom group and we were introducing large scale scrum. One of the product managers said to me once he finally came to understand what was really going on in scrum, he said, but Craig, who are we going to blame? That's literally what he asked me. That was his primary interest in the development game was who we could blame when something went wrong. He was very concerned about that. It gets better. This person has lots of money on the line and there's a reduction of flexibility, control and transparency from their perspective. And so they have a kind of fear. And so they want to assuage their fear by introducing something that will give them the feeling that things are under control. So these people apparently satisfy this person's fear by saying, don't worry, we've got it under control because we have a Microsoft project Gantt chart. And therefore it's under control. And by the way, if you've read the 1911 book, The Collected Works of Henry Gantt and I've looked at it, my co-author Bust Voda has a copy, Gantt charts were created for Ford Motor to control the movement of workers on the assembly line. And it was like 0.3 seconds, move the foot there, 0.4 seconds, move the foot there. It had nothing to do with R&D. I digress. So we have an illusion of control, an illusion that we've reduced or eliminated the systemic variability that is inherent to R&D. In addition, this person not only wants a plan, they want a status meeting. They want to show, they want proof that we're actually on plan to assuage their fear that things are under control. And so now it's time right now for the first status meeting. And I'd like to invite my three volunteers to join me on this stage. Alright. And Ragu is the customer in this game and he wants to have the first status meeting. And Nadim, it's Nadim, right? He's the program manager and he's going to have the meeting. And Guru, yeah, Guru, I know the first name, forget the second name. Guru Krishna. Guru Krishna is a first level project manager. And so Nadim is preparing for this first status meeting. And so he says to Guru, I got to prepare for the status meeting. I need to collect the data, collect all the data, roll it up and give me a summary. And I'm a humble programmer on the team. And so Guru comes to me and says, Craig, what's going on? Hey Craig, give me the good news, okay? How's it going? You know, it's a complete fucking disaster. I have no idea what's going on and I have no idea how the hell this is ever going to get done. People really don't seem to know what they're doing here. So now Nadim, he's the manager of Guru. And once a year there's a performance review. And because Guru is a first level project manager, his performance review is good if his projects are under control or on track. And he might get a salary recommendation increase if that's true. And of course, if his projects aren't under control, that won't look so good at his salary review time. Nadim asks Guru how the project's going. Now, Nadim, as a senior program manager, aspires actually to moving into the business group in the future. And Ragu will be involved in his performance appraisals and might even recommend a salary and maybe promotion to CTO in the next year or so. And it's time for the big status meeting. So Ragu, ask Nadim how the project's going. How's it going? Hope you're on time. We are on time. I think we will be, I must say, in all cases. Though we have a few glitches, but it's under control. Thank you very much. If you're familiar in astrophysics with the phenomenon called red shifting, we call this green shifting. And this is the third reason why there's a reduction of transparency. These carrots and sticks in which people are encouraged to obfuscate and not explain the reality of what's going on. Okay. So, status meeting, status meeting, status meeting, status meeting. And the project manager Guru actually has in mind, you know, the last thing I need in order to solve the problem is more pressure from above. If people would just leave me alone, maybe we can work it out. That's kind of what's in his mind, a certain kind of wishful thinking. And indeed sometimes it does work out and then things go well. But let's take a scenario where we're here and there's only 20% left in the project and things didn't go well. So it's time for that final difficult meeting. And then at that point, essentially Nadim says to Ragu, and this is why Nadim gets paid the big bucks. Ragu, everything was under control. We had excellent risk management. Before a snowstorm, somebody died. A high attrition, couldn't possibly have foreseen this. Sorry. It's going to be a little bit late. And so on and so forth. Now at that point, what happens is that Ragu does the following. It's time for the musical interlude. And what happens is that Ragu says, you committed customer promise penalties. And he pressures into Nadim and Nadim says to Guru, you promised pressure customer commitment. And then Guru says to me, Craig, customer commitment, you promised. But what's interesting is that the pressure doesn't stop with me, the programmer, because I can shift the pressure too. And so then what I do, and by the way, if you're from business, you have to close your ears now because I'm going to share a secret that normally we don't share outside of the world of R&D. I open up the secret R&D toolbox. And I open up the secret R&D toolbox. And so do all of my CogLeaks and the people to do testing and the first level program managers. And then we deliver a miracle. And what's in the secret R&D toolbox? Reduction of code quality, overtime, burning out your best people who then leave and go somewhere else. Reduction of good architectural quality, saying something was done when it's not really done and then handling it as defects to fix later on. Not hard coding, no longer learning, no longer improving. And I could go on and on and on. You know the game. And what's interesting here is that it's the secret R&D toolbox because this person never actually learns that. And in fact, you might even have deniable plausibility and the big program manager might ever even know that. All the hands on workers and first level managers know that. But beyond that, it's a bit of a secret. And so then we introduce organizational debt in which the system gets a little bit weaker and technical debt in which we start to introduce a bit of crap into the system. And then we deliver the system and everybody says, great job, you get your bonus. Repeat. More, more, more, less, less, more, more, more, less, less, less. I commit. Now the organizational and technical systems now have debt. So there's friction so everything's going a little bit slower. So it's the same dynamics as the first time, but all a little bit worse. So cycle number two, secret toolbox, cycle three, cycle four. And we now have a positive feedback loop in which we're on a downward spiral until after seven or nine cycles of this, somebody says, damn, for some reason, it's impossible to get anything done in this group anymore. What happened? Let's outsource this to South Yemen and start the next generation product or some variation of that. Have you ever seen this? This is a kind of familiar story. This is really at the heart of what is meant by the contract negotiation game. And I'd like to flip back to the computer slides now. The idea in Agile and in Scrum and other Agile methods is to move to customer collaboration over contract negotiation and what Alistair Coburn has rightly called the cooperative game instead of the competitive game. And if you're familiar with Scrum in this picture, who is it that has to become the product owner? It's this person, the person from business who before was saying more, more, more. It's a central idea in Scrum that the idea of the product owner is that the owner of the product, which is why it was called the product owner, the owner of the product, the business person responsible for ROI is the one who plays the role of the product owner and they directly interact with the teams. You're doing potentially shipable product increment every sprint, which completely changes the nature of the dynamics of the game because you no longer need a big contract and you no longer need to shift responsibility to an R&D group in order to do the big project because the whole paradigm of a big project with a bunch of stuff only half done for months doesn't exist in Scrum because you have essentially every project is two weeks and then you have PSPI and you can do that forever. So the fundamental dynamics of the game of change and it's this person from business who directly interacts with the team. After all, they're the person who has the business problem so we give them the steering wheel and then they can steer directly to help them solve their real external customer commitments and that is why there must not be project or program managers responsible for release. That's why the end of the contract game also implies that R&D or IT project managers are no longer responsible for a release. It's not that project and program managers and R&D aren't nice people or good people, almost all of the ones that I met are excellent people. The reason why in Scrum that an R&D project manager must not be responsible for the release is that it's part of this entire system, the traditional contract game which has inherently dysfunctional elements and we're trying to deconstruct the roots of that system. And if your entire company is seven people, this is obvious and the change is obvious. But when you're a large scale group, a product group with a thousand people and you've got fossilized systems and the contract game has been around for 20 years and there's a lot of ceremony around it, what often is incorrectly done is there's the incorrect belief that what it means to adopt Scrum is just change what you're doing here rather than changing the entire system and the relationship between R&D and business. This is one of the big ideas in Scrum and Agile and is the implication of customer collaboration over contract negotiation that it's not about changing what you do here, it's about a change of the interactions and a relationship at a much deeper level. Let's move on to another element of scaling. So when scaling, fake Scrum is common and the root cause organizational problems related to groups and structure are often not addressed. On contrast, back in the 1970s and my first job as a programmer, an APL programmer by the way for some of you who know what that implies, I was in a group where the entire number of programmers was six people. And it was inconceivable the idea of private code or his code versus my code. The idea never even arose. Obviously it was just all of our code and we all worked on it together to create customer solutions. And we all understood the code. Internal open source. But when you're scaling, what often happens is that people get the idea, usually traditional managers who have never worked in an open source world or are unfamiliar with the implications of continuous integration and they come a very traditional background and they think that of course we have to have component teams instead of internal open source. So when you're scaling, a traditional mindset is that we've got these big architectural units of code and we couldn't possibly have internal open source and we couldn't possibly have teams that work across it with collective code ownership because the senior managers that set up the organizational structures never experienced open source, can't hardly believe it would work or how it would work and have never seen real continuous integration. And I don't understand the implications of how that fundamentally can change the nature of the game and somehow believe that it's not possible for a programmer to learn new kinds of things. And so then what happens in large scale traditional organizations is the creation of component teams. Instead of the basic scrum idea, quote from the scrum guide, cross functional teams have all competencies needed to accomplish the end to end customer features without depending on other part, on others not part of the team. That's basic one team scrum. But when you move to large scale, this is sometimes forgotten and what is set up instead are component teams where there's separate chunks of code and you assign programmers to different chunks of code, the server team, the GUI team, the platform team. And then what's often incorrectly believed in fake large scale scrum is that adopting scrum is something this group does without changing the organizational structure. But let's explore what happens if you do that. Let's explore what happens if you keep component teams rather than dissolve this organizational structure. And what I'd like to do now is move back to the flip charts, please, with the camera feed. To visualize it, there's a bunch of software modules or components. And I'm only going to draw nine boxes to keep the picture simple. But in fact, it's in my world, like in large telecom systems, it's not nine components, it's 90 or 450. And in component team organizational structure, you've got programmers that belong to different components. So these are programmers. And you have private code rather than collective code ownership and you do not have internal open source. And I want to examine more closely, I want to unpack the box of what happens if you have this kind of a structure. And let's consider a requirement such as F1. Now the assumption underlying my analysis is that a customer centric requirement cuts across multiple components. And if that's not true, my analysis does not really apply and it's not valid. But almost always customer centric requirements cut across multiple components. Now I work with some groups that have been in component teams and they say, oh no, Craig, all our requirements are just in one component. But in fact, they're fake requirements where someone upstream has already chopped them at the component level and then handed them to the component team. So the component team never really saw the end to end customer requirement to begin with and is not seeing the whole as Mary Poppindike would say. So I'm assuming that it's like that or F2 is like this and so forth. So that's the situation. Now let's examine the question of how can we do, how can we realize F1? So here's F1. And the first thing that we need to ask is who is going to do the requirements analysis? Will it be this team or this team or this team? In fact, you might not even know which component teams are involved in F1 yet. And even if you did, it's a little bit arbitrary which would do the analysis. So therefore, what's the solution? Let's create a group before these programmers who will solve that problem. And let's call them requirements analysts or business analysts. And they'll analyze F1 and create some kind of a requirements document. The second question that we have to answer is what component teams are responsible or will be involved in F1? Now who's going to answer that question? It's a chicken and egg problem. We don't even know which of the teams to ask. And so let's pull somebody before the component teams to answer that question. And this person or group is usually called systems engineering or sometimes architecture. And they'll take this and produces output some kind of another document that answers that question. They'll often have some kind of a spreadsheet where they've got requirements R1, R2, and then component 1, component 2, and they'll make little checkboxes or something like that. And they might even define the interfaces between these components. Well, now we've done the analysis. We've got the architectural components identified. And it's finally time to actually do the programming parts of the work. And so this is then split up across the different component teams. So I'll say these circles here represent the programmers and the component teams. Notice, by the way, that the component teams are teams of programmers. They're not cross-functional teams. And they do their bits of the work. But I don't want to give you the impression that they all do their bits of the work on the same day. Because, in fact, there's not just F1 flowing through the system. There's F2 and many more all at the same time. And the work for all of these different requirements has got split up and chopped up across these different groups. And so they've all got cues in front of them or they're multitasking across multiple requirements. And so things start to get done out of order. When I was working years ago in Hangzhou, China, with a product group, and you might not believe this, but this is a fact, this group did their part of F1 11 months before this group did their part of F1. Now, that's kind of an extreme case. But especially when you're at large scale, that's how out of step the work can become. Well, we need to do the end-to-end testing of F1. Who's going to do that? This group, this group, or that group? Not at all clear, somewhat arbitrary. It doesn't seem to make sense. So let's introduce a group after these groups and let's call them the testing or the QA group. And, oh, I forgot to mention, there's code that's being added altogether. And in this traditional world, who's responsible for integrating all of this code? Is it this group, this group, or this group? Well, it's not their responsibility. So let's add an integration manager role to make sure it all comes together at some point. And then finally, there'll be the end-to-end testing. But we're not done. Because the work has been chopped up across so many different groups, it's possible that someone could drop the ball on this. So what do we have to do to solve that problem? We need to introduce another role. And what do we call this person? Project manager, or in some of my customers, feature manager. And the only reason for the existence of this overhead role is as a side effect of how all of this work has been chopped up across these different groups. And of course, all of these groups have cues associated with them as well. Now, I'll just ask a rhetorical question. What does this look like? This is a sequential life cycle, a kind of a waterfall. And the key point I want to make is that if you have component teams, it will inevitably generate an organizational design which is sequential, with lots of handoff and local optimization. And almost nobody seeing the whole incredible slowdown. If you look at the overall cycle time of F1 going from one end to the other, it's incredible how inefficient and slow it is with handoff waste and information scatter and many other problems. Quite the opposite, of course, than the scrum and agile model where you eliminate all of these groups and have cross-functional, cross-component teams in an internal open source world that work across the entire stack of the code. And so it's very important to understand that scrum is not for this team. It would just be fake scrum. You haven't addressed the fundamental issue of having a waterfall at the large scale. We need instead to dissolve this organizational structure, move to internal open source cross-component, cross-functional teams and address the learning debt and all of the issues that arise when you make that kind of transition. But it gets even better than that. I'm not finished with this story. For example, all of these groups will need overhead managers. We need component one manager and a component two manager and a component three manager and so forth. So we got more overhead. It gets better. Let's consider this was release number one. And let's assume that the number of programmers assigned to these different components was more or less appropriately balanced for the amount of programming effort for release number one. Okay. But now we come to release number two. And the number of people in these different component groups is no longer balanced with the highest value customer requirements. Let's say for argument's sake that in the second release, these components are the focus of the highest value customer requirements, but not these groups. So then what you would like to do is actually be able to move these people over here to help out. But no, we can't do that because number one, there's no possible way that these people could possibly learn about this code. That would be impossible. And number two, this person says, Hey, I'm a manager. And I want to become a bigger manager. And if I lose people, that's not going to be good for me. I want more people, not less. Back in 1996, I was working at Bell Atlantic, a telecom company in the US. And in order to become a higher level manager, you had to have first led a project with 100 people before you become a higher level manager. Can you predict how many 100 person projects there were in Bell Atlantic? And so there's tremendous resistance to reducing the number of people here. So what happens is that we just add more people here for the second release. Third release. And in the third release, the highest value customer requirements are there. And that's where most of the programmers should be, but can't move these people over there, because there's no way they could possibly learn about that code. And these managers don't want to lose their people. So OK, let's add some more people over here. So repeat, repeat, repeat. And you get a system which really could have taken 25 programmers, now taking 250 programmers. It's a very subtle dynamic that you don't see unless you're working in a product group for multiple years at large scale. It gets even better. One of the ideas of the managers who set up the system is that this is good, which is a local optimization, because these five programmers will really create good code in that component, because that's all that they look at. Well, I'm a programmer. And I don't just sit in classrooms or meetings rooms with managers. I actually go, practice go-see Genchi Genbutsu in lean thinking. And I spend time sitting with these programmers and working on their code with them. And I've done this for years. And I've seen what the code looks like in these component teams. And you know what? It's crap. It's not good. How could that be? Because for several subtle dynamics, which unless you actually spend years looking closely at what's really going on, people don't grasp. The first is this. How do you become a great programmer? So imagine you get a fresher out of university who joins this group and then spends four years just in this group with four other programmers staring at the same 20,000 lines of code. How much are you going to learn about different programmers' perspectives or great examples of code? It's a completely walled garden. And you're getting very little exposure to new stuff. So there's actually very little learning that goes on in contrast to an open source model where people are being continually exposed to new code and maybe even better code. Secondly, another reason why the code is crap, ironically and completely counter-intuitively, because there's this forcing function that we have to work across it. It has to be understandable. It has to be clean. It has to be well-refactored. So in fact, in really good open source products and projects, you get a better code quality, at least if they're going to be sustainable. It gets even better. Let's consider a backlog of requirements that were organized by customer value, one, two, three, four. Well, this group here can only do component one programming. Suppose that it's only number 20 in the list that includes code in component number one. Well, we can't let those people sit around for six weeks doing nothing. Everybody has to be busy locally optimizing on coding their component. So instead of doing business value number 20 requirement, we push it up the list because now we're optimizing on people being busy doing the one thing that they know how to do rather than optimizing in terms of customer value. So you're sub-optimizing around your architecture and around your bottlenecks of knowledge and you're sub-optimizing around people being busy and outputting code rather than doing the right thing. Isn't that wonderful? Component teams. And I go into these large groups who think, well, we're adopting Scrum. That means that these programmers have a daily standup meeting every day. So those are just a few examples of the kinds of dynamics that I've come to see over the years in helping to introduce real large-scale Scrum. And as I hope you can see, at scale, this is not a subject that you introduce to a group of programmers at the hands-on level. This has implications for changing the entire organizational design in terms of structures, policies, roles, responsibilities, and changing the interactions. And if you want to help introduce Scrum or Agile at the large scale, you need to be aware of and working at that level, not helping a team of programmers have a daily standup meeting at a wall. Let's close with a bad joke. I heard this one when I was in Brazil. I think I heard it when I was in Brazil. A man walks into a bar with his friend and goes up to the bartender and orders a triple shot of whiskey. And not just any man, an engineer, and not just any engineer, the Brad Pitt of engineers. He is so good-looking, so handsome that women just melt when they look at him. He is just gorgeous. And his friend, the other engineer, says to him, how come you're ordering so much to drink? And the Brad Pitt of engineer says, well, I'm celebrating. You see, I was walking to work this morning and a beautiful Brazilian girl drove in front of me on her bicycle, my wife, Albertina's Brazilian. And she got off her bicycle and she looked at me and she said, baby, you are so gorgeous, you can have anything you want. And she took all of her clothes off. Wow, said the other engineer. So what did you do? I took her bike. Oh, that was smart, said the other engineer. I don't think her clothes would have fit you. Thank you for your time.