 I'm the chief methodologist for IT at IBM Rational and what I'd like to talk about right now is some work that I've been doing over the last few years called the Agile Scaling Model and the goal is to describe a framework around which people can understand what Agile, how they're applying Agile, the context in which they find themselves in. It's interesting, the previous speaker was joking that everybody jokes about this, that the consultant answer is, it depends. Well, I would really like if people were to follow up on that and say, well, on what? Because that's an interesting question. And this is the answer to, well, on what? At least some of it will be at least. So keep that in mind. So, that's not working. So, I want to talk about three basic things. I'm going to start out, first of all, by talking about what the Agile Scaling Model is. Because it's a fairly light thing, which I hope hopefully we'll be able to convince you of it's fairly light and fairly straightforward. And then what I'm going to do is I'm going to explore two basic issues. You know, how is this scaling model, how would it affect the common practices that you're probably used to and we'll look at daily standups and stuff like that and we'll see how you would scale them. And you've probably heard some of this already from other speakers. As well as what are some of the other practices that you might want to adopt? Now, I'm not going to go through every single freaking scaling practice there is. This would be a several-day talk if that was the case. And I'm certainly not going to go through every Agile practice and show you how to scale them all because that would also be several days because there's 80 or 90 common Agile practices. And even if it takes me a couple minutes to walk through each one, which would be very short, that's still half a day of material. And I've got 60 minutes. And then finally, I'm going to talk a little bit about organizing large teams. Now, part of my message here today is that there's far more to scaling than worrying about large teams and actually large teams is a relatively trivial thing. But I just want to talk a little bit about large teams to give some advice around that and then get you thinking a bit outside the box. And I almost wish I'd given this presentation earlier today because some of the questions that I was hearing in other people's presentations, I think they could have benefited from a couple of diagrams I'm going to show here about how large teams are actually implemented in Agile. So what's the Agile scaling model all about? It's a three-level or three-category model. At the first level, the first category is Agile development in general. And this is typified by Scrum, by Extreme Programming. The focus is almost always on construction. We see this a lot. That's a great place to start. The goal of Agile development is generally to develop high-quality software, build it in an evolutionary, inter incremental manner, be very collaborative, be self-organizing. This is something that hopefully you've been hearing about over the last three days. So this isn't new. It has a value-driven lifecycle. So in Scrum, the rhetoric is we produce potentially shipable software, every sprinter, every iteration, depending on your terminology. So we're producing visible value at all points in time. That's a good idea. I'm without a doubt, and Agile Manifesto talks about how the only way to measure progress on development projects is the delivery of working software. So it's all good stuff. And for the most part, a lot of the advice is around small and reasonably co-located teams doing fairly straightforward stuff. And without a doubt, it's actually the majority of teams. So near-located, at least, not co-located. But the majority of software development teams are 10 people or less. They are roughly near-located. So we're sort of in the same building or same campus. And for the most part, most people are developing reasonably straightforward things. There's really only a few teams out there in the world that are developing air traffic control systems, or heart monitoring systems, or the Watson system to play video games, and stuff like that. So the vast majority of projects are reasonably straightforward. So that's OK. So this is a decent niche for Agile to focus on, the majority of teams. But there's more to it than that. This is the problem. Some of the questions I've been hearing in other people's talks over the last couple of days were around these issues that aren't being described all that well. So it's not about construction, just about construction. It's about delivery. So I've got to be able to say, how do I initiate a project effectively? How do I do the construction stuff effectively? How do I release the production effectively? If you've got a DevOps type of an attitude, and there's a DevOps track here, it's the next question, how do I operate and support the solution effectively? How do I do portfolio management effectively? How do I do enterprise architecture effectively? Look at the bigger picture type stuff. So there's a bunch of questions that's not being well-addressed by just this construction focus that we like to talk about in the Agile community. Value-driven life cycles are nice, and they're definitely a good idea, and they definitely pay down some risks. But delivering working software on a regular basis does not pay down all risks. So we know at the beginning of a project, it'd be really nice if we'd have some sort of agreement around what we're supposed to be doing. It'd be really nice if we had a clue what the architecture was. So we could go in a reasonable good direction to begin with. We should be worrying about these basic fundamental risks, and we should try to address them very early in the life cycle if we possibly can. So this is about governance, this is about portfolio management. Whatever you want to call that, we need to work a little bit smarter. So it's not just about showing working software on a regular basis. It was interesting, the gentleman that we were talking about regulatory compliance a while ago, they used slightly different terminology, but they both showed life cycles that had an explicit project initiator. Actually, one gentleman was talking using the term inception, the other one I can't remember what he was talking about, but he's basically showing you do a little bit of upfront work, then you do a bunch of construction, then you do a bunch of release work. And they both had this very clear cadence in their life cycles. You use slightly different terminology, but that's basically what they're talking about. This is having a full delivery life cycle. Self-organization is nice, and it's actually quite effective, but you need some adult supervision. So he should be doing this within the scope of an appropriate governance framework. And all teams, by the way, are being... I realize governance is a swear word, and I apologize for using that swear word, but like it or not, all agile teams are governed in some way, like it or not. Okay, this is the real world now, not the Scrum Fantasy certification stuff. This is real world, and you know this to be true because somebody is funding your project. So somebody at least is keeping an eye on you and how the money is being spent. That's governance, that's financial governance. And if you're really smart and you want to be really effective, you'll also know that you need technical governance. You should be working to common coding conventions. This is actually built into XP, by the way. You should be working to a common infrastructure. You should be reusing as much as you can. If you aren't a regulatory compliant situation, you should be following the regulations. So there's some basic fundamental governance things that you better be doing. Otherwise, you're going to get a spanking at some point from senior management for not doing your jobs properly. So yeah, you need this adult supervision, one of my colleagues likes to say. And this is still geared for reasonably small teams developing fairly straightforward stuff with the exception of that one word solution, not just software. And I was ranting about this this morning. This focus on software is not helping us in this community. It makes us sound like idiots, actually. It's very clear all these people are running a working software, working software, working software. You've just labeled yourself a junior employee, by the way, when you start talking like this. Because it's not just software that we're producing. We also deliver supporting documentation. And documentation is, in fact, part of Agilay. I would invite you to Google the term Agiladocumentation and see what comes up. And because there's deliverable documentation, there's going to be some operations documentation you're going to need. There's probably going to be some user guides, some training manuals that you need. There might be some system overview documentation that you leave behind for maybe yourself or for somebody else to overview the system. So that way you can maintain support over time. Let alone if you're in a regulatory environment and you want to avoid a few fines by producing some of the extra documents that the regulations ask for. So we need to worry about that sort of stuff. The software runs on hardware, and almost always in any system I've ever produced, there's been hardware upgrades. You do a major release, and you're probably going to throw a little more hardware in a production or somebody else will. Maybe the operations people will. If you're running in a cloud, then somebody's slapping some boards in there at some point to keep things running. But something's happening and the network's changing. All good stuff. The business process is changing. You might even be changing the organizational structure on the usage of your system. So you've really got to be looking at the solution, not just the software. The software's part of the solution, but it's only part. So we really got to be looking at the full picture. In many ways we've lost this in the Agile community from all the rhetoric and all the questionable training that we get sometimes. We've really lost this. And before Agile, we had sort of matured to the point that we recognized that there was more to it than just software. And then we sort of backtracked a bit with the... But anyways, so let's up our game and look at the big picture. And it's not just potentially shippable software. It's really consumable software. It's nice that the software runs, but it'd be even nicer if the end-users actually wanted to use it. That would be really nice. Because I'm sure many of you have seen systems that were wonderful. They were great systems. They met their requirements. People signed off on it. And then you ship it into production. You ship it in the marketplace. Nobody wants to use it. Nobody buys it. That might not have been all that successful. I will contend. So then the third level, Agility at Scale, is what happens when the situation is not so simple. And I'll walk you through this in a few minutes. So what happens when there's one or more scaling factors and you're not in this simple situation anymore? And so how do you tailor your process and tailor your tooling to meet the needs? So let's walk through these three categories real quickly. So this is the Scrum Life Cycle. I'm sure many of you are familiar with it. So I'm not going to belabor the point. So very clearly focused on the construction part of the lifetime. Which is important? Very important. Good stuff. Great ideas. You should probably consider adopting them. But as we know, there's more to it. Yes, there's construction without a doubt. So that's all good stuff. But we need to kick the project off somehow. We're going to do a little bit of initial planning up front. A little bit of initial requirements. That product backlog, which really isn't all that accurate, by the way. But anyways, this stack of work items has got to come from somewhere. Requirements just don't magically appear. And they don't get beamed down from the Starship Enterprise, if you followed the panel yesterday. But you've got to do a little bit of modeling up front. You've got to populate the backlog. I'm sorry, you've got to populate the backlog. I swore again. I said modeling. You've got to populate the backlog. Or repopulate the backlog. You've got to remodel throughout the construction as well. And you probably have to go hat in hand, get some funding for the project. Because money just doesn't beam down from Starship Enterprise either. Somebody needs to sign off and fund your project. So there's a little bit of upfront work. Some people call this sprint zero or iteration zero. That term is, of course, incorrect. First of all, if people are renumbering backwards in time, they didn't think a few things through. That's an indication right there. But it's not a sprint. And we know this because, well, at least I know this, because I do industry surveys. And the average construction sprint or iteration is roughly two weeks in length. Okay, that's pretty good. But the average effort to start a project is four weeks. So that's either one hell of a long sprint or it's several sprints, or maybe it's not really even a sprint because it's a different animal completely. So we need to start thinking. But the same thing with transition, by the way, this is, I think, four and a half weeks on average. And obviously, some people are doing transition on the order of minutes or hours if they're fully automated. Some people are transitioning in the order of months if they're fully dysfunctional. So I've seen some organizations that take three to four months to do transition of a system and they wonder why it's so expensive to develop anything. But what can you do? So we need to be a little bit smarter about this. And there's a few other things. This is the basic or the simple life cycle of dispensational delivery, which is based on Scrum. And there's a few other features that are interesting. It's enterprise aware. So you should be working with the enterprise architects. I'll be talking about enterprise people in general. I'll talk about that later. And it's scalable, which is where we get in the next slide. So like I said, this is for, both of these things are for fairly straightforward situations. And what happens when the situation is not so straightforward? This is where things get interesting. So what does it mean to scale? So what I'm going to do, I'm going to walk you through eight scaling factors one at a time. All the scaling factors are described in this sort of a format where on the left, from the point of view of the team, this is important for one of the scaling factors. From the point of view of the team, the simpler situation to be in, or the desirable situation to be in as the case may be, is on the left-hand side, on the right-hand side is the more difficult situation to be in, and it's actually an analog range. So you're co-located when all the people on the team are in the same room, including your key stakeholders and you work together to get the job done. This is the desirable situation to be in from a geographic distribution point of view. Your success rates are the highest, your costs are the lowest, your risks are the lowest. This is a good thing. You're distributed. If you have people working in cubes, even though you're in the same building, you're now geographically distributed. You have erected barriers to communication. These are called cube walls. And there's a wonderful series of cartoons, Dilbert, that make fun of the challenges of working in cubes. They're right. Your success rate measurably goes down by several percentage points when you work this way. Now, if you're a small organization, a couple of percentage points, who cares? If you're a large organization, if you're a Fortune 1000 company, this can translate into millions of dollars a year. Sometimes, your success rate going down by several percentage points because of the interior decorating decision to have cubicles. Let alone offices, let alone having people working on different floors, let alone having people working in different buildings in the same campuses. There's wonderful studies that say that if you have people working in two different buildings, even though the buildings are side by side, so I work in building D and you work in building C. The chances of me talking with that gentleman, because he's in the other building, he's one of those, he's one of those C people. He works in building C. I'm not going to talk to him unless I happen to be on a softball team or some other thing outside of work. That's the only, more than like the only way I'm ever going to talk with this guy. He might as well be on the other side of the planet by that time. There's been studies that show this. So, anyways, there's bad news. I've done work that says it's not quite as bad as him being on the other side of the planet, but it's darn close. And then let alone if you're globally distributed and you've got teams in different locations, and then your success rate plummets. And this is true of all paradigms, not just agile. So avoid distribution if you can, and sometimes you can't. So life's tough. Then you have large teams where you have different team sizes. See if teams of two people, teams of 20, teams of 200, teams of programs of 2000, it's not just a team by that point. And by the way, agile works at all points in scale. Like I said, I do surveys. I've got data that shows that I've got people reporting that they're succeeding at agile at all levels of scale on all of the scaling factors I'm going to talk about. So don't let anybody tell you that agile does not scale. Please don't. They might not, if they tell you that, what they're really saying is they don't know how to scale agile. Okay, that's a different thing, right? They're not communicating correctly, but they're telling you they don't know how to scale agile, which is okay, they just don't know. But other people have figured this out. So other people are succeeding at this. Doesn't mean that you will, but it is possible. Other people are. So we need to observe that and act accordingly. Sometimes you have regulatory compliance. That was a talk earlier on today. It's easy when you have no regulatory compliance. And there's different types of regulations, by the way. So there's Sarbanes-Oxley, which is reasonably trivial, all the way up to the FDA type regulations, where you're building medical equipment, or you're working in a pharmaceutical, you're supporting the development of drugs, not doing, oh, you might be doing drugs, but hey, why not? I'm from Canada, we're fairly liberal. So we were this close to legalizing marijuana, and then we voted the conservative party into place, which is our version of the Republicans, if you know the American politics. But anyways, that's okay, they won't last forever, so we'll eventually be able to smoke up. So anyway, so compliancy, it changes the way you work. You're gonna have a little more documentation, you're gonna be a little more careful. A lot of the compliancy is around, when it boils down to it, it's around risk management and good stuff like that. One of the really good suggestions from the previous talk is to read the regulations. If you're in a regulatory environment, it behooves you to read the regulations, because if you let, usually what happens, and this is a phenomenally stupid and ignorant thing to do, and as we saw, they ran this, stand up if you've read, sit down if you haven't read the regulations or things. Most people hadn't read the regulations in the last few years, even though they were working in regulatory environments. And what happens is, if you let the bureaucrats interpret the regulations, which most people do, because they can't be bothered to read these phenomenally boring regulatory documents, you end up with bureaucratic responses. You deserve what you get. If you're gonna be that lazy, if you're gonna outsource the interpretation, which is the effect of what you're doing, you're outsourcing to a bureaucrat the interpretation of your regulations, the bureaucrats will put together a bureaucratic strategy to address the regulations. If you let the practical people, and I hope you're all practical, if the practical people interpret the regulations, you'll end up with a practical response. Isn't that nice? So, take a hit and read the regulations every so often. Yes, they're phenomenally boring, and what can you do? Now, it's interesting at this point in time, I usually like to make a point that different teams are in different situations. So my team might be distributed, might be all in the same building, might be a team of five people in the same building in a non-regulatory environment. This gentleman's team could be spread across the planet, be 20 people in a regulatory environment. That gentleman's team could be 500 people on the same floor in a non-regulatory environment. That's okay. Different teams are gonna work in different manner. A team of five people, I think it's pretty obvious, that a team of five people will organize themselves differently, will work differently than a team of 50, than a team of 500. A team in a non-regulatory environment will organize themselves differently, and will work differently than a team that is suffering from having to comply to Sarbanes-Oxley, who in turn will work differently than a team that's in an FDA regime. A team that's co-located will very obviously work differently than a team that's spread across a building, than a team that's spread across the planet. Different teams, different situations, different ways of working. So many of you have heard about ideas such as CMMI and CMM who sometimes prompt the idea and actually they don't if you were to actually read those regulations or read those, that guidance. It often gets interpreted as we have to have a repeatable process. What a phenomenally stupid and ignorant thing to do. Repeatable processes are complete and utter nonsense. That is useless bureaucracy. Useless bureaucracy. Nobody wants repeatable processes other than useless bureaucrats. What we really want are repeatable results. We want to spend the money wisely. We want solutions that meet our needs. We want systems out in a timely manner. We want sufficient quality. Nobody cares what processes you follow. This morning there was a gentleman talking about lean IT and their experience at their organization adopting lean stuff. It was a really good talk. And one of the things that he just mentioned offhand was that in their organization they had adopted CMMI, they were like level five, they were doing Six Sigma and they weren't getting the benefits. They were still unpredictable. They still had crap quality. There were some serious challenges. The promises were not because they were producing a lot of paperwork from the sounds of it. They weren't producing good solutions. And that's a perfect example of bureaucracy and not of discipline. So anyways, avoid, really don't get in the trap of looking for repeatable processes. The different teams are in different situations. You need to tailor your process. You need to tailor your tools. You need to tailor the team structure to fit the situation you find yourself in. One size does not fit all, will never fit all and never fit all and will never fit all. We need to be a lot smarter about the, we need discipline, we need skill. We need to be a lot smarter about the way we work. Sometimes you have domain complexity. Pretty straightforward to build an informational website. A little harder to build an e-commerce system. A little harder to build a, you know, the Watson system that wins at Jeopardy or an air traffic control system or the control system for a nuclear power plant. Okay, so different teams are in different situations. I would hope that the team working on a nuclear power plant works in a slightly more sophisticated manner than the team building a website. God fuel tells me that would be happening. Sometimes we're organizationally distributed. Now, I'm sure none of you are involved in outsourcing here. But sometimes some organizations split the work up. They do some of the work and they have another company do some of the work. Or they partner, you know, sometimes there's companies that are partnering together. So, and this adds some complexity. It's pretty easy when everybody works for the same division of the same company. A little harder when you're working for multiple divisions. Harder yet when you're trying to partner with other similar companies to build some sort of shared infrastructure. Harder yet when you have outsourcing and contractors and all this sort of stuff that's being thrown into play. Sometimes there's technical complexity. Yes, it's pretty easy when you're building a silo system that is a green field so it doesn't have to connect to anything. Brand new technologies. No legacy whatsoever using all the whiz bang tools. Yeah, that's pretty straightforward. Some of us though are working in situations where maybe it's not the greatest, you know, the brand new technology anymore. Maybe it's not a standalone system. Maybe we have some legacy code that we have to integrate with. Maybe there's some legacy code that we have to evolve and fix. Maybe there's some legacy data that we have to use. Maybe there's some legacy data that we darn well should be fixing because my data people don't know how to do it themselves. Not that I'm bitter about that. Promo and Satellage had a great talk a couple of days ago, I hope, about fixing databases and stuff like that. So it's a little bit more difficult than something. So over lunch I was talking to somebody who had a situation where they were dealing with legacy code. How do you fix work on a mainframe and do Agil on a mainframe and fix this ancient cobalt stuff? Well, yes, it's possible, by the way. People are in fact succeeding at that. And it's highly desirable to do because some of these cobalt programmers are getting a little old and are going to retire soon. And that cobalt stuff is not going away, folks. I now know people. I have friends who are working on source code that is older than they are. I have absolutely no doubt that somewhere in the world there is a programmer right now working on source code that their father wrote. In a few years it'll be their grandfather wrote it. I have no doubt that that's going to happen. This source code stuff does not go away. Sometimes there's organizational complexity. It's often not this big happy family we keep reading about. There's politics. There's people in different parts of the organization have very different ways that they want to work. The CMI folks might not appreciate the fact that I'm beating up on them. But you can in fact do Agil and still be CMI compliant. There's some wonderful writings on that if you choose to read them. Sometimes the data folks have this very coherent at least to them this very coherent story for why they have to do these detailed logical data models up front followed by detailed physical data models. And then and only then would the programmers be allowed to start coding. They had these coherence. Well, they think it's coherent. But regardless of all the evidence showing that it doesn't work very well. But that's their religion. They believe in that and they have a good story around it. You still have to work with these folks. You still have to find a way to work together. So that brings a few complexities into the situation. And then finally, and this is the one where it's a bit weird. The discipline teams actually want to be on the right hand side not on the left hand side. And the basic idea here is you should have enterprise discipline or enterprise awareness. You should want to be following common coding conventions. You should want to be working close to the enterprise architects to understand what your infrastructure is. What can I reuse? What should I be building out so that that way other teams can reuse them? Where are my legacy data sources so that I'm not creating yet another customer database? Where, how do I fit into the overall portfolio management stuff? How do we govern the teams effectively? That would be a wonderful thing. A lot of IT governance efforts are phenomenally dysfunctional. They're dysfunctional for the traditional teams let alone for the agile teams. And these stage gate documentation based governance approaches are not good, particularly not good for agile but not that good for traditional stuff as well. So having enterprise discipline can change, also affect the way that you tailor your process, the tailor your tools, tailor the structure of your team. It was interesting that the previous speaker in here was talking about architecture and how architects fit on the team. And it was pretty clear that some people in the audience really were not getting it. And it was like a foreign concept to them. And what happens is when you start having an enterprise discipline, I think actually enterprise discipline was in the title of her talk or something very similar to that term. When you start looking at the bigger picture, you start changing the way. So she was in an environment where they were a little more mature and they realized they needed these architects on the team and that changed the team structure. They added an architect and the architect did stuff and help the team and did whatever, right? So it changed the team structure let alone the process and obviously the process they were following. And may even have changed the tools they were using. Maybe that architect started whipped out a modeling tool or something and started doing modeling. So who knows? So anyways, interesting observation to have. So how does this affect things? So let's walk through a few common practices. So how would I scale daily stand-up meetings or a daily scrum meeting, whatever you want to call that. So first of all, when we move to a more discipline approach, we start calling them by what the incident is calling it a scrum meeting, which is a branded term. Let's call it what it is. It's a coordination meeting and there's different ways of holding it of course, but it's a coordination meeting. It's not a scrum meeting or a daily stand-up. When you're geographically distributed, you're at least going to involve phones or maybe video conferencing or something. Maybe even typing, I'm going to make all these slides available on the agile site on the conference site. So you don't need to worry about writing madly. But yeah, you'll be doing some sort of electronic chatting or something. And they certainly won't be doing a stand-up meeting. I've actually been in situations where the scrum, so we have teams in multiple locations and the scrum master on the phone is saying, I want everybody to stand up at their desk so we can have the stand-up meeting. Do you really think that people are going to stand up to have a conversation over the phone? No, just boom, stupid. But anyways, what can you do? When the team gets bigger, there's a different way you've got to deal with it. You can maybe have a scrum of scrums and that's good for up to medium-sized teams. I'll talk about this in a bit. It craps out with really large teams. Or you can take the combine strategy where they speak on a task board and what they're really looking for. What are the bottlenecks? What problems do you foresee? Because they don't need to worry about the stat... Because if you're working closely together on the team, we don't need to hear the status, all the status reporting that occurs in the scrum meetings. If this group of people here was a big team, a team of, I don't know, 100 people, I don't know what it is, but say you're a team of 100 people. Even if you're co-located in a really big room, I'm not working... I'm not really working with all 100 of these people today. I'm working with these three or four gentlemen across the front on a regular basis. And because I was working with them all day long yesterday, I got a pretty good idea what they did. They got a pretty good idea what I did. So we don't need to hear our status. We know. The people over there, I haven't interacted with them for months now because they're not really part of my little group of doing whatever it is that we're doing. I could care less what their status is. As long as they're not screwing up and affecting me or if I'm not screwing up and affecting them, we don't really care what they did yesterday. I don't care what they did yesterday. I don't care what they're going to do today. They don't care what I did yesterday. I don't care. And they don't care what I'm going to do today. It's useless extraneous information. Everybody's wasting their time hearing this stuff. So in common, what they focus on is the real value. What's blocking us? If there's nothing blocking us, hey, we're good to go. Stop the meeting and let's go get some work done. If we're in a regulatory compliance situation, maybe we're sick meeting attendance. Maybe we're going to have to record action items because you got to show that you're following the process. At least you're going to have to record the fact that you held a meeting because in some regulations, you got to show that you're following whatever your process is. If you're organizationally distributed, so you've got different people working on different teams, you might not actually be a lot... If you've ever worked in a secret type of a situation or like a government situation, if you're working for the military, different teams might not even be allowed to know that the other teams exist, let alone what they're doing. So you got to be very careful about what status you're sharing. Or if you've got multiple consulting organizations involved. So I got TCS, I got WEPRO, I got IBM, and we're all working together for a bank in Europe. Chances are pretty good that the WEPRO people and the TCS people and the IBM people don't really want to share details with each other. This is real-world stuff now. So this is going to change the way that we hold meetings. We're going to make sure that only the right people are talking to each other. And if we've got enterprise discipline, we might have enterprise professionals showing up at the meetings. I might be inviting my portfolio management people to when I'm discussing project management issues. Or in my architecture meetings, I might bring in the enterprise architects and ask them to be involved. And if I'm really smart, I'll ditch the chicken and pig concept because I want those, if I'm inviting those people, I want them to actually participate. And the chicken and pig thing is rather insulting and disrespectful if you step back and think about it. And if you don't know what I'm talking about, you're lucky, don't worry about it. Okay, so scaling self-organization. If you consider this a practice. Okay, so like I said, one of the very first steps when you're moving from the construction focus of scrum to the delivery focus of dad, the very first thing is we bring in the concept of appropriate governance, the adult supervision concept. Because this is what we see. This is the types of things we see in real enterprises. If we're in a regulatory compliance situation, these plans or these estimates that we're talking about, we might have to record them. We might have to actually document them on more than just index cards in order to avoid fines and stuff like that. If we have organizational complexity, organizational complexity is IBM's nice way of saying organization dysfunction. So if we have a dysfunctional organization, we might need to educate our management team on basic leadership stuff and basic facilitation stuff and why this self-organization concept is a good thing and why they should be promoting it. We should be helping them get away from the command and control stuff. I ran a survey about a year and a half ago and within the agile community, I was trying to judge how agile people actually were. So I asked these, so are you agile? Yes, okay. Then I asked a bunch of other questions to explore how agile they were and roughly half the people claiming to be agile were agile in my mind. And I was being phenomenally generous. And one of the things that the most common thing that people were not as agile on as they should have been was self-organization. And I highly suspect the project management offices in their companies were getting in the way. They weren't allowing these teams to be self-organized and they weren't allowing them to have stand-up meetings or coordination meetings, I should say. They weren't allowing the developers to do the estimation and stuff like that. They were still being told what to do. They were still being told what the plan was. This is not good. This is hampering people's agility to be successful. At the enterprise discipline level, I might be bringing in the enterprise architects to help us help drive some of our architecture decisions or help motivate or mentor some of our people in this stuff. I might adopt some governance strategies from lean development governance. So things change, different situations. So here's the interesting thing. So for both of these practices, it's still the same basic practice of having a coordination meeting every day. Because you're in a different situation, you'll have a different flavor of that practice. Same thing with self-organization. The flavor will change depending on what scaling factors affect you. If you're doing an iteration demo, it will change based on the situation you find yourself in. If you're distributed, you might be doing a webcast instead of a face-to-face demo. In a regulatory environment, you might have to take meeting minutes again. You might have to re-context. In other contexts, it's really bad advice. So let's be clear about the context of the advice that we give. So having a daily stand-up, that's great advice for when you're co-located. When everybody's on the end of a phone line telling them to stand up is a stupid thing to do. Obviously, stupid. So it's not really a stand-up meeting. It's a coordination meeting. So basic things like this. So the advice should depend. Okay, so some practices that you might want to adopt that maybe you haven't heard of. Maybe you never heard in your two-day certification courses. So first of all, you might want to think before acting. This is what some of the agile modeling practices are around. So in the agile modeling methodology, which I led the development of over 10 years ago now, we have a few practices for doing some up-front, lightweight up-front requirements envisioning, some lightweight up-front architecture envisioning. By the way, 90 some odd percent of agile teams do some up-front modeling, regardless of the rhetoric you might have heard. And that is information coming from agile people. Because I run surveys, I ask you a bunch of stuff, are you doing this, are you doing that, what's happening, blah, blah, blah. And 90% of them, over 90% of the respondents have very clearly said, yeah, we're doing some form of up-front requirements modeling, some form of up-front architecture modeling, some form of up-front planning. Then you do modeling throughout the life cycle. Modeling is part of iteration planning. So you're pulling user stories or features or whatever off the stack, and you start talking about it, you might do a whiteboard sketch to figure out what the tasks are, you're at least talking about it. So modeling ends up becoming part of, it's actually part of your planning efforts. And it was actually interesting, I ran a survey just recently about planning and how people do planning throughout an agile project. One of the things I did, I luckily had an open form question where I was, when I was asking about initial modeling on a project, and roughly half of the response, this is how, I was just shocked at this, roughly half of the respondents to the survey were talking about doing initial requirements modeling, and they thought it was planning. So they were doing, yeah, so their idea of initial plan, which is okay, it's good that they're doing this, don't get me wrong, but they were struggling to communicate what they were doing. So they were doing, initial, they're doing, they're populating the backlog basically, right? So they're identifying a bunch of initial user stories and prioritizing them, and then they said that this is my planning activity. Well, no, that's initial modeling, and well, prioritization is arguably planning. Okay, fine. But creating the user stories, that's a modeling activity. So, we need to get better at communicating with the heck we're doing. But anyways, that's an example of requirements envisioning actually. And then finally, and we're doing documentation throughout the life cycle, either we're doing continuous documentation within the iterations themselves, or, which, so if you want to be potentially shipable, that's the way you got to work. Perhaps a better, well, there's risks involved, but the most efficient way is actually to leave the documentation towards the end of the life cycle. But you've got a very, but then you're not potentially shipable, so you get some very serious risks there. Cheaper to do, but there's some risks. So, there's always trade-offs. There's no perfect situation. And executable specifications are writing tests instead of writing static documents. So, instead of writing an SRS, you write executable and acceptance tests, things like that. So, and obviously require skill and the right tools and discipline and all that sort of stuff. So, there's a bunch of practices in Agile. And, you know, obviously Agile modeling is not the only one talking about test-driven development, but those practices are there, if you're interested, at agilemodeling.com. Appropriate governance. So, I used this term earlier. What is appropriate governance? Good governance is based on collaboration and motivation and on enablement. So, it should be based on human behavior. Command and control governance of you. Follow my Java coding conventions or else. Chances are he's not going to do it, right? He's an intellectual worker. He was probably just insulted because I had the nerve to tell him how to do his job properly, even though my Java coding standards are in fact fantastic. He thinks better. He knows better. What is this guy now? Screw him. He's senior management. Idiot. But if I say, well, you know, we've got these corporate coding conventions. It's really good. It would be really good. We would like you to follow them because we'd really like everybody to be writing the same basic code because it's easy. If everybody's following the same conventions, I'd say if you have to update somebody else's code, you'll be able to read it easier. If somebody else has to update your code, they'll be able to read it easier, leads to better quality, blah, blah, blah. A bunch of benefits for doing that. So, I motivate them. So, it's a coherent story, right? People are like, yeah, yeah, he's pretty little inconvenient, but he's pretty much right. Okay, so their motivation is there. Then if I also say, oh, and by the way, here's this tool that you can throw into your continuous integration to check against the coding standard. So, we can automate that. And I can throw warnings. And so, if you break the coding, if you go against the coding convention, I'll throw a warning the next time you compile or the next time you build and let you know that. So, that way you can very quickly learn what the coding conventions are. Oh, making it easy now for me. So, I motivate them to do the right thing. I make it as easy as possible to the right thing. I also make it difficult to do the wrong thing because if he screws around, it follows his own coding conventions because he still thinks he knows better than me, he's going to get a heck of a lot of warnings coming out of the static code analysis, right? It's going to make it harder and harder and harder and harder for him to do the wrong thing. So, reward the right things, punish the wrong things. That's going to greatly increase the chance that your teams follow and do whatever it is that you desire them to do. So, that's one aspect of governance. Another aspect of governance is monitoring the teams. So, good governance should, if I'm on the governing body in your organization, my goal should be to help make it as easy as possible for your teams to do the right thing, to get rid of some of the barriers to success. Some of the things that they talk about scrum masters doing at the project level, we should also need to occur at the organization level. I should be trying to make sure that you're building the right thing, that there isn't other teams out there, so that this guy here, he's not working on an ERP system. This guy here down the street in another building is also working on an ERP system. I don't need two ERP systems, right? So, if I'm governing effective relations, I say, whoa, wait, what the heck is this? And I should get these teams talking, and they're figuring out how to motivate them to come to some sort of solution to have one ERP system to get the job done, things like that. I should also be doing, hopefully, have automated metrics, having, if I adopt tools that generate the metrics for me, then I can have automated dashboards that show the metrics. If you want to get an example, if you drop by jazz.net, you can see live project dashboards from several IBM teams of building actual products in progress, and all of those metrics are being generated automatically by their tools. So the burn down charts, the defect trend analysis, the build history, and a bunch of other stuff, all those charts are being generated automatically. No more of this typing stuff into Excel or typing stuff into a point specific tool. All bureaucracy, by the way, even though it's blessed, the blessed bureaucracy of Scrum, it's still bureaucracy. You could automate all that away if you choose to, and that way you can actually focus on doing your jobs. And the beautiful thing about that is great for the teams because they can focus on doing their jobs, as opposed to focusing on status reporting type stuff, like manually generating a burn down chart. And better yet, if I'm from a governance point of view, I can get accurate real-time assessment of what the heck's going on in the team. So if I notice that something's going wrong, I can walk down the hall or hop on the phone or get on the chat system and ask what's going on is there anything I can do to help? So if I see that your build has been broken for a couple of days, that might be a clue to me. Maybe I should give you a call because maybe you're running short of heart. Now you've got some hardware problems. You've got network problems. Your build master died. Who knows, right? Maybe I can help. So this is the idea here. And maybe I can make coherent decisions. If I know your actual status, I might be able to make real decisions to help your team as opposed to guessing. It's interesting. We like to make fun. Developers like to make fun of senior management, right? They're stupid. They don't know what they're doing. And that's when they're being polite. It's not true. It's not true. These are smart people. They really are. They're smart people. They're doing the best that they can, given the information that they've got. Well, if they're making what appears to be stupid decisions, well, it's good decisions based on whatever crappy information they had. If we can improve the timeliness of the information, if we can improve the quality and the accuracy of the information, chances are managers will start making less stupid decisions because they are smart people who are actively trying to do the best that they can do. They really are. They're good, decent people. They really are. And they're doing the best that they can do. So let's give them more accurate information. Let's help them understand what the heck is going on. That will increase the chance that they don't get in our way. Wouldn't that be nice? So anyway, something to think about. Another technique that you might do at scale, something called parallel independent testing. So in Agile, we talk a lot about how the development team should be doing their own testing and the whole team testing all this great stuff. TDD, love it. Problem is it's not sufficient. So yeah, if I'm in a small team in a small organization, yeah, whole team testing is probably going to get the job done. You're assuming you got the skills, right? So we'll give the Agile teams the benefit of the doubts. They got the skills. They got the tools. They know what they're doing. Let's assume that. It's not always true, but let's assume that for the sake of discussion. Even then, they could be in trouble. So in a few situations, I might have to have an independent testing team. In a regulatory environment, I'm probably going to have to have some form of independent testing. Most regulations imply that. If I'm in a complex domain, if I'm doing a complex system, I might have some very interesting integration issues. So earlier, if I'm one of 20 teams in the organization, then I've got to make sure I'm testing against these other systems that are also in flight that are also being developed. I can't do that. I don't have the resources. I can't possibly keep track of these other 20 teams' builds. I can't possibly do all the integration work that I need to do to get them all up and running. Regardless of the wonders of virtualization, and IBM is happy to sell you anything you need to do it, regardless of all that wonderful stuff, you're still probably not going to have the resources to simulate production in an intelligent manner. And you certainly will not have the resources. No organization has the resources to do it individually for 20 different teams in flight, let alone 100 teams, or whatever you've actually got up and running right now. So economically, you're going to have to have an independent test team that will do this pre-production system integration testing for me. So my team will push my build, or make my working build available to that test team. Your team will do it. Your team will do it. Your team will do it. And then the test team will do this harder form of testing of making sure everything works together well. And then when it doesn't, they report defects back to the individual teams. And they might be doing even other forms of testing, like security testing. How many of you are working on systems where you have security experts on your teams right now? A few of you. How many of you are working on systems where you might have some security concerns because maybe you're building a web-based system? Oh, uh-oh. Screwed, right? You're basically screwed if you've got security concerns and you don't have security people on your team. So you might want to be doing some security testing. So if the independent testers know this, oh, they're building a web-based system that's going to be deployed out to the internet. Oh, there's a few hackers out there that like to break into systems. Maybe we should be doing some security testing, right? So, and because security testing is a skill and there's expensive tools and stuff like that, and you're more than likely, you're not going to have the ability to put security experts on every single team. We saw this just now. More than likely, you're not going to have the money to buy expensive security testing tools for every single team, right? So economically, you're going to want to centralize. This is a bunch of different reasons for having independent testing. It's a phenomenally good idea. And worst case, if you put an independent testing team up and you find out that they're not finding any defects because the agile team is actually doing a phenomenal job at testing, okay, fine. That's great. Now you know, now you've verified that. If on the other hand, you find, oh, this independent testing team is in fact finding defects early in the life cycle when they're inexpensive to fix, that's probably a good thing. I don't want to be doing testing at the end of the life cycle. I don't want to leave acceptance testing to the end. I don't want to leave integration testing to the end. That's the worst possible time to do testing is at the end of a project. The most expensive way of doing it. Well, actually the most expensive way is to not do any testing at all and let your users test. And bad things really happen. But yeah, I want to push testing to the front of the life cycle as much as possible. So large team stuff and then we'll end up. So the basic idea here is how do you organize a large team? There's a lot of literature around how do you organize small teams. But what happens when you've got a team that's 100 people, 150, 200 people? First of all, you're going to organize and there's no such thing as a 100 person team. It's a team of teams. So how are you going to coordinate these sub teams with each other? So if you're only three or four sub teams, then yeah, doing a daily Scrum of Scrums where you share your status and all sorts of stuff with each other, that'll probably get the job done. But when you're in a larger situation and you get a larger team than that, the Scrum of Scrums concept starts to fall down. What's happening here is there's three, maybe four things that you're coordinating. First, you're coordinating basic project management stuff. You know, what's the current status? How much money are we spending? Are we onboarding people? Are we off-boarding people? And if I've got a team of 100 people, chances are pretty good one or two people left this iteration. One or two people got hired on this iteration. So I've got these basic management stuff of bringing them on and off. If I've got a 100 person team, I don't know what your charge rates are here, but you're spending a fair bit of money every week. You probably should be tracking it. So there's the basic project manager, program management stuff that should be occurring here. Somebody should be making some coherent decisions. You should be coordinating the activities between the teams. Then on the requirements management side of things, the product, there's dependencies, functional dependencies between requirements between the different subteams have got. So you've got to manage these things. So if my team is working on something right now and we expect a feature that this gentleman's team is working on, then if we're managing things accordingly, his team will either be doing it in the same iteration as mine or in iteration before. Because if I depend on him to deliver something, and we're both in iteration five right now, but his product owner has prioritized it down to iteration nine, the things that I need in iteration five, I'm out of luck. I can have to mock it out or whatever. And as soon as I mock something out, I'm no longer potentially shippable. I now have a risk. So what we should do is the product owner should get together and negotiate. I need it in iteration five. He thinks it's going to be iteration nine. Maybe we split the difference. Maybe he prioritizes up. Maybe I prioritize down. But something got to occur, so that way everything works out well. So this prioritized simply based on business value, interesting and quaint concept for small teams for larger teams, reality gets in the way sometimes. So stuff like that happens. And then there's technical issues that you've got to coordinate. So you'll have an architecture owner on your team or an architect depending on your terminology, and they'll be part of the overall architecture team for the overall program. And they'll be negotiating technical issues as time goes on. And so people on the team will be bringing stuff up and everybody will be working together. And then finally there's probably an overall program manager keeping an eye on all this stuff and managing it all. Because you've got a 100-person team, I would hope there's at least enough work to keep one person busy coordinating everything. I'm even just running the leadership team is often enough. So the team lead or the scrum master in each team is part of the project management team. The product owner is part of the product ownership team. The architecture owner in each sub-team is part of that team. And then all these people together form the leadership team. So that's the basic idea. So these are some of the ways that you're going to be organizing larger teams. You'll probably have independent testers involved, which might be a sub-team all by itself. You might even have a build master or an integrator person because the integration effort is so difficult now because of the complexity that you're implementing. There's a couple strategies around. There's different ways to organize. There's great religious debates, all of which are a name around how do you organize large teams.