Leading a Self-Organizing Team
Cohn, Mike
One of the challenges of agile development is coming to grips with the role of leaders and managers of self-organizing teams. Many would-be ScrumMasters and agile coaches go to the extreme of refusing to exert any influence on their teams at all. Others retain too much of their prior command-and-control management styles and fail to unleash the creativity and productivity of a self-organizing team. Leading a self-organizing team can be a fine line. In this session you will learn the proper ways to influence the path taken by a team to solving the problems given to it. You will learn how to become comfortable in this role. You’ll understand why influencing a self-organizing team is neither sneaky nor inappropriate but is necessary. Drawing on analogies from fields such as evolutionary biology and the study of complex adaptive systems, the instructor will describe three factors necessary for self-organization to occur and then provide seven tools for guiding the direction taken by the team as they self-organize.
 What a busy week. NDC is always such a busy week. I appreciate you guys being here so close until the end. We got one more session in the event today. So thank you for being here and the next to last. I appreciate it. We're going to talk about leading a self-organizing team. Here's the answer. Buy pizza, get out of the way. We're done. No? There's more to it than that. There's more to leading a self-organizing team than just buying pizza and getting out of the way. So that's what we're going to talk about. Our agenda, three things. I want to talk about self-organization. I want to talk about subtle control and how we can exert subtle control over how a team self-organizes. We're going to talk about three things called containers, differences, and exchanges. These are things that you can use to influence, exert, subtle control over how a team self-organizes. And we're going to talk about team evolution, how a team evolves over time. So that's our agenda. So self-organization. Self-organization does not mean that a team gets to pick their own goal. Self-organization, self-organizing, is the proper term for what scrum teams do, what agile teams do. Some people will call it self-directed. That's not it. A self-directed team gets to pick their own goal. Some people will call it self-managing. That's not it. It's not self-managing. It's self-organizing. And teams organize in response to a challenge. So self-organization is a response to a challenge. So self-organization responds to a challenge defined by the product owner. Think about cars on the highway. Cars on the highway self-organize. They figure out who gets in what lane, who goes at what speed, who goes how close to somebody else. There's no police officer saying, you go next, you go next, why don't you go in that lane. Cars self-organize. So self-organization responds to a challenge. So what we do is we set up the right organizational environment, and then teams respond to that. Meaning we are going to be able to exert influence in a good way over how a team self-organizes. Now self-organization occurs in what are called complex adaptive systems, or CAS. And I've looked up some definitions of CAS. Here's kind of the ones I like. Where a complex adaptive system is a dynamic network of many agents. It didn't say people. Agents could be individuals. Agents could be groups. And they're acting in parallel, meaning they're both acting at the same time. And they're acting and reacting to one another. So a programmer is reacting to what a tester finds. A tester is reacting to how well the programmer did their code. We're acting and reacting to one another. In a complex adaptive system, there is no centralized control. There's not that police officer saying, you go next, you go next. So the control is decentralized. And the overall system behavior is not the result of one really smart decision maker, but it's the result of a bunch of small decisions being made, remade, adjusted. And this is how teams behave, or should be allowed to behave. A few examples of complex adaptive systems. Things like ant colonies, beehives, flock of geese, a family preparing a meal. You got little kids. You might have the mom or the dad assign tasks to the little kids. But a more mature family will figure out how to do this. Us right now, we self-organized. You had to figure out where to sit. You had to walk in. Some of you wanted to sit near the front. Maybe you forgot your glasses today. You want to sit here. A few other people wanted to sit near the door in case I get real boring. You had to figure out where to sit. That's self-organization. I used cars on the highway. Software teams, complex adaptive systems. Now, in this type of a situation, subtle control over a team over a complex adaptive system is not evil. We can use simple rules or incentives to guide behavior. We have rules about which side of the highway to drive on. I don't feel like that's some evil rule perpetrated on me by my government. I think a lot of other things are evil and perpetrated on me by my government. But not rules about the highway. That's a pretty realistic thing. I don't care what side of the highway we drive on. For me, it's pretty natural to drive on the right side, like you do here. But the English, India, going on the other side of the road, OK. I get it, kind of a random decision. I don't really care. Certainly used to one by now, so I don't want to change it. But I understand why different countries do different things. Bio teams, teams in biology or nature, their rules are provided by their environment. These are born with a desire and innate desire to produce honey. So these rules or incentives to behave are OK. And managers, leaders, scrum masters, product owners can add rules, can add incentives on top of a team to help that team. We don't do it because we're evil, manipulative jerks. We do it to help a team behave the best they can. I taught a product owner class the last two days, a scrum product owner class. I got down there the very first day around in the hotel, across the street. I got there around 6 o'clock the first day to make sure the tables were set up exactly how I wanted them. I taught a class a couple days before the room was a little too big. I didn't like how the tables were. So for the product owner class, I rearranged the tables. I sat a certain number of chairs at each table. I didn't do that to manipulate the attendees of that class. I did it to help create the best environment we could. I couldn't do anything here. These chairs are where they are. So I didn't get a chance to really exert subtle influence over you. But I did over that class, not because I'm evil, but because I wanted to create the best experience we could. So subtle control, not evil. I think certainly can be, but that's not the type we want to impose. Now, sometimes I feel alone in making this statement. So I want to get myself a little bit of support. Here's a little bit of support from a guy named Phillip Anderson. He's a scientist, business writer, and scientist. And I'll share with you his quote. He said, self-organization does not mean that workers, instead of managers, engineer an organizational design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from interaction of independent agents instead of specifying in advance what effective behavior is. So management doesn't decide it has to be this way. Management commits to guiding the evolution of a team, helping that team be continually better and better, have that team evolve to fit their environment. So that's management's commitment to help a team evolve to better fit their environment. Here's another quote. This is from the very first Scrum article. The very first article on Scrum is old. It came out January 1986. And here's a quote from that article. It says, although project teams, Scrum teams, are largely on their own, they are not uncontrolled. Management establishes enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos. Scrum teams are often talked about acting on the edge of chaos. They're going so fast, they're just about to go out of control. It says, at the same time, management avoids the kind of rigid control that impairs creativity and spontaneity. So we want a team going so fast, they're almost going to go out of control, but they're going just slow enough to be in control. And so that's where management sets up enough checkpoints to make sure that happens. Last quote to support this claim. This is from a 1990 book on Scrum. Bet you didn't even, or book that referenced Scrum, it wasn't all about Scrum, but it had a chapter on Scrum. Bet you didn't know there were all these old references to Scrum, 1986, 1990. And this one says, to be sure, control is exercised over the team. But it is subtle, and much of it is indirect. So we're talking about exercising this indirect control. So I'm not talking about being manipulative, deceptive, sneaky. I'm not doing anything like that. That's not what it's about. Nothing I want to advocate here needs to be done in secret. But there may be reasons why I don't broadcast my reasons to a team. Let me give you an example. I had a team whose decision-making style I didn't like. I felt like they were rushing into decisions. I don't know if they were making good or bad decisions, but I felt like they were making them too quickly. And so I put somebody else on the team who I knew had a more methodical decision-making style. He loved to debate everything. Kind of honest, to be honest, he kind of debated things a little too much. But I knew that having him on that team would slow them down. Because he'd ask a lot of questions. Have we considered this? What if we did this? Maybe we should try it out. Let's do a little bit more research. And so he would be a big counter to that team that was going too fast. Now, I didn't want to go to them and say, I feel like you're rushing into decisions. So I'm putting this guy on your project. Because that would have kind of defeated the purpose. Two years later, if we were out over beers one night, they say, hey, why did you put him on our project two years ago? I would have been happy to share the reason. But sometimes sharing the reason in advance can defeat the purpose. So I'm not necessarily going to broadcast why I do every intervention with a team. But I'm not ashamed of those interventions. And after the fact, I'd be happy to share it with the team why I did it. But again, sometimes by telling the team in advance, I might defeat the purpose a little bit. So not sneaky, not deceptive, but I still may not want to broadcast everything. So let's start out by looking at self-organization, subtle control. Actually, that's what we just did. I want to back up here. We did that. I want to go into containers, differences, and exchanges. Now, the idea of containers, differences, and exchanges come from a PhD paper that was done by a woman who was studying what is required for teams to self-organize. And she was studying both human teams and bio teams, ants, bees, things like that. And she said that for, and I've referenced her paper down here at the bottom, for a team to self-organize, they need three things. They need containers, differences, and exchanges. I need all three of these things. Now, a container is a boundary within which self-organization occurs. I said a moment ago, we self-organized in this room. They and that other room over there self-organized. Their self-organization didn't influence ours. But your individual self-organization influenced each other. I'm looking at one row up here, and it's great because we've got a person in every other seat. So where somebody sat who influenced one of the experts is that I want two arm rests. Don't blame people. So how individuals sat down influenced the others. How somebody sat in a room over there? No influence over us because we're in a different container. So some containers are physical. Some containers are more kind of conceptual. Your project is a container. Your role, you are database people. Your role is a database person. You're a member of the database developers at your company. You're a member of the JavaScript developers. Your nationality. I'm American. I'm actually one fourth of the region. I love my one fourth Norwegian-ness. Thank you, grandmother. But my nationality is kind of American. A number of people here have different nationalities. And if you were over in the US, you'd be like my grandmother was when she was there. She hung around with all the other Norwegians in San Francisco. You have people that move to another country. It's amazing how they all find each other. That's because of our boundaries that brings us together. Differences. We need differences. Pretty easy to have differences when we're talking about humans. We're going to have differences in terms of knowledge. You know some things better than I do. I know other things better than you do. We've got different levels of knowledge. That's a difference. Sometimes we have differences in our experience with the company. You know this domain really well. You've been with our company for 10 years. I got here 10 days ago. We have differences in terms of gender, differences in power. One of you might be a vice president of the company. I'm the intern. There's a power difference. So we need differences in order to self-organize. If everybody were the same, self-organization would be kind of random. We wouldn't do it. There'd be no difference. None of us would care. Last thing that we need for self-organization to occur are transforming exchanges. Transforming exchanges are conversations. You and I go talk to our product owner. Our product owner tells us about a client visit she did. We leave that conversation excited about how many people are going to buy our product. That was a transforming exchange. We leave motivated. You and I go talk to our architect. And we leave that conversation with our architect educated. That's a transforming exchange. I go down to the payroll department and pick up my paycheck. That's a transforming exchange, my favorite exchange. So we need these three things, containers, differences, and exchanges for self-organization to occur. We didn't have those things. We didn't have anything in common, like physical container. If we were all equal people, no difference whatsoever, impossible with people. If we never interacted, we wouldn't self-organize. I'm not interacting right now with somebody out on the street. So I need some sort of exchange. The way we can use this model, the container difference exchange model, is we can exert influence by altering these things. You can change the containers that are on a project. Change the team's physical space. Change their differences. Move somebody onto the project. I just gave you an example. I moved a guy onto the project to add a different decision-making style. I was trying to create a bigger difference in personality. It was amplifying the difference. That will change how a team will self-organize. Introduce a new exchange. So what we can do is we can exert influence by altering a team's containers, differences, or exchanges. Now, when you do this, you do not know how a team will respond. I love going into teams and getting them to start doing something like, let's say, pair programming. And I have a pretty good idea, because I've been doing it for years, how a team will respond to pair programming. After I've met that team, I know them a little bit, I can develop an opinion about how they'll respond to pair programming. But I don't know that. I don't know how they're going to respond. So I'm taking an educated guess. And then I consider this to be kind of a nudge. I kind of poke and prod. I nudge the group, hoping that introducing this will fix or improve some aspect of their situation. But I never know for sure. They're educated guesses. So we alter containers, differences, or exchanges. Not because it's just plain fun. We do it to improve the team, constantly trying to help a team get better. I want to give you a couple examples. I've given you a few already, but here are a few more. For containers, enlarge or shrink the team. Make the team bigger or smaller. That will change the container. Enlarge or shrink the responsibility of the team. Tell a team they're not responsible just for developing the thing, but for getting it deployed out in our data center. That's a change in responsibility. That's a changing container. I don't know how a team will respond to that. I can take educated guesses, but I'm not 100% sure. Change team memberships. Move him off her on. Change the team members. Create new teams or groups. Instead of the three teams we've got, let's create four smaller teams. That's a change in container. So we can do all those things, and we do it to help a team improve. Differences. Amplify or dampen the differences. Tell a team to change their decision-making style. Or just as a scrum master or coach, manager for that team, you change how they're making decisions. Do it by the questions you ask. I love asking teams hard questions. When you ask a team hard questions, you will find dissenting viewpoints. You will bring out the differences they have. What three alternatives did you reject before you chose this approach? What's the worst thing that could happen if we made this decision? How would we recover if this decision didn't work out for us? If you ask questions like this, and there is kind of underlying dissent with the direction they're headed, that will come up. Somebody on the team will say, well, I've been really worried about that. I'm glad you asked. Here's what I think might happen if we make this decision, and I'm worried about it. I'm going along with the team, but here's what I'm worried about. So you can amplify the differences, make them bigger by asking hard questions. You can dampen the differences. Stop asking those questions if you need a team to get to consensus sooner. These are communications that a team has. Encourage communication between teams. Find out who's talking that shouldn't be, or find an exchange that's happening that you don't think is necessary, and try to get a team to stop that exchange. Add or remove people to conversations. Maybe your team does a design review. Add somebody to that design review. Here's an example. You might not think this was a very agile thing to do. In this talk, isn't necessarily agile. We're just talking about self-organization. But if you know me, you know I'm kind of into agile. So you might not think this is a very agile thing to do. I had a particular team, and I told them all of your decisions, all of your key architectural decisions, I want you to run by this one really senior developer in the company. His name was Todd. And I said, I want you to run all your hard technical decisions by Todd. I went to Todd, who's an architect, not on that team. And I told him, I said, don't change many of their decisions. I really just mostly want you there to scare the team. If they know they have to come present to you, they're going to think through their architecture better, and they'll come to you prepared with good decisions. If they are about to make a big mistake, I absolutely want you to stop them from making that big mistake. But if it's just a small mistake, or if it's just the thing where you disagree with how they're going, but they're going to be successful their way, don't change them. Let them own that decision. That's fine. I said, but do stop them from big mistakes. So I put this new exchange in place. It probably sounds kind of unagile. I took a team that was a nice agile team, and I had them get approval on their design decisions from some outside guy, kind of a non-agile. I did it for their good. I did it to make them pause, reflect, think harder about decisions they were making. I didn't do it just because I wanted to slow them down. I didn't do it just because I liked this Todd guy and wanted reviews to go through him. I did it to help this agile team. So an example of introducing an exchange. Containers, differences, exchanges are things that we can control. We can alter. We can manipulate to help a team do better on their project. What I'd like to do, what I'd like to have you do, is a little exercise along this lines. So here's what I've got. Here's our exercise. I've got the next couple slides. These are the things I handed out. Hopefully you got one. If not, we can get more passed around. What I'd like you to do is to think about the cases on the next couple pages, just in little groups. Just kind of turn around, talk to a couple people next to you, and talk through one of these cases and decide what would you do in that case. If you don't have the handout, I'll just leave one of them up on the screen. You can talk about the one on this, talk about the two that will be on the slide. Let's do number one together here. You've got a team that's got four programmers, two testers, database guy, and you. The programmers and testers aren't working well together. Programmers work in isolation until two days are left in the iteration. Then they throw the code over the wall to the testers. Anybody got an idea what would be a good thing to change in that situation, suggesting for what you might do there? Yes? Change how they're seated, right? Move people around. Would that be a change in container? Difference or exchange? The two first ones? Containers and differences? Yeah, to me that would be a change in container, right? And it's probably then immediately going to lead to additional differences, right? It's going to get people who are different talking to each other, right? Another good example, I could introduce the idea of pairing. Have a programmer and tester pair. They're not doing it on their own. Let's just decide we're going to do this. As a scrum master for that team, I might say, hey guys, let's try cross discipline pairing. We're going to have programmers and testers pair early on to get this going. We might do that for a couple of sprints, and they'll realize it's a good way to go. I don't have to mandate it anymore, right? Is that a difference in container? Differences or exchange there? Exchange? Yeah, I'd go with exchange on that one. Now I see some people going, ooh, I don't know, right? You're right. A lot of times things will cross boundaries. They might be two of these things. That's fine. When you have something, and you're looking at this going, wow, this is really a container and an exchange, that's probably a pretty powerful intervention, as opposed to something that you can look at and go, wow, that's a pure container intervention. Something that's really kind of two things, pretty powerful intervention. That could be good or bad. Maybe you want a powerful intervention. This team needs to be kind of nudged in a powerful way. Maybe they need just a small nudge. Maybe you can find something that's just a difference you introduce. So what I want you to do, I'm going to put these up here. Two's up here, three, four. You've got to use them to hand out. If you didn't get one of these, I'm just going to leave the last one up here. Just take five minutes. Pick one or two of these. Talk about it. What would you change? What would you have this team do differently? And is that a change in container, difference, or exchange? Talk about that for five minutes. OK. Let's talk about this. I'm just going to pick one on each page. So we talked about one on the first page. Which one you want to talk about here? Anybody talk about three or four? You got a tip for me on this one? Anybody do three or four? No. Let's talk about it then. Now, what would you do on number three? You got a team consistently under committing during sprint planning. They finished their work, but it didn't seem like much. Product owner hasn't complained yet, but you're worried as the coach, you're worried that the product owner is going to complain. What might you change here? Yes? What would you change for this in the new container? What would you do in there? Where's the results of the data here? That's a good point. Is this something that's been persistent? I'm looking at the way I wrote this, and I said consistently under committing. So I'm assuming they've been doing it for a little while. What would you think to change? Well, usually what happens is the pulse on the track will be really consistent in the last four hours. OK. So I encourage them to take on the right advice. Might have been a spectacular fail your five or six sprints ago, right? And it's been consistent since then. What else? I'm going to bring a senior that consistently underestimates the work. OK. Bring a senior onto the team who consistently underestimates. That could do it, right? Now, that would be which? Get some tension on the team, right? Team should have some sort of tension. We don't want people who always do the same thing. A lot of times when we do have a team that under commits or over commits, it's not necessarily that we got a bad team or bad people on the team. We just have kind of a bad mix, right? And we change that up. We bring a different person onto the team. Just swap two people out. I'm not saying we bring anybody better on or anybody worse. It's just somebody different, right? Somebody different will have a different approach to things. We bring on one of those people who's just always really enthusiastic. We can do more. We can do more. Yeah, let's take this on, right? Rest of the team is nervous, but this guy's got an outgoing, let's do it, personality. Maybe they start to try one more, right? And maybe in this case, if they really are under committing, might be a better thing to do. It may not be the team's fault. It may be that the backlog isn't groomed. Is it really ready to go? In which case, I might want to do what? I want to introduce a meeting to make sure the backlog is groomed, is prepared. That would be a new exchange, right? Let's introduce a new meeting into our process where we make sure the backlog is well groomed before we do something, before we start a sprint, right? Let's just do one more, something on the last page here. Let's do number five. We got Jeff, a domineering senior developer. During iteration planning, the team defers him on every decision, even though he's a horrible estimator. You notice that Glantz is the other team members exchange wherever he suggests very low estimates. What do you want to do about this guy? Yes. Do what? Yeah, play poker, play planning poker, estimating poker, right? One of the nice things with estimating poker or planning poker is everybody turns over a card at the same time, right? If everybody turns over a card at the same time, we at least get to see people's independent opinion before this guy gets a chance to dominate the meeting, right? That would be, if I look at that as a way of introducing a new, or amplifying the differences, right? So that'd be a new difference to me. We've already got an exchange going. I already got an estimation meeting of some sort. We're going to change our technique. This would be a way of amplifying the differences between team members by having this first round of planning poker unbiased by any one estimator, right? So to me, the container difference exchange model is a way of thinking through problems. You have a problem with the team. You're trying to introduce a way to solve that problem. Thinking through the containers, differences, and exchanges can help address that. I can't tell for sure. Is the microphone on? It's working. OK. I wasn't hearing it, so I wanted to make sure. All I hear is this other group. So the last thing I want to talk about is influencing that team over time. Evolution. Self-organization is not a one-time thing. We don't self-organize and we're done. Self-organization is a path, right? And the team is never done. You can't put self-organization on a Gantt chart and say, boom, we're done. We've self-organized. It's a continual response to a challenge. So as the team self-organizes, you can continue to re-exert influence. Always trying to help that team be the best they can. Again, I consider these things like nudges. You're pushing the team in certain directions, and you never know for sure how they're going to respond. I want to share with you one other quote. This is from the same guy we looked at before, Philip Anderson. He said, self-organization proceeds from the premise that effective organization is evolved, not designed. You can't sit down up front and go, here's what we should look like. You have to evolve there. He says, it aims to create an environment in which success and growth, rights, browins, podemos solve a metric amount of problems that lead to We're not talking about turning people into marathon runners with fitness. We're talking about fitness for their environment. We're talking about a team that fits their environment. And so the team evolves to fit their environment even as their environment changes. And they say this happens not because management has mastered the art of planning and monitoring workflow. So management sets up an environment, management encourages change, management pushes teams to get better. So we are talking about things that you hear as scrum masters, product owners, project managers, just plain influential people in your organization can do to help that team evolve. Now, if we think about evolution, evolution is a result of three things. Variation, selection, and retention. All right, so think about a giraffe. In a giraffe, variation occurs when the first giraffe suddenly develops a long neck. Mutation refers to that long neck turning out to be a good thing. And retention occurs when that mutation, that long neck is passed on. So what we're looking at here is allowing teams to vary, allowing them to try new things. Having a mechanism that lets us determine which of those things they tried was good. Which of those things worked out and therefore should be retained by other teams. So our job in management is to help create this type of environment where we can experiment, where we can retain, where we can pass on the successful items. Here are seven things you can do to influence evolution. All right, from selecting the environment down to energizing the system. So we're going to walk through. Yeah, absolutely. Sorry, it's hard for me to see things. I got, oh, I got this noise. I got a big white. So. I got a lot of team members I wish would go away. So yeah, I think it does mean that. I mean, what we're talking about here, you know, kind of Darwin's term, survival of the fittest, right? We're talking about the teams that do the best in our environment, should be propagated, they should be continued, and practices that aren't working should start to fade away, right? So I'm not necessarily talking about, you know, teams evolving and teams going away. I'm talking about practices with those teams, things like that. So if a practice is not working and a new practice is discovered, right, testing early rather than testing late, yeah, I want the testing late practice to go away as we learn the benefit of testing early. So yeah, I do. Good point. So here are seven things. We're going to talk about each of these seven, right? Selecting the external environment. What we're after here is defining the environment for your team. And this is more than just your physical office environment, right? This is more than the type of chair you've got, right? To some extent, it's what business we're in. Now you probably can't influence that, but somebody can in the organization. This has to do with your company's approach to innovation, right? Some companies are innovators. Others are fast followers. I'm not going to judge and say one's better than the other, right? Being a fast follower, Hewlett Packard, right, known for making printers, right? They're known as a fast follower, right? They're generally not the first one to come out with the idea, but they follow and then they do it better than anybody else in terms of making it a long-term product. What's our corporate culture towards mistakes, right? Do we penalize somebody when they make a mistake? Chop their head off, right? What type of projects are worked on? Which type of projects are praised in the organization? Do we try to do too many projects at once? All of these things have to do with our physical environment, our external environment, right? The environment in which the projects are occurring, right? I've got multitasking and focus, right? What do we like to do here? Do we want to have people focused, get one thing done? Or, we want to have those companies where everybody's on eight projects, right? I was with a client last year. I was supposed to be there for a week. I did one day and I left, right? I was there as teaching a class and I looked up too many times during the first day and I couldn't make eye contact with a single person in the room. There's like 30 people in the room, every one of them, every time I looked, banging away on their laptop, right? And then they're asking me questions every now and then like, should a Sprint Master do this during the daily Sprint, right? It's like, sorry, those aren't even the right words, right? They're not getting it. And so this was a culture where everybody was expected because the boss did it. Everybody was expected to just be banging away on your laptop all day during every meeting. I went to the boss at the end of the day and said, you're not going to be successful. I don't want to be a part of this, right? I didn't bill him for the one day I was there and I flew home, right? So what is our company expectations towards multitasking, towards focus, right? As leaders in the company, right, we can define what is good performance, right? What makes a successful employee in our company, right? You've all been in part of companies or in companies where there's some boss who praises the hero, who worked really hard to solve a problem that that guy caused himself, right? I've seen that way too many times, right? This guy causes a crisis, then he works hard to solve the crisis and he gets praised, right? Isn't this guy a hard worker, which should all be more like him, right? What type of message does your company send in terms of long and short-term performance, right? I'm sure there's a company who had people planned to come here today, come here this week, and then last week they decided, uh-oh, we're too busy. Let's cancel the person's attendance at NDC. I guarantee somebody was in that position. None of you, because you're all here, right? But somebody had their attendance here canceled at the very last minute. What type of message does that send employees in that company in terms of the long-term versus the short-term? We don't want to invest in this, uh, this employee over the long-term because the short-term is such a crisis, right? Not a good sign to send, right? We can manage what's meaningful in our company, right? What messages do we respond to, right? What messages do we hear? What signals danger in our environment, right? Think about ants responding. They follow trails, right? There's food over here. They follow a trail, right? Think about the messages that you can push to your team about what's valuable. What messages can you push that are good? I want to share you one story about messages in a company where I worked. I worked in this company where we were a startup. We had about 200 employees at the time, and we were about to turn profitable. We were just about to do it. If things went well this quarter, we would be profitable. And we were a public company. We had gone public earlier in the year. And if we could be profitable, that was going to be huge for our stock price. And so the company president has us all come in to a company meeting, and he talks about this, and he talks about how important it is to keep costs down. Please do not go on a business trip this quarter if you can put it off. Please don't buy office supplies this quarter if you can put it off by all you want next quarter. But let's try to get profitable. It is going to be so close. And while we're having this meeting, he tells us that he's got the janitors going around to all of the toilets in the building, and they are replacing the nice, comfortable, two-ply toilet paper with one-ply toilet paper. Now, I'm sure this cost him money to replace whatever toilet paper we had with a lower-quality toilet paper. But he said every time we were in the bathroom, he wanted us thinking about company profitability. Very ridiculous, but man, what a way to make his point. What a way to make his point. I remember this is 20 years ago, and I remember this as though I were still there. I was working with another company. They were trying to get me to come in and do some consulting, and I pretty much decided I'm not going to do it. I'm just going to kind of finish out this kind of day where I'm helping them out for free, and I'm not going to come back. And I'm waiting for the general manager to come by, and this vice president who's kind of been pushing me around different places all day, said, I can't wait for you to meet our general manager. He is so great, and he talks about how this general manager counts the cars in the parking lot every day at 5 p.m. Now, 5 p.m. is kind of an early but normal quitting time in the U.S. A lot of people may be there until 5.30, maybe 6 o'clock. And so this guy goes, because they don't come in until later, and this guy goes out at 5 o'clock and counts the cars in the parking lot. And so I said to the vice president who's got me there, I said, wow, that's great. He counts the cars. Then what does he do? He goes around and finds all the people who are still here at 5 and send them home because they've worked so much? He said, no, no, no, we want people here later. And so this had become part of their company culture. This was horrible that this vice, this general manager was going to walk around and count the cars. And he did. He had a chart. He had a little graph in his office, how many cars were in the office or in the parking lot every day at 5 p.m. He was fired about a year later. And the division of the business was sold about six months after that. So what type of stories are told in the company? What has meaning in the company? Choosing people is a management responsibility. Who is on the team is going to influence how they self-organize. And so when we choose the team, we can do things like adjust team size, location, background, experience, the decision-making style of people, the gender of the people on the team. What's the gender up if that's going to be good, right? The motivation. People who are skeptical versus people who are just very enthusiastic. I remember one guy I had on a team. He was just kind of a mediocre programmer. But man, he was good for helping a team come together. He was the guy that was having people over to his house on the weekend for parties. He was the one encouraging people to go out for beer afterwards or the new Star Trek movies out. Let's go see that. I was considered this guy to be like glue. He was one of the highest paid guys in my department because of this behavior that he had. Not because he was an amazingly talented programmer. He was a little above average. But he was like glue. He kept a team together. And I remember having two teams in two different cities that didn't get along. I put him on one of those two teams so he could help them get along. And he did. So think about the people that we put on a team. So one of the questions that this brings up is should a team have full control over it? My answer is going to be no. I do not think the team should have full control over who's on the team. They should have opinions. They should have influence. But it's a management responsibility to select who is on the team. The very first article on Scrum talks about this and validates me in this opinion. This is back to a team being self-organizing. If you give the team total responsibility for who's on the team, it's very possible that they select team members who are all very similar to one another. So this remains a management responsibility. I want to listen to the team. I want to be very influenced by who they want on the team. But I'm not willing to give that up as management in the organization. Because this is one of the primary levers I can pull to help a team self-organize. So who's on the team? Up to management. Totally should be influenced by the team. But it's a management decision. Yeah? Do you think the team should be able to choose their own roles? Largely. I do. So do I think team members should be able to pick their own roles? Yeah, largely I do. I don't think that we hired you to be a DBA and you think database stuff is boring all of a sudden and you'd like to be our new superstar Python programmer even though we don't program in Python in this company. No, I don't think you have the right to do that. But I do want people to help figure out what they want to do. I do think we should have influence over those things. But the team still has to respond to the challenge that they're given. And if the other team members don't want you doing that because they need you doing the other thing, I think they have influence over that as well. So I don't think you can just completely change your direction on a team. The way I like to think of team members is I think of us as team member first and then JavaScript programmer second or database person second. But you're a team member first doing whatever you can to help the team. But you're largely going to stay within some sort of specialty evolving that over time. Three more things. Number five here. It has to do with reconfiguring the network. I'm not talking about the data network. I'm talking about the people network, the human network. Communication paths in an organization. These can often be more important than the individual people. How do we communicate? And you can introduce or remove communication paths. I talked about having everybody run things by an external architect. Introducing new communication paths. So I want to give an example of a distributed team and reconfiguring the network on a distributed team. So suppose we have this situation. Half of our team is here. Half of our team is back in my hometown Denver, Colorado. One way to structure those teams would be like this. We would have an intact team here in Oslo. Programmer, tester, designer, data. Everybody necessary here in Oslo. We have everybody necessary to be a good team in Denver. And then we just coordinate. That's one option. Another approach would be to create what are called deliberately distributed teams. In a deliberately distributed team, we would set up one team that's half here, half there. A second team that's half here, half there. There are advantages to either approach. If we have an Oslo team and a Denver team, it's entirely possible that we end up with a little us them mentality. It's their fault. No, it's their fault. If we end up with a team half here, half there. A second team half here, half there. Probably not going to have us and them problems. But we're going to have people doing meetings at weird times of the day. Phone calls early in the morning from Denver to late in the afternoon here. There are problems either way here. So I'm not going to tell you do it the top way, do it the bottom way. I do it both ways. Sometimes the top, sometimes the bottom. But this should be a thing that you can consider in terms of how are you going to structure that team. I've been involved in a lot of acquisitions where one company's acquired the other than I get involved to help kind of fix the development problems at the acquired company. When we do that, I far prefer the bottom approach. Because if one company acquires another, I want to get those teams working well together and setting up separate cities. Kind of desirable in a lot of ways, but not when there's an acquisition. Because we've got kind of an us and them thing going already. So top or bottom, either one can work, be aware there's pros and cons. Number six of seven. Evolved vicarious selection systems. So we talked about variation selection retention. One of the things I would love to do is have 20 teams in our company. Have those teams run for five years and at the end of five years, figure out which one of those teams created the most profitable products. And then take that process that that team used and replicate that to all other teams. The problem with that is it just took us five years to find out which one of those teams was more successful. So what we'd like to do is create vicarious alternative selection systems. A selection system that doesn't take an entire generation of giraffes to select long necks. I want to find something that will help us create those mutations and retain them more quickly. So I don't want to trust the marketplace because it's going to be too long of a cycle. So one of the things that you can do here is create alternative selection systems. Google's 20% policy. Everybody's familiar with this. Where Google tells people that you can spend 20% of your time on any project you want. What do you think that tells Google when they see a whole bunch of employees flocking to work on a certain project? That is a really good indicator that that project has captured people's attention. And one of Google's premises for years has been that their engineers are pretty much their audience. Right? They're after people like themselves. Right? They're building stuff for people like themselves. So if their engineers all want to work on a new system, that system is likely to be profitable and they should let those people work on that system. So what we want to do, we want to create these approaches that let us monitor what's successful and select it without having to wait for entire market cycles to indicate this. The last thing that we can do is to pump energy into the system. In the U.S., overtime is a big issue. And people are always trying to get people to work more overtime, work longer hours, things like that. And I've been a vice president in four different organizations and I've never been after overtime from my people. I was never really trying to get people to work 60 and 80 hours a week. What I was after, on the other hand, was having my team members go home after eight hours mentally exhausted. They had left it in the office. They were tired. Did not want to see a computer when they went home. They put so much energy into the day they were done. So what I'm after is people's energy, not just hours. And so what we can do as leaders is pump energy into the system. And we do that by giving teams an igniting purpose. What ignites a team's passion? Sometimes called a clear, elevating goal. What can we do to get that team motivated? And we can do this by giving teams if they're successful. I don't just give them money, but give them opportunity. Bigger roles, chances to work on the better projects. Allow them things like to go to conferences. I remember sending my programmers to a Eiffel conference one time. Eiffel is kind of a weird language, a very fringe language, a very interesting language, but it's never been a mainstream language. And I sent my C++ programmers to an Eiffel conference many years ago. They were all totally baffled. But they all came back kind of energized about what they'd learned. We were never going to use that language, but it taught them new ways to think about things. They got them excited. Do brown bags, little seminars in the office, things like this to pump energy in. Keep a team motivated. I want to give one example. We'll wrap this up. One example of pumping energy into a system. This to me is a very famous example, a very old one, but it had to do with the email. Actually, it wasn't an email. It was a memo. Bill Gates didn't use email back in 95. He did. This is a memo. This is back when Microsoft realized there was something called the Internet out there. And so Bill Gates sent this message to his employees, the Internet is a tidal wave. It changes the rules. It's an incredible opportunity as well as an incredible challenge. I'm looking forward to your input on how we can improve our strategy to continue our track record of incredible success. Pretty bland email when it really comes down to it. Bill Gates did not deliver some, whoa, we got to go take over the Internet message. This is a pretty bland email. I can imagine any boss I've ever had writing that email. There's nothing amazing to that. But this was the email or the message, the memo that really turned Microsoft around, got the Internet Explorer team started, things like that. Got people focused on the Internet. So this was a very energizing message that was sent around Microsoft, even though when you read it, really not much there. Just a memo saying, hey, you think about it. I'm looking forward to your input, you guys own the problem, figure this out. Bill Gates was not laying out the strategy. He was very good at this. He wasn't saying, I got the answers here. He was asking for the answers from his entire company. So self-organization, evolution, subtle control. Remember containers, differences, exchanges, we exert influence on our teams. None of this is evil. We do it as a way to influence our teams. Last things, you guys have seen this, if you've been here before, there's just a website we've got for video training. Want to mention that because we've only had it up for a month or so, so we're trying to get interest in this. There's my contact information, my website up there. Again, you can download this presentation, all the other presentations from today. In fact, you can download any presentation I've ever given at a conference on that website. Just go to mountgoatsoftware.com. Feel free to email me questions later. I'm always happy to talk about this, so you got my email up there. I can back and teach classes through our host here through program of the team every three months. So if you're interested in Scrum, I teach classes on that every three months here. We'd love to have some of you in those classes. Last thing, please do as you get a chance when you're walking out, drop one of the little colored squares in the review box out there. The conference is appreciates that as do I. Thank you guys very much. I appreciate you being here. Have a good weekend. Bye-bye. Thank you.
 What a busy week.  NDC is always such a busy week.  I appreciate you guys being here so close until the end.  We got one more session in the event today.  So thank you for being here and the next to last.  I appreciate it.  We're going to talk about leading a self-organizing team.  Here's the answer.  Buy pizza, get out of the way.  We're done.  No?  There's more to it than that.  There's more to leading a self-organizing team than just  buying pizza and getting out of the way.  So that's what we're going to talk about.  Our agenda, three things.  I want to talk about self-organization.  I want to talk about subtle control and how we can exert  subtle control over how a team self-organizes.  We're going to talk about three things called containers,  differences, and exchanges.  These are things that you can use to influence, exert,  subtle control over how a team self-organizes.  And we're going to talk about team evolution, how a team  evolves over time.  So that's our agenda.  So self-organization.  Self-organization does not mean that a team gets to pick  their own goal.  Self-organization, self-organizing, is the proper  term for what scrum teams do, what agile teams do.  Some people will call it self-directed.  That's not it.  A self-directed team gets to pick their own goal.  Some people will call it self-managing.  That's not it.  It's not self-managing.  It's self-organizing.  And teams organize in response to a challenge.  So self-organization is a response to a challenge.  So self-organization responds to a challenge defined by the  product owner.  Think about cars on the highway.  Cars on the highway self-organize.  They figure out who gets in what lane, who goes at what  speed, who goes how close to somebody else.  There's no police officer saying, you go next, you go  next, why don't you go in that lane.  Cars self-organize.  So self-organization responds to a challenge.  So what we do is we set up the right organizational  environment, and then teams respond to that.  Meaning we are going to be able to exert influence in a good  way over how a team self-organizes.  Now self-organization occurs in what are called complex  adaptive systems, or CAS.  And I've looked up some definitions of CAS.  Here's kind of the ones I like.  Where a complex adaptive system is a dynamic network of  many agents.  It didn't say people.  Agents could be individuals.  Agents could be groups.  And they're acting in parallel, meaning they're both acting  at the same time.  And they're acting and reacting to one another.  So a programmer is reacting to what a tester finds.  A tester is reacting to how well the programmer did their  code.  We're acting and reacting to one another.  In a complex adaptive system, there is no centralized  control.  There's not that police officer saying, you go next, you go  next.  So the control is decentralized.  And the overall system behavior is not the result of one  really smart decision maker, but it's the result of a bunch  of small decisions being made, remade, adjusted.  And this is how teams behave, or should be allowed to behave.  A few examples of complex adaptive systems.  Things like ant colonies, beehives, flock of geese, a  family preparing a meal.  You got little kids.  You might have the mom or the dad assign tasks to the little  kids.  But a more mature family will figure out how to do this.  Us right now, we self-organized.  You had to figure out where to sit.  You had to walk in.  Some of you wanted to sit near the front.  Maybe you forgot your glasses today.  You want to sit here.  A few other people wanted to sit near the door in case I get  real boring.  You had to figure out where to sit.  That's self-organization.  I used cars on the highway.  Software teams, complex adaptive systems.  Now, in this type of a situation, subtle control over a  team over a complex adaptive system is not evil.  We can use simple rules or incentives to guide behavior.  We have rules about which side of the highway to drive on.  I don't feel like that's some evil rule perpetrated on me  by my government.  I think a lot of other things are evil and perpetrated on me  by my government.  But not rules about the highway.  That's a pretty realistic thing.  I don't care what side of the highway we drive on.  For me, it's pretty natural to drive on the right side, like  you do here.  But the English, India, going on the other side of the road,  OK.  I get it, kind of a random decision.  I don't really care.  Certainly used to one by now, so I don't want to change it.  But I understand why different countries do different things.  Bio teams, teams in biology or nature, their rules are  provided by their environment.  These are born with a desire and innate desire to produce  honey.  So these rules or incentives to behave are OK.  And managers, leaders, scrum masters, product owners can  add rules, can add incentives on top of a team to help that  team.  We don't do it because we're evil, manipulative jerks.  We do it to help a team behave the best they can.  I taught a product owner class the last two days, a scrum  product owner class.  I got down there the very first day around in the hotel,  across the street.  I got there around 6 o'clock the first day to make sure the  tables were set up exactly how I wanted them.  I taught a class a couple days before the room was a little  too big.  I didn't like how the tables were.  So for the product owner class, I rearranged the tables.  I sat a certain number of chairs at each table.  I didn't do that to manipulate the  attendees of that class.  I did it to help create the best environment we could.  I couldn't do anything here.  These chairs are where they are.  So I didn't get a chance to really exert subtle influence  over you.  But I did over that class, not because I'm evil, but because  I wanted to create the best experience we could.  So subtle control, not evil.  I think certainly can be, but that's not the type we want  to impose.  Now, sometimes I feel alone in making this statement.  So I want to get myself a little bit of support.  Here's a little bit of support from a guy named Phillip  Anderson.  He's a scientist, business writer, and  scientist.  And I'll share with you his quote.  He said, self-organization does not mean that workers,  instead of managers, engineer an organizational design.  It does not mean letting people do whatever they want to do.  It means that management commits to guiding the evolution of  behaviors that emerge from interaction of independent  agents instead of specifying in advance what effective behavior  is.  So management doesn't decide it has to be this way.  Management commits to guiding the evolution of a team,  helping that team be continually better and better,  have that team evolve to fit their environment.  So that's management's commitment to help a team evolve  to better fit their environment.  Here's another quote.  This is from the very first Scrum article.  The very first article on Scrum is old.  It came out January 1986.  And here's a quote from that article.  It says, although project teams, Scrum teams, are largely  on their own, they are not uncontrolled.  Management establishes enough checkpoints to prevent  instability, ambiguity, and tension from turning into chaos.  Scrum teams are often talked about acting on the edge of chaos.  They're going so fast, they're just about to go out of control.  It says, at the same time, management avoids the kind of  rigid control that impairs creativity and spontaneity.  So we want a team going so fast, they're almost going to go  out of control, but they're going just slow enough to be in  control.  And so that's where management sets up enough checkpoints to  make sure that happens.  Last quote to support this claim.  This is from a 1990 book on Scrum.  Bet you didn't even, or book that referenced Scrum, it wasn't  all about Scrum, but it had a chapter on Scrum.  Bet you didn't know there were all these old references to  Scrum, 1986, 1990.  And this one says, to be sure, control is exercised over the  team.  But it is subtle, and much of it is indirect.  So we're talking about exercising this indirect control.  So I'm not talking about being manipulative, deceptive,  sneaky.  I'm not doing anything like that.  That's not what it's about.  Nothing I want to advocate here needs to be done in secret.  But there may be reasons why I don't broadcast my reasons to  a team.  Let me give you an example.  I had a team whose decision-making style I didn't like.  I felt like they were rushing into decisions.  I don't know if they were making good or bad decisions, but I  felt like they were making them too quickly.  And so I put somebody else on the team who I knew had a more  methodical decision-making style.  He loved to debate everything.  Kind of honest, to be honest, he kind of debated things a  little too much.  But I knew that having him on that team would slow them down.  Because he'd ask a lot of questions.  Have we considered this?  What if we did this?  Maybe we should try it out.  Let's do a little bit more research.  And so he would be a big counter to that team that was  going too fast.  Now, I didn't want to go to them and say, I feel like  you're rushing into decisions.  So I'm putting this guy on your project.  Because that would have kind of defeated the purpose.  Two years later, if we were out over beers one night, they  say, hey, why did you put him on our project two years ago?  I would have been happy to share the reason.  But sometimes sharing the reason in advance can  defeat the purpose.  So I'm not necessarily going to broadcast why I do every  intervention with a team.  But I'm not ashamed of those interventions.  And after the fact, I'd be happy to share it with the team  why I did it.  But again, sometimes by telling the team in advance, I  might defeat the purpose a little bit.  So not sneaky, not deceptive, but I still may not want to  broadcast everything.  So let's start out by looking at self-organization, subtle  control.  Actually, that's what we just did.  I want to back up here.  We did that.  I want to go into containers, differences, and exchanges.  Now, the idea of containers, differences, and exchanges  come from a PhD paper that was done by a woman who was  studying what is required for teams to self-organize.  And she was studying both human teams and bio teams, ants,  bees, things like that.  And she said that for, and I've referenced her paper down  here at the bottom, for a team to self-organize, they need  three things.  They need containers, differences, and exchanges.  I need all three of these things.  Now, a container is a boundary within which self-organization  occurs.  I said a moment ago, we self-organized in this room.  They and that other room over there self-organized.  Their self-organization didn't influence ours.  But your individual self-organization influenced  each other.  I'm looking at one row up here, and it's great because we've  got a person in every other seat.  So where somebody sat who influenced one of the experts  is that I want two arm rests.  Don't blame people.  So how individuals sat down influenced the others.  How somebody sat in a room over there?  No influence over us because we're in a different container.  So some containers are physical.  Some containers are more kind of conceptual.  Your project is a container.  Your role, you are database people.  Your role is a database person.  You're a member of the database developers at your company.  You're a member of the JavaScript developers.  Your nationality.  I'm American.  I'm actually one fourth of the region.  I love my one fourth Norwegian-ness.  Thank you, grandmother.  But my nationality is kind of American.  A number of people here have different nationalities.  And if you were over in the US, you'd  be like my grandmother was when she was there.  She hung around with all the other Norwegians  in San Francisco.  You have people that move to another country.  It's amazing how they all find each other.  That's because of our boundaries that brings us together.  Differences.  We need differences.  Pretty easy to have differences when we're talking  about humans.  We're going to have differences in terms of knowledge.  You know some things better than I do.  I know other things better than you do.  We've got different levels of knowledge.  That's a difference.  Sometimes we have differences in our experience  with the company.  You know this domain really well.  You've been with our company for 10 years.  I got here 10 days ago.  We have differences in terms of gender, differences in power.  One of you might be a vice president of the company.  I'm the intern.  There's a power difference.  So we need differences in order to self-organize.  If everybody were the same, self-organization  would be kind of random.  We wouldn't do it.  There'd be no difference.  None of us would care.  Last thing that we need for self-organization to occur  are transforming exchanges.  Transforming exchanges are conversations.  You and I go talk to our product owner.  Our product owner tells us about a client visit  she did.  We leave that conversation excited about how many people  are going to buy our product.  That was a transforming exchange.  We leave motivated.  You and I go talk to our architect.  And we leave that conversation with our architect educated.  That's a transforming exchange.  I go down to the payroll department  and pick up my paycheck.  That's a transforming exchange, my favorite exchange.  So we need these three things, containers, differences,  and exchanges for self-organization to occur.  We didn't have those things.  We didn't have anything in common, like physical container.  If we were all equal people, no difference whatsoever,  impossible with people.  If we never interacted, we wouldn't self-organize.  I'm not interacting right now with somebody out on the street.  So I need some sort of exchange.  The way we can use this model, the container difference  exchange model, is we can exert influence  by altering these things.  You can change the containers that are on a project.  Change the team's physical space.  Change their differences.  Move somebody onto the project.  I just gave you an example.  I moved a guy onto the project to add  a different decision-making style.  I was trying to create a bigger difference in personality.  It was amplifying the difference.  That will change how a team will self-organize.  Introduce a new exchange.  So what we can do is we can exert influence  by altering a team's containers, differences, or exchanges.  Now, when you do this, you do not know how a team will respond.  I love going into teams and getting  them to start doing something like, let's say, pair programming.  And I have a pretty good idea, because I've  been doing it for years, how a team will respond to pair  programming.  After I've met that team, I know them a little bit,  I can develop an opinion about how they'll  respond to pair programming.  But I don't know that.  I don't know how they're going to respond.  So I'm taking an educated guess.  And then I consider this to be kind of a nudge.  I kind of poke and prod.  I nudge the group, hoping that introducing this  will fix or improve some aspect of their situation.  But I never know for sure.  They're educated guesses.  So we alter containers, differences, or exchanges.  Not because it's just plain fun.  We do it to improve the team, constantly trying  to help a team get better.  I want to give you a couple examples.  I've given you a few already, but here are a few more.  For containers, enlarge or shrink the team.  Make the team bigger or smaller.  That will change the container.  Enlarge or shrink the responsibility of the team.  Tell a team they're not responsible just  for developing the thing, but for getting it deployed out  in our data center.  That's a change in responsibility.  That's a changing container.  I don't know how a team will respond to that.  I can take educated guesses, but I'm not 100% sure.  Change team memberships.  Move him off her on.  Change the team members.  Create new teams or groups.  Instead of the three teams we've got,  let's create four smaller teams.  That's a change in container.  So we can do all those things, and we  do it to help a team improve.  Differences.  Amplify or dampen the differences.  Tell a team to change their decision-making style.  Or just as a scrum master or coach, manager for that team,  you change how they're making decisions.  Do it by the questions you ask.  I love asking teams hard questions.  When you ask a team hard questions,  you will find dissenting viewpoints.  You will bring out the differences they have.  What three alternatives did you reject  before you chose this approach?  What's the worst thing that could happen  if we made this decision?  How would we recover if this decision didn't work out for us?  If you ask questions like this, and there  is kind of underlying dissent with the direction  they're headed, that will come up.  Somebody on the team will say, well,  I've been really worried about that.  I'm glad you asked.  Here's what I think might happen if we make this decision,  and I'm worried about it.  I'm going along with the team, but here's  what I'm worried about.  So you can amplify the differences,  make them bigger by asking hard questions.  You can dampen the differences.  Stop asking those questions if you need a team  to get to consensus sooner.  These are communications that a team has.  Encourage communication between teams.  Find out who's talking that shouldn't be,  or find an exchange that's happening  that you don't think is necessary,  and try to get a team to stop that exchange.  Add or remove people to conversations.  Maybe your team does a design review.  Add somebody to that design review.  Here's an example.  You might not think this was a very agile thing to do.  In this talk, isn't necessarily agile.  We're just talking about self-organization.  But if you know me, you know I'm kind of into agile.  So you might not think this is a very agile thing to do.  I had a particular team, and I told them  all of your decisions, all of your key architectural decisions,  I want you to run by this one really senior developer  in the company.  His name was Todd.  And I said, I want you to run all your hard technical decisions  by Todd.  I went to Todd, who's an architect, not on that team.  And I told him, I said, don't change many of their decisions.  I really just mostly want you there to scare the team.  If they know they have to come present to you,  they're going to think through their architecture better,  and they'll come to you prepared with good decisions.  If they are about to make a big mistake,  I absolutely want you to stop them  from making that big mistake.  But if it's just a small mistake,  or if it's just the thing where you disagree with how  they're going, but they're going to be successful their way,  don't change them.  Let them own that decision.  That's fine.  I said, but do stop them from big mistakes.  So I put this new exchange in place.  It probably sounds kind of unagile.  I took a team that was a nice agile team,  and I had them get approval on their design decisions  from some outside guy, kind of a non-agile.  I did it for their good.  I did it to make them pause, reflect,  think harder about decisions they were making.  I didn't do it just because I wanted to slow them down.  I didn't do it just because I liked this Todd guy  and wanted reviews to go through him.  I did it to help this agile team.  So an example of introducing an exchange.  Containers, differences, exchanges  are things that we can control.  We can alter.  We can manipulate to help a team do better on their project.  What I'd like to do, what I'd like to have you do,  is a little exercise along this lines.  So here's what I've got.  Here's our exercise.  I've got the next couple slides.  These are the things I handed out.  Hopefully you got one.  If not, we can get more passed around.  What I'd like you to do is to think about the cases  on the next couple pages, just in little groups.  Just kind of turn around, talk to a couple people next to you,  and talk through one of these cases  and decide what would you do in that case.  If you don't have the handout, I'll just  leave one of them up on the screen.  You can talk about the one on this, talk  about the two that will be on the slide.  Let's do number one together here.  You've got a team that's got four programmers, two testers,  database guy, and you.  The programmers and testers aren't working well together.  Programmers work in isolation until two days  are left in the iteration.  Then they throw the code over the wall to the testers.  Anybody got an idea what would be a good thing to change  in that situation, suggesting for what you might do there?  Yes?  Change how they're seated, right?  Move people around.  Would that be a change in container?  Difference or exchange?  The two first ones?  Containers and differences?  Yeah, to me that would be a change in container, right?  And it's probably then immediately going  to lead to additional differences, right?  It's going to get people who are different talking  to each other, right?  Another good example, I could introduce the idea of pairing.  Have a programmer and tester pair.  They're not doing it on their own.  Let's just decide we're going to do this.  As a scrum master for that team, I might say, hey guys,  let's try cross discipline pairing.  We're going to have programmers and testers pair early on  to get this going.  We might do that for a couple of sprints,  and they'll realize it's a good way to go.  I don't have to mandate it anymore, right?  Is that a difference in container?  Differences or exchange there?  Exchange?  Yeah, I'd go with exchange on that one.  Now I see some people going, ooh, I don't know, right?  You're right.  A lot of times things will cross boundaries.  They might be two of these things.  That's fine.  When you have something, and you're looking at this going,  wow, this is really a container and an exchange,  that's probably a pretty powerful intervention,  as opposed to something that you can look at and go, wow,  that's a pure container intervention.  Something that's really kind of two things,  pretty powerful intervention.  That could be good or bad.  Maybe you want a powerful intervention.  This team needs to be kind of nudged in a powerful way.  Maybe they need just a small nudge.  Maybe you can find something that's just a difference  you introduce.  So what I want you to do, I'm going to put these up here.  Two's up here, three, four.  You've got to use them to hand out.  If you didn't get one of these, I'm just  going to leave the last one up here.  Just take five minutes.  Pick one or two of these.  Talk about it.  What would you change?  What would you have this team do differently?  And is that a change in container, difference, or exchange?  Talk about that for five minutes.  OK.  Let's talk about this.  I'm just going to pick one on each page.  So we talked about one on the first page.  Which one you want to talk about here?  Anybody talk about three or four?  You got a tip for me on this one?  Anybody do three or four?  No.  Let's talk about it then.  Now, what would you do on number three?  You got a team consistently under committing  during sprint planning.  They finished their work, but it didn't seem like much.  Product owner hasn't complained yet,  but you're worried as the coach, you're  worried that the product owner is going to complain.  What might you change here?  Yes?  What would you change for this in the new container?  What would you do in there?  Where's the results of the data here?  That's a good point.  Is this something that's been persistent?  I'm looking at the way I wrote this,  and I said consistently under committing.  So I'm assuming they've been doing it for a little while.  What would you think to change?  Well, usually what happens is the pulse on the track  will be really consistent in the last four hours.  OK.  So I encourage them to take on the right advice.  Might have been a spectacular fail your five or six sprints  ago, right?  And it's been consistent since then.  What else?  I'm going to bring a senior that consistently underestimates  the work.  OK.  Bring a senior onto the team who consistently underestimates.  That could do it, right?  Now, that would be which?  Get some tension on the team, right?  Team should have some sort of tension.  We don't want people who always do the same thing.  A lot of times when we do have a team that under commits  or over commits, it's not necessarily  that we got a bad team or bad people on the team.  We just have kind of a bad mix, right?  And we change that up.  We bring a different person onto the team.  Just swap two people out.  I'm not saying we bring anybody better on or anybody worse.  It's just somebody different, right?  Somebody different will have a different approach to things.  We bring on one of those people who's just always  really enthusiastic.  We can do more.  We can do more.  Yeah, let's take this on, right?  Rest of the team is nervous, but this guy's got an outgoing,  let's do it, personality.  Maybe they start to try one more, right?  And maybe in this case, if they really are under committing,  might be a better thing to do.  It may not be the team's fault.  It may be that the backlog isn't groomed.  Is it really ready to go?  In which case, I might want to do what?  I want to introduce a meeting to make sure the backlog is groomed,  is prepared.  That would be a new exchange, right?  Let's introduce a new meeting into our process  where we make sure the backlog is well groomed  before we do something, before we start a sprint, right?  Let's just do one more, something on the last page here.  Let's do number five.  We got Jeff, a domineering senior developer.  During iteration planning, the team  defers him on every decision, even though he's a horrible estimator.  You notice that Glantz is the other team members exchange  wherever he suggests very low estimates.  What do you want to do about this guy?  Yes.  Do what?  Yeah, play poker, play planning poker, estimating poker, right?  One of the nice things with estimating poker or planning poker  is everybody turns over a card at the same time, right?  If everybody turns over a card at the same time,  we at least get to see people's independent opinion  before this guy gets a chance to dominate the meeting, right?  That would be, if I look at that as a way of introducing  a new, or amplifying the differences, right?  So that'd be a new difference to me.  We've already got an exchange going.  I already got an estimation meeting of some sort.  We're going to change our technique.  This would be a way of amplifying the differences  between team members by having this first round of planning  poker unbiased by any one estimator, right?  So to me, the container difference exchange model  is a way of thinking through problems.  You have a problem with the team.  You're trying to introduce a way to solve that problem.  Thinking through the containers, differences,  and exchanges can help address that.  I can't tell for sure.  Is the microphone on?  It's working.  OK.  I wasn't hearing it, so I wanted to make sure.  All I hear is this other group.  So the last thing I want to talk about  is influencing that team over time.  Evolution.  Self-organization is not a one-time thing.  We don't self-organize and we're done.  Self-organization is a path, right?  And the team is never done.  You can't put self-organization on a Gantt chart  and say, boom, we're done.  We've self-organized.  It's a continual response to a challenge.  So as the team self-organizes, you  can continue to re-exert influence.  Always trying to help that team be the best they can.  Again, I consider these things like nudges.  You're pushing the team in certain directions,  and you never know for sure how they're going to respond.  I want to share with you one other quote.  This is from the same guy we looked at before,  Philip Anderson.  He said, self-organization proceeds  from the premise that effective organization is  evolved, not designed.  You can't sit down up front and go, here's  what we should look like.  You have to evolve there.  He says, it aims to create an environment in which success  and growth, rights, browins, podemos  solve a metric amount of problems that  lead to  We're not talking about turning people into marathon runners with fitness.  We're talking about fitness for their environment.  We're talking about a team that fits their environment.  And so the team evolves to fit their environment even as their environment changes.  And they say this happens not because management has mastered the art of planning and monitoring  workflow.  So management sets up an environment, management encourages change, management pushes teams  to get better.  So we are talking about things that you hear as scrum masters, product owners, project  managers, just plain influential people in your organization can do to help that team  evolve.  Now, if we think about evolution, evolution is a result of three things.  Variation, selection, and retention.  All right, so think about a giraffe.  In a giraffe, variation occurs when the first giraffe suddenly develops a long neck.  Mutation refers to that long neck turning out to be a good thing.  And retention occurs when that mutation, that long neck is passed on.  So what we're looking at here is allowing teams to vary, allowing them to try new things.  Having a mechanism that lets us determine which of those things they tried was good.  Which of those things worked out and therefore should be retained by other teams.  So our job in management is to help create this type of environment where we can experiment,  where we can retain, where we can pass on the successful items.  Here are seven things you can do to influence evolution.  All right, from selecting the environment down to energizing the system.  So we're going to walk through.  Yeah, absolutely.  Sorry, it's hard for me to see things.  I got, oh, I got this noise.  I got a big white.  So.  I got a lot of team members I wish would go away.  So yeah, I think it does mean that.  I mean, what we're talking about here, you know, kind of Darwin's term, survival of  the fittest, right?  We're talking about the teams that do the best in our environment, should be propagated,  they should be continued, and practices that aren't working should start to fade away,  right?  So I'm not necessarily talking about, you know, teams evolving and teams going away.  I'm talking about practices with those teams, things like that.  So if a practice is not working and a new practice is discovered, right, testing early  rather than testing late, yeah, I want the testing late practice to go away as we learn  the benefit of testing early.  So yeah, I do.  Good point.  So here are seven things.  We're going to talk about each of these seven, right?  Selecting the external environment.  What we're after here is defining the environment for your team.  And this is more than just your physical office environment, right?  This is more than the type of chair you've got, right?  To some extent, it's what business we're in.  Now you probably can't influence that, but somebody can in the organization.  This has to do with your company's approach to innovation, right?  Some companies are innovators.  Others are fast followers.  I'm not going to judge and say one's better than the other, right?  Being a fast follower, Hewlett Packard, right, known for making printers, right?  They're known as a fast follower, right?  They're generally not the first one to come out with the idea, but they follow and then  they do it better than anybody else in terms of making it a long-term product.  What's our corporate culture towards mistakes, right?  Do we penalize somebody when they make a mistake?  Chop their head off, right?  What type of projects are worked on?  Which type of projects are praised in the organization?  Do we try to do too many projects at once?  All of these things have to do with our physical environment, our external environment, right?  The environment in which the projects are occurring, right?  I've got multitasking and focus, right?  What do we like to do here?  Do we want to have people focused, get one thing done?  Or, we want to have those companies where everybody's on eight projects, right?  I was with a client last year.  I was supposed to be there for a week.  I did one day and I left, right?  I was there as teaching a class and I looked up too many times during the first day and  I couldn't make eye contact with a single person in the room.  There's like 30 people in the room, every one of them, every time I looked, banging away  on their laptop, right?  And then they're asking me questions every now and then like, should a Sprint Master  do this during the daily Sprint, right?  It's like, sorry, those aren't even the right words, right?  They're not getting it.  And so this was a culture where everybody was expected because the boss did it.  Everybody was expected to just be banging away on your laptop all day during every meeting.  I went to the boss at the end of the day and said, you're not going to be successful.  I don't want to be a part of this, right?  I didn't bill him for the one day I was there and I flew home, right?  So what is our company expectations towards multitasking, towards focus, right?  As leaders in the company, right, we can define what is good performance, right?  What makes a successful employee in our company, right?  You've all been in part of companies or in companies where there's some boss who praises  the hero, who worked really hard to solve a problem that that guy caused himself, right?  I've seen that way too many times, right?  This guy causes a crisis, then he works hard to solve the crisis and he gets praised, right?  Isn't this guy a hard worker, which should all be more like him, right?  What type of message does your company send in terms of long and short-term performance,  right?  I'm sure there's a company who had people planned to come here today, come here this  week, and then last week they decided, uh-oh, we're too busy.  Let's cancel the person's attendance at NDC.  I guarantee somebody was in that position.  None of you, because you're all here, right?  But somebody had their attendance here canceled at the very last minute.  What type of message does that send employees in that company in terms of the long-term  versus the short-term?  We don't want to invest in this, uh, this employee over the long-term because the short-term  is such a crisis, right?  Not a good sign to send, right?  We can manage what's meaningful in our company, right?  What messages do we respond to, right?  What messages do we hear?  What signals danger in our environment, right?  Think about ants responding.  They follow trails, right?  There's food over here.  They follow a trail, right?  Think about the messages that you can push to your team about what's valuable.  What messages can you push that are good?  I want to share you one story about messages in a company where I worked.  I worked in this company where we were a startup.  We had about 200 employees at the time, and we were about to turn profitable.  We were just about to do it.  If things went well this quarter, we would be profitable.  And we were a public company.  We had gone public earlier in the year.  And if we could be profitable, that was going to be huge for our stock price.  And so the company president has us all come in to a company meeting, and he talks about  this, and he talks about how important it is to keep costs down.  Please do not go on a business trip this quarter if you can put it off.  Please don't buy office supplies this quarter if you can put it off by all you want next  quarter.  But let's try to get profitable.  It is going to be so close.  And while we're having this meeting, he tells us that he's got the janitors going around  to all of the toilets in the building, and they are replacing the nice, comfortable,  two-ply toilet paper with one-ply toilet paper.  Now, I'm sure this cost him money to replace whatever toilet paper we had with a lower-quality  toilet paper.  But he said every time we were in the bathroom, he wanted us thinking about company profitability.  Very ridiculous, but man, what a way to make his point.  What a way to make his point.  I remember this is 20 years ago, and I remember this as though I were still there.  I was working with another company.  They were trying to get me to come in and do some consulting, and I pretty much decided  I'm not going to do it.  I'm just going to kind of finish out this kind of day where I'm helping them out for  free, and I'm not going to come back.  And I'm waiting for the general manager to come by, and this vice president who's kind  of been pushing me around different places all day, said, I can't wait for you to meet  our general manager.  He is so great, and he talks about how this general manager counts the cars in the parking  lot every day at 5 p.m.  Now, 5 p.m. is kind of an early but normal quitting time in the U.S. A lot of people  may be there until 5.30, maybe 6 o'clock.  And so this guy goes, because they don't come in until later, and this guy goes out at 5  o'clock and counts the cars in the parking lot.  And so I said to the vice president who's got me there, I said, wow, that's great.  He counts the cars.  Then what does he do?  He goes around and finds all the people who are still here at 5 and send them home because  they've worked so much?  He said, no, no, no, we want people here later.  And so this had become part of their company culture.  This was horrible that this vice, this general manager was going to walk around and count  the cars.  And he did.  He had a chart.  He had a little graph in his office, how many cars were in the office or in the parking  lot every day at 5 p.m.  He was fired about a year later.  And the division of the business was sold about six months after that.  So what type of stories are told in the company?  What has meaning in the company?  Choosing people is a management responsibility.  Who is on the team is going to influence how they self-organize.  And so when we choose the team, we can do things like adjust team size, location, background,  experience, the decision-making style of people, the gender of the people on the team.  What's the gender up if that's going to be good, right?  The motivation.  People who are skeptical versus people who are just very enthusiastic.  I remember one guy I had on a team.  He was just kind of a mediocre programmer.  But man, he was good for helping a team come together.  He was the guy that was having people over to his house on the weekend for parties.  He was the one encouraging people to go out for beer afterwards or the new Star Trek movies  out.  Let's go see that.  I was considered this guy to be like glue.  He was one of the highest paid guys in my department because of this behavior that he  had.  Not because he was an amazingly talented programmer.  He was a little above average.  But he was like glue.  He kept a team together.  And I remember having two teams in two different cities that didn't get along.  I put him on one of those two teams so he could help them get along.  And he did.  So think about the people that we put on a team.  So one of the questions that this brings up is should a team have full control over it?  My answer is going to be no.  I do not think the team should have full control over who's on the team.  They should have opinions.  They should have influence.  But it's a management responsibility to select who is on the team.  The very first article on Scrum talks about this and validates me in this opinion.  This is back to a team being self-organizing.  If you give the team total responsibility for who's on the team, it's very possible that  they select team members who are all very similar to one another.  So this remains a management responsibility.  I want to listen to the team.  I want to be very influenced by who they want on the team.  But I'm not willing to give that up as management in the organization.  Because this is one of the primary levers I can pull to help a team self-organize.  So who's on the team?  Up to management.  Totally should be influenced by the team.  But it's a management decision.  Yeah?  Do you think the team should be able to choose their own roles?  Largely.  I do.  So do I think team members should be able to pick their own roles?  Yeah, largely I do.  I don't think that we hired you to be a DBA and you think database stuff is boring all  of a sudden and you'd like to be our new superstar Python programmer even though we don't program  in Python in this company.  No, I don't think you have the right to do that.  But I do want people to help figure out what they want to do.  I do think we should have influence over those things.  But the team still has to respond to the challenge that they're given.  And if the other team members don't want you doing that because they need you doing the  other thing, I think they have influence over that as well.  So I don't think you can just completely change your direction on a team.  The way I like to think of team members is I think of us as team member first and then  JavaScript programmer second or database person second.  But you're a team member first doing whatever you can to help the team.  But you're largely going to stay within some sort of specialty evolving that over time.  Three more things.  Number five here.  It has to do with reconfiguring the network.  I'm not talking about the data network.  I'm talking about the people network, the human network.  Communication paths in an organization.  These can often be more important than the individual people.  How do we communicate?  And you can introduce or remove communication paths.  I talked about having everybody run things by an external architect.  Introducing new communication paths.  So I want to give an example of a distributed team and reconfiguring the network on a distributed  team.  So suppose we have this situation.  Half of our team is here.  Half of our team is back in my hometown Denver, Colorado.  One way to structure those teams would be like this.  We would have an intact team here in Oslo.  Programmer, tester, designer, data.  Everybody necessary here in Oslo.  We have everybody necessary to be a good team in Denver.  And then we just coordinate.  That's one option.  Another approach would be to create what are called deliberately distributed teams.  In a deliberately distributed team, we would set up one team that's half here, half there.  A second team that's half here, half there.  There are advantages to either approach.  If we have an Oslo team and a Denver team, it's entirely possible that we end up with  a little us them mentality.  It's their fault.  No, it's their fault.  If we end up with a team half here, half there.  A second team half here, half there.  Probably not going to have us and them problems.  But we're going to have people doing meetings at weird times of the day.  Phone calls early in the morning from Denver to late in the afternoon here.  There are problems either way here.  So I'm not going to tell you do it the top way, do it the bottom way.  I do it both ways.  Sometimes the top, sometimes the bottom.  But this should be a thing that you can consider in terms of how are you going to structure  that team.  I've been involved in a lot of acquisitions where one company's acquired the other than  I get involved to help kind of fix the development problems at the acquired company.  When we do that, I far prefer the bottom approach.  Because if one company acquires another, I want to get those teams working well together  and setting up separate cities.  Kind of desirable in a lot of ways, but not when there's an acquisition.  Because we've got kind of an us and them thing going already.  So top or bottom, either one can work, be aware there's pros and cons.  Number six of seven.  Evolved vicarious selection systems.  So we talked about variation selection retention.  One of the things I would love to do is have 20 teams in our company.  Have those teams run for five years and at the end of five years, figure out which one  of those teams created the most profitable products.  And then take that process that that team used and replicate that to all other teams.  The problem with that is it just took us five years to find out which one of those teams  was more successful.  So what we'd like to do is create vicarious alternative selection systems.  A selection system that doesn't take an entire generation of giraffes to select long necks.  I want to find something that will help us create those mutations and retain them more  quickly.  So I don't want to trust the marketplace because it's going to be too long of a cycle.  So one of the things that you can do here is create alternative selection systems.  Google's 20% policy.  Everybody's familiar with this.  Where Google tells people that you can spend 20% of your time on any project you want.  What do you think that tells Google when they see a whole bunch of employees flocking to  work on a certain project?  That is a really good indicator that that project has captured people's attention.  And one of Google's premises for years has been that their engineers are pretty much  their audience.  Right?  They're after people like themselves.  Right? They're building stuff for people like themselves.  So if their engineers all want to work on a new system, that system is likely to be  profitable and they should let those people work on that system.  So what we want to do, we want to create these approaches that let us monitor what's  successful and select it without having to wait for entire market cycles to indicate  this.  The last thing that we can do is to pump energy into the system.  In the U.S., overtime is a big issue.  And people are always trying to get people to work more overtime, work longer hours,  things like that.  And I've been a vice president in four different organizations and I've never been after overtime  from my people.  I was never really trying to get people to work 60 and 80 hours a week.  What I was after, on the other hand, was having my team members go home after eight hours  mentally exhausted.  They had left it in the office.  They were tired.  Did not want to see a computer when they went home.  They put so much energy into the day they were done.  So what I'm after is people's energy, not just hours.  And so what we can do as leaders is pump energy into the system.  And we do that by giving teams an igniting purpose.  What ignites a team's passion?  Sometimes called a clear, elevating goal.  What can we do to get that team motivated?  And we can do this by giving teams if they're successful.  I don't just give them money, but give them opportunity.  Bigger roles, chances to work on the better projects.  Allow them things like to go to conferences.  I remember sending my programmers to a Eiffel conference one time.  Eiffel is kind of a weird language, a very fringe language, a very interesting language,  but it's never been a mainstream language.  And I sent my C++ programmers to an Eiffel conference many years ago.  They were all totally baffled.  But they all came back kind of energized about what they'd learned.  We were never going to use that language, but it taught them new ways to think about  things.  They got them excited.  Do brown bags, little seminars in the office, things like this to pump energy in.  Keep a team motivated.  I want to give one example.  We'll wrap this up.  One example of pumping energy into a system.  This to me is a very famous example, a very old one, but it had to do with the email.  Actually, it wasn't an email.  It was a memo.  Bill Gates didn't use email back in 95.  He did.  This is a memo.  This is back when Microsoft realized there was something called the Internet out there.  And so Bill Gates sent this message to his employees, the Internet is a tidal wave.  It changes the rules.  It's an incredible opportunity as well as an incredible challenge.  I'm looking forward to your input on how we can improve our strategy to continue our  track record of incredible success.  Pretty bland email when it really comes down to it.  Bill Gates did not deliver some, whoa, we got to go take over the Internet message.  This is a pretty bland email.  I can imagine any boss I've ever had writing that email.  There's nothing amazing to that.  But this was the email or the message, the memo that really turned Microsoft around,  got the Internet Explorer team started, things like that.  Got people focused on the Internet.  So this was a very energizing message that was sent around Microsoft, even though when  you read it, really not much there.  Just a memo saying, hey, you think about it.  I'm looking forward to your input, you guys own the problem, figure this out.  Bill Gates was not laying out the strategy.  He was very good at this.  He wasn't saying, I got the answers here.  He was asking for the answers from his entire company.  So self-organization, evolution, subtle control.  Remember containers, differences, exchanges, we exert influence on our teams.  None of this is evil.  We do it as a way to influence our teams.  Last things, you guys have seen this, if you've been here before, there's just a website we've  got for video training.  Want to mention that because we've only had it up for a month or so, so we're trying to  get interest in this.  There's my contact information, my website up there.  Again, you can download this presentation, all the other presentations from today.  In fact, you can download any presentation I've ever given at a conference on that website.  Just go to mountgoatsoftware.com.  Feel free to email me questions later.  I'm always happy to talk about this, so you got my email up there.  I can back and teach classes through our host here through program of the team every three  months.  So if you're interested in Scrum, I teach classes on that every three months here.  We'd love to have some of you in those classes.  Last thing, please do as you get a chance when you're walking out, drop one of the little  colored squares in the review box out there.  The conference is appreciates that as do I.  Thank you guys very much.  I appreciate you being here.  Have a good weekend.  Bye-bye.  Thank you.
Mike_Cohn_-_Leading_a_Self-Organizing_Team_0_839.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_840_887.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_888_1595.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_1596_3419.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_3420_5111.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_5112_6395.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_6396_9623.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_9624_11111.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_11112_11723.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_11724_12179.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_12180_12515.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_12516_12863.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_12864_15371.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_15372_15455.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_15456_15503.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_15504_16043.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_16044_21419.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_21420_23699.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_23700_24911.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_24912_26627.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_26628_30191.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_30192_30791.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_30792_34019.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_34020_34067.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_34068_42011.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_42012_46091.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_46092_48227.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_48228_48491.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_48492_49295.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_49296_49343.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_49344_51191.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_51192_52607.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_52608_54479.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_54480_57995.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_57996_59891.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_59892_65051.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_65052_66959.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_66960_70391.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_70392_71183.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_71184_71987.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_71988_72167.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_72168_74171.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_74172_77339.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_77340_80255.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_80256_82715.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_82716_82967.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_82968_84515.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_84516_84755.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_84756_84803.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_84804_84851.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_84852_84899.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_84900_84947.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_84948_84995.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_84996_85043.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_85044_85091.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_85092_85139.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_85140_85187.png Mike_Cohn_-_Leading_a_Self-Organizing_Team_85188_85224.png
What a busy week. NDC is always such a busy week. I appreciate you guys being here so close until the end. We got one more session in the event today. So thank you for being here and the next to last. I appreciate it. We're going to talk about leading a self-organizing team. Here's the answer. Buy pizza, get out of the way. We're done. No? There's more to it than that. There's more to leading a self-organizing team than just buying pizza and getting out of the way. So that's what we're going to talk about. Our agenda, three things. I want to talk about self-organization. I want to talk about subtle control and how we can exert subtle control over how a team self-organizes. We're going to talk about three things called containers, differences, and exchanges. These are things that you can use to influence, exert, subtle control over how a team self-organizes. And we're going to talk about team evolution, how a team evolves over time. So that's our agenda. So self-organization. Self-organization does not mean that a team gets to pick their own goal. Self-organization, self-organizing, is the proper term for what scrum teams do, what agile teams do. Some people will call it self-directed. That's not it. A self-directed team gets to pick their own goal. Some people will call it self-managing. That's not it. It's not self-managing. It's self-organizing. And teams organize in response to a challenge. So self-organization is a response to a challenge. So self-organization responds to a challenge defined by the product owner. Think about cars on the highway. Cars on the highway self-organize. They figure out who gets in what lane, who goes at what speed, who goes how close to somebody else. There's no police officer saying, you go next, you go next, why don't you go in that lane. Cars self-organize. So self-organization responds to a challenge. So what we do is we set up the right organizational environment, and then teams respond to that. Meaning we are going to be able to exert influence in a good way over how a team self-organizes. Now self-organization occurs in what are called complex adaptive systems, or CAS. And I've looked up some definitions of CAS. Here's kind of the ones I like. Where a complex adaptive system is a dynamic network of many agents. It didn't say people. Agents could be individuals. Agents could be groups. And they're acting in parallel, meaning they're both acting at the same time. And they're acting and reacting to one another. So a programmer is reacting to what a tester finds. A tester is reacting to how well the programmer did their code. We're acting and reacting to one another. In a complex adaptive system, there is no centralized control. There's not that police officer saying, you go next, you go next. So the control is decentralized. And the overall system behavior is not the result of one really smart decision maker, but it's the result of a bunch of small decisions being made, remade, adjusted. And this is how teams behave, or should be allowed to behave. A few examples of complex adaptive systems. Things like ant colonies, beehives, flock of geese, a family preparing a meal. You got little kids. You might have the mom or the dad assign tasks to the little kids. But a more mature family will figure out how to do this. Us right now, we self-organized. You had to figure out where to sit. You had to walk in. Some of you wanted to sit near the front. Maybe you forgot your glasses today. You want to sit here. A few other people wanted to sit near the door in case I get real boring. You had to figure out where to sit. That's self-organization. I used cars on the highway. Software teams, complex adaptive systems. Now, in this type of a situation, subtle control over a team over a complex adaptive system is not evil. We can use simple rules or incentives to guide behavior. We have rules about which side of the highway to drive on. I don't feel like that's some evil rule perpetrated on me by my government. I think a lot of other things are evil and perpetrated on me by my government. But not rules about the highway. That's a pretty realistic thing. I don't care what side of the highway we drive on. For me, it's pretty natural to drive on the right side, like you do here. But the English, India, going on the other side of the road, OK. I get it, kind of a random decision. I don't really care. Certainly used to one by now, so I don't want to change it. But I understand why different countries do different things. Bio teams, teams in biology or nature, their rules are provided by their environment. These are born with a desire and innate desire to produce honey. So these rules or incentives to behave are OK. And managers, leaders, scrum masters, product owners can add rules, can add incentives on top of a team to help that team. We don't do it because we're evil, manipulative jerks. We do it to help a team behave the best they can. I taught a product owner class the last two days, a scrum product owner class. I got down there the very first day around in the hotel, across the street. I got there around 6 o'clock the first day to make sure the tables were set up exactly how I wanted them. I taught a class a couple days before the room was a little too big. I didn't like how the tables were. So for the product owner class, I rearranged the tables. I sat a certain number of chairs at each table. I didn't do that to manipulate the attendees of that class. I did it to help create the best environment we could. I couldn't do anything here. These chairs are where they are. So I didn't get a chance to really exert subtle influence over you. But I did over that class, not because I'm evil, but because I wanted to create the best experience we could. So subtle control, not evil. I think certainly can be, but that's not the type we want to impose. Now, sometimes I feel alone in making this statement. So I want to get myself a little bit of support. Here's a little bit of support from a guy named Phillip Anderson. He's a scientist, business writer, and scientist. And I'll share with you his quote. He said, self-organization does not mean that workers, instead of managers, engineer an organizational design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from interaction of independent agents instead of specifying in advance what effective behavior is. So management doesn't decide it has to be this way. Management commits to guiding the evolution of a team, helping that team be continually better and better, have that team evolve to fit their environment. So that's management's commitment to help a team evolve to better fit their environment. Here's another quote. This is from the very first Scrum article. The very first article on Scrum is old. It came out January 1986. And here's a quote from that article. It says, although project teams, Scrum teams, are largely on their own, they are not uncontrolled. Management establishes enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos. Scrum teams are often talked about acting on the edge of chaos. They're going so fast, they're just about to go out of control. It says, at the same time, management avoids the kind of rigid control that impairs creativity and spontaneity. So we want a team going so fast, they're almost going to go out of control, but they're going just slow enough to be in control. And so that's where management sets up enough checkpoints to make sure that happens. Last quote to support this claim. This is from a 1990 book on Scrum. Bet you didn't even, or book that referenced Scrum, it wasn't all about Scrum, but it had a chapter on Scrum. Bet you didn't know there were all these old references to Scrum, 1986, 1990. And this one says, to be sure, control is exercised over the team. But it is subtle, and much of it is indirect. So we're talking about exercising this indirect control. So I'm not talking about being manipulative, deceptive, sneaky. I'm not doing anything like that. That's not what it's about. Nothing I want to advocate here needs to be done in secret. But there may be reasons why I don't broadcast my reasons to a team. Let me give you an example. I had a team whose decision-making style I didn't like. I felt like they were rushing into decisions. I don't know if they were making good or bad decisions, but I felt like they were making them too quickly. And so I put somebody else on the team who I knew had a more methodical decision-making style. He loved to debate everything. Kind of honest, to be honest, he kind of debated things a little too much. But I knew that having him on that team would slow them down. Because he'd ask a lot of questions. Have we considered this? What if we did this? Maybe we should try it out. Let's do a little bit more research. And so he would be a big counter to that team that was going too fast. Now, I didn't want to go to them and say, I feel like you're rushing into decisions. So I'm putting this guy on your project. Because that would have kind of defeated the purpose. Two years later, if we were out over beers one night, they say, hey, why did you put him on our project two years ago? I would have been happy to share the reason. But sometimes sharing the reason in advance can defeat the purpose. So I'm not necessarily going to broadcast why I do every intervention with a team. But I'm not ashamed of those interventions. And after the fact, I'd be happy to share it with the team why I did it. But again, sometimes by telling the team in advance, I might defeat the purpose a little bit. So not sneaky, not deceptive, but I still may not want to broadcast everything. So let's start out by looking at self-organization, subtle control. Actually, that's what we just did. I want to back up here. We did that. I want to go into containers, differences, and exchanges. Now, the idea of containers, differences, and exchanges come from a PhD paper that was done by a woman who was studying what is required for teams to self-organize. And she was studying both human teams and bio teams, ants, bees, things like that. And she said that for, and I've referenced her paper down here at the bottom, for a team to self-organize, they need three things. They need containers, differences, and exchanges. I need all three of these things. Now, a container is a boundary within which self-organization occurs. I said a moment ago, we self-organized in this room. They and that other room over there self-organized. Their self-organization didn't influence ours. But your individual self-organization influenced each other. I'm looking at one row up here, and it's great because we've got a person in every other seat. So where somebody sat who influenced one of the experts is that I want two arm rests. Don't blame people. So how individuals sat down influenced the others. How somebody sat in a room over there? No influence over us because we're in a different container. So some containers are physical. Some containers are more kind of conceptual. Your project is a container. Your role, you are database people. Your role is a database person. You're a member of the database developers at your company. You're a member of the JavaScript developers. Your nationality. I'm American. I'm actually one fourth of the region. I love my one fourth Norwegian-ness. Thank you, grandmother. But my nationality is kind of American. A number of people here have different nationalities. And if you were over in the US, you'd be like my grandmother was when she was there. She hung around with all the other Norwegians in San Francisco. You have people that move to another country. It's amazing how they all find each other. That's because of our boundaries that brings us together. Differences. We need differences. Pretty easy to have differences when we're talking about humans. We're going to have differences in terms of knowledge. You know some things better than I do. I know other things better than you do. We've got different levels of knowledge. That's a difference. Sometimes we have differences in our experience with the company. You know this domain really well. You've been with our company for 10 years. I got here 10 days ago. We have differences in terms of gender, differences in power. One of you might be a vice president of the company. I'm the intern. There's a power difference. So we need differences in order to self-organize. If everybody were the same, self-organization would be kind of random. We wouldn't do it. There'd be no difference. None of us would care. Last thing that we need for self-organization to occur are transforming exchanges. Transforming exchanges are conversations. You and I go talk to our product owner. Our product owner tells us about a client visit she did. We leave that conversation excited about how many people are going to buy our product. That was a transforming exchange. We leave motivated. You and I go talk to our architect. And we leave that conversation with our architect educated. That's a transforming exchange. I go down to the payroll department and pick up my paycheck. That's a transforming exchange, my favorite exchange. So we need these three things, containers, differences, and exchanges for self-organization to occur. We didn't have those things. We didn't have anything in common, like physical container. If we were all equal people, no difference whatsoever, impossible with people. If we never interacted, we wouldn't self-organize. I'm not interacting right now with somebody out on the street. So I need some sort of exchange. The way we can use this model, the container difference exchange model, is we can exert influence by altering these things. You can change the containers that are on a project. Change the team's physical space. Change their differences. Move somebody onto the project. I just gave you an example. I moved a guy onto the project to add a different decision-making style. I was trying to create a bigger difference in personality. It was amplifying the difference. That will change how a team will self-organize. Introduce a new exchange. So what we can do is we can exert influence by altering a team's containers, differences, or exchanges. Now, when you do this, you do not know how a team will respond. I love going into teams and getting them to start doing something like, let's say, pair programming. And I have a pretty good idea, because I've been doing it for years, how a team will respond to pair programming. After I've met that team, I know them a little bit, I can develop an opinion about how they'll respond to pair programming. But I don't know that. I don't know how they're going to respond. So I'm taking an educated guess. And then I consider this to be kind of a nudge. I kind of poke and prod. I nudge the group, hoping that introducing this will fix or improve some aspect of their situation. But I never know for sure. They're educated guesses. So we alter containers, differences, or exchanges. Not because it's just plain fun. We do it to improve the team, constantly trying to help a team get better. I want to give you a couple examples. I've given you a few already, but here are a few more. For containers, enlarge or shrink the team. Make the team bigger or smaller. That will change the container. Enlarge or shrink the responsibility of the team. Tell a team they're not responsible just for developing the thing, but for getting it deployed out in our data center. That's a change in responsibility. That's a changing container. I don't know how a team will respond to that. I can take educated guesses, but I'm not 100% sure. Change team memberships. Move him off her on. Change the team members. Create new teams or groups. Instead of the three teams we've got, let's create four smaller teams. That's a change in container. So we can do all those things, and we do it to help a team improve. Differences. Amplify or dampen the differences. Tell a team to change their decision-making style. Or just as a scrum master or coach, manager for that team, you change how they're making decisions. Do it by the questions you ask. I love asking teams hard questions. When you ask a team hard questions, you will find dissenting viewpoints. You will bring out the differences they have. What three alternatives did you reject before you chose this approach? What's the worst thing that could happen if we made this decision? How would we recover if this decision didn't work out for us? If you ask questions like this, and there is kind of underlying dissent with the direction they're headed, that will come up. Somebody on the team will say, well, I've been really worried about that. I'm glad you asked. Here's what I think might happen if we make this decision, and I'm worried about it. I'm going along with the team, but here's what I'm worried about. So you can amplify the differences, make them bigger by asking hard questions. You can dampen the differences. Stop asking those questions if you need a team to get to consensus sooner. These are communications that a team has. Encourage communication between teams. Find out who's talking that shouldn't be, or find an exchange that's happening that you don't think is necessary, and try to get a team to stop that exchange. Add or remove people to conversations. Maybe your team does a design review. Add somebody to that design review. Here's an example. You might not think this was a very agile thing to do. In this talk, isn't necessarily agile. We're just talking about self-organization. But if you know me, you know I'm kind of into agile. So you might not think this is a very agile thing to do. I had a particular team, and I told them all of your decisions, all of your key architectural decisions, I want you to run by this one really senior developer in the company. His name was Todd. And I said, I want you to run all your hard technical decisions by Todd. I went to Todd, who's an architect, not on that team. And I told him, I said, don't change many of their decisions. I really just mostly want you there to scare the team. If they know they have to come present to you, they're going to think through their architecture better, and they'll come to you prepared with good decisions. If they are about to make a big mistake, I absolutely want you to stop them from making that big mistake. But if it's just a small mistake, or if it's just the thing where you disagree with how they're going, but they're going to be successful their way, don't change them. Let them own that decision. That's fine. I said, but do stop them from big mistakes. So I put this new exchange in place. It probably sounds kind of unagile. I took a team that was a nice agile team, and I had them get approval on their design decisions from some outside guy, kind of a non-agile. I did it for their good. I did it to make them pause, reflect, think harder about decisions they were making. I didn't do it just because I wanted to slow them down. I didn't do it just because I liked this Todd guy and wanted reviews to go through him. I did it to help this agile team. So an example of introducing an exchange. Containers, differences, exchanges are things that we can control. We can alter. We can manipulate to help a team do better on their project. What I'd like to do, what I'd like to have you do, is a little exercise along this lines. So here's what I've got. Here's our exercise. I've got the next couple slides. These are the things I handed out. Hopefully you got one. If not, we can get more passed around. What I'd like you to do is to think about the cases on the next couple pages, just in little groups. Just kind of turn around, talk to a couple people next to you, and talk through one of these cases and decide what would you do in that case. If you don't have the handout, I'll just leave one of them up on the screen. You can talk about the one on this, talk about the two that will be on the slide. Let's do number one together here. You've got a team that's got four programmers, two testers, database guy, and you. The programmers and testers aren't working well together. Programmers work in isolation until two days are left in the iteration. Then they throw the code over the wall to the testers. Anybody got an idea what would be a good thing to change in that situation, suggesting for what you might do there? Yes? Change how they're seated, right? Move people around. Would that be a change in container? Difference or exchange? The two first ones? Containers and differences? Yeah, to me that would be a change in container, right? And it's probably then immediately going to lead to additional differences, right? It's going to get people who are different talking to each other, right? Another good example, I could introduce the idea of pairing. Have a programmer and tester pair. They're not doing it on their own. Let's just decide we're going to do this. As a scrum master for that team, I might say, hey guys, let's try cross discipline pairing. We're going to have programmers and testers pair early on to get this going. We might do that for a couple of sprints, and they'll realize it's a good way to go. I don't have to mandate it anymore, right? Is that a difference in container? Differences or exchange there? Exchange? Yeah, I'd go with exchange on that one. Now I see some people going, ooh, I don't know, right? You're right. A lot of times things will cross boundaries. They might be two of these things. That's fine. When you have something, and you're looking at this going, wow, this is really a container and an exchange, that's probably a pretty powerful intervention, as opposed to something that you can look at and go, wow, that's a pure container intervention. Something that's really kind of two things, pretty powerful intervention. That could be good or bad. Maybe you want a powerful intervention. This team needs to be kind of nudged in a powerful way. Maybe they need just a small nudge. Maybe you can find something that's just a difference you introduce. So what I want you to do, I'm going to put these up here. Two's up here, three, four. You've got to use them to hand out. If you didn't get one of these, I'm just going to leave the last one up here. Just take five minutes. Pick one or two of these. Talk about it. What would you change? What would you have this team do differently? And is that a change in container, difference, or exchange? Talk about that for five minutes. OK. Let's talk about this. I'm just going to pick one on each page. So we talked about one on the first page. Which one you want to talk about here? Anybody talk about three or four? You got a tip for me on this one? Anybody do three or four? No. Let's talk about it then. Now, what would you do on number three? You got a team consistently under committing during sprint planning. They finished their work, but it didn't seem like much. Product owner hasn't complained yet, but you're worried as the coach, you're worried that the product owner is going to complain. What might you change here? Yes? What would you change for this in the new container? What would you do in there? Where's the results of the data here? That's a good point. Is this something that's been persistent? I'm looking at the way I wrote this, and I said consistently under committing. So I'm assuming they've been doing it for a little while. What would you think to change? Well, usually what happens is the pulse on the track will be really consistent in the last four hours. OK. So I encourage them to take on the right advice. Might have been a spectacular fail your five or six sprints ago, right? And it's been consistent since then. What else? I'm going to bring a senior that consistently underestimates the work. OK. Bring a senior onto the team who consistently underestimates. That could do it, right? Now, that would be which? Get some tension on the team, right? Team should have some sort of tension. We don't want people who always do the same thing. A lot of times when we do have a team that under commits or over commits, it's not necessarily that we got a bad team or bad people on the team. We just have kind of a bad mix, right? And we change that up. We bring a different person onto the team. Just swap two people out. I'm not saying we bring anybody better on or anybody worse. It's just somebody different, right? Somebody different will have a different approach to things. We bring on one of those people who's just always really enthusiastic. We can do more. We can do more. Yeah, let's take this on, right? Rest of the team is nervous, but this guy's got an outgoing, let's do it, personality. Maybe they start to try one more, right? And maybe in this case, if they really are under committing, might be a better thing to do. It may not be the team's fault. It may be that the backlog isn't groomed. Is it really ready to go? In which case, I might want to do what? I want to introduce a meeting to make sure the backlog is groomed, is prepared. That would be a new exchange, right? Let's introduce a new meeting into our process where we make sure the backlog is well groomed before we do something, before we start a sprint, right? Let's just do one more, something on the last page here. Let's do number five. We got Jeff, a domineering senior developer. During iteration planning, the team defers him on every decision, even though he's a horrible estimator. You notice that Glantz is the other team members exchange wherever he suggests very low estimates. What do you want to do about this guy? Yes. Do what? Yeah, play poker, play planning poker, estimating poker, right? One of the nice things with estimating poker or planning poker is everybody turns over a card at the same time, right? If everybody turns over a card at the same time, we at least get to see people's independent opinion before this guy gets a chance to dominate the meeting, right? That would be, if I look at that as a way of introducing a new, or amplifying the differences, right? So that'd be a new difference to me. We've already got an exchange going. I already got an estimation meeting of some sort. We're going to change our technique. This would be a way of amplifying the differences between team members by having this first round of planning poker unbiased by any one estimator, right? So to me, the container difference exchange model is a way of thinking through problems. You have a problem with the team. You're trying to introduce a way to solve that problem. Thinking through the containers, differences, and exchanges can help address that. I can't tell for sure. Is the microphone on? It's working. OK. I wasn't hearing it, so I wanted to make sure. All I hear is this other group. So the last thing I want to talk about is influencing that team over time. Evolution. Self-organization is not a one-time thing. We don't self-organize and we're done. Self-organization is a path, right? And the team is never done. You can't put self-organization on a Gantt chart and say, boom, we're done. We've self-organized. It's a continual response to a challenge. So as the team self-organizes, you can continue to re-exert influence. Always trying to help that team be the best they can. Again, I consider these things like nudges. You're pushing the team in certain directions, and you never know for sure how they're going to respond. I want to share with you one other quote. This is from the same guy we looked at before, Philip Anderson. He said, self-organization proceeds from the premise that effective organization is evolved, not designed. You can't sit down up front and go, here's what we should look like. You have to evolve there. He says, it aims to create an environment in which success and growth, rights, browins, podemos solve a metric amount of problems that lead to We're not talking about turning people into marathon runners with fitness. We're talking about fitness for their environment. We're talking about a team that fits their environment. And so the team evolves to fit their environment even as their environment changes. And they say this happens not because management has mastered the art of planning and monitoring workflow. So management sets up an environment, management encourages change, management pushes teams to get better. So we are talking about things that you hear as scrum masters, product owners, project managers, just plain influential people in your organization can do to help that team evolve. Now, if we think about evolution, evolution is a result of three things. Variation, selection, and retention. All right, so think about a giraffe. In a giraffe, variation occurs when the first giraffe suddenly develops a long neck. Mutation refers to that long neck turning out to be a good thing. And retention occurs when that mutation, that long neck is passed on. So what we're looking at here is allowing teams to vary, allowing them to try new things. Having a mechanism that lets us determine which of those things they tried was good. Which of those things worked out and therefore should be retained by other teams. So our job in management is to help create this type of environment where we can experiment, where we can retain, where we can pass on the successful items. Here are seven things you can do to influence evolution. All right, from selecting the environment down to energizing the system. So we're going to walk through. Yeah, absolutely. Sorry, it's hard for me to see things. I got, oh, I got this noise. I got a big white. So. I got a lot of team members I wish would go away. So yeah, I think it does mean that. I mean, what we're talking about here, you know, kind of Darwin's term, survival of the fittest, right? We're talking about the teams that do the best in our environment, should be propagated, they should be continued, and practices that aren't working should start to fade away, right? So I'm not necessarily talking about, you know, teams evolving and teams going away. I'm talking about practices with those teams, things like that. So if a practice is not working and a new practice is discovered, right, testing early rather than testing late, yeah, I want the testing late practice to go away as we learn the benefit of testing early. So yeah, I do. Good point. So here are seven things. We're going to talk about each of these seven, right? Selecting the external environment. What we're after here is defining the environment for your team. And this is more than just your physical office environment, right? This is more than the type of chair you've got, right? To some extent, it's what business we're in. Now you probably can't influence that, but somebody can in the organization. This has to do with your company's approach to innovation, right? Some companies are innovators. Others are fast followers. I'm not going to judge and say one's better than the other, right? Being a fast follower, Hewlett Packard, right, known for making printers, right? They're known as a fast follower, right? They're generally not the first one to come out with the idea, but they follow and then they do it better than anybody else in terms of making it a long-term product. What's our corporate culture towards mistakes, right? Do we penalize somebody when they make a mistake? Chop their head off, right? What type of projects are worked on? Which type of projects are praised in the organization? Do we try to do too many projects at once? All of these things have to do with our physical environment, our external environment, right? The environment in which the projects are occurring, right? I've got multitasking and focus, right? What do we like to do here? Do we want to have people focused, get one thing done? Or, we want to have those companies where everybody's on eight projects, right? I was with a client last year. I was supposed to be there for a week. I did one day and I left, right? I was there as teaching a class and I looked up too many times during the first day and I couldn't make eye contact with a single person in the room. There's like 30 people in the room, every one of them, every time I looked, banging away on their laptop, right? And then they're asking me questions every now and then like, should a Sprint Master do this during the daily Sprint, right? It's like, sorry, those aren't even the right words, right? They're not getting it. And so this was a culture where everybody was expected because the boss did it. Everybody was expected to just be banging away on your laptop all day during every meeting. I went to the boss at the end of the day and said, you're not going to be successful. I don't want to be a part of this, right? I didn't bill him for the one day I was there and I flew home, right? So what is our company expectations towards multitasking, towards focus, right? As leaders in the company, right, we can define what is good performance, right? What makes a successful employee in our company, right? You've all been in part of companies or in companies where there's some boss who praises the hero, who worked really hard to solve a problem that that guy caused himself, right? I've seen that way too many times, right? This guy causes a crisis, then he works hard to solve the crisis and he gets praised, right? Isn't this guy a hard worker, which should all be more like him, right? What type of message does your company send in terms of long and short-term performance, right? I'm sure there's a company who had people planned to come here today, come here this week, and then last week they decided, uh-oh, we're too busy. Let's cancel the person's attendance at NDC. I guarantee somebody was in that position. None of you, because you're all here, right? But somebody had their attendance here canceled at the very last minute. What type of message does that send employees in that company in terms of the long-term versus the short-term? We don't want to invest in this, uh, this employee over the long-term because the short-term is such a crisis, right? Not a good sign to send, right? We can manage what's meaningful in our company, right? What messages do we respond to, right? What messages do we hear? What signals danger in our environment, right? Think about ants responding. They follow trails, right? There's food over here. They follow a trail, right? Think about the messages that you can push to your team about what's valuable. What messages can you push that are good? I want to share you one story about messages in a company where I worked. I worked in this company where we were a startup. We had about 200 employees at the time, and we were about to turn profitable. We were just about to do it. If things went well this quarter, we would be profitable. And we were a public company. We had gone public earlier in the year. And if we could be profitable, that was going to be huge for our stock price. And so the company president has us all come in to a company meeting, and he talks about this, and he talks about how important it is to keep costs down. Please do not go on a business trip this quarter if you can put it off. Please don't buy office supplies this quarter if you can put it off by all you want next quarter. But let's try to get profitable. It is going to be so close. And while we're having this meeting, he tells us that he's got the janitors going around to all of the toilets in the building, and they are replacing the nice, comfortable, two-ply toilet paper with one-ply toilet paper. Now, I'm sure this cost him money to replace whatever toilet paper we had with a lower-quality toilet paper. But he said every time we were in the bathroom, he wanted us thinking about company profitability. Very ridiculous, but man, what a way to make his point. What a way to make his point. I remember this is 20 years ago, and I remember this as though I were still there. I was working with another company. They were trying to get me to come in and do some consulting, and I pretty much decided I'm not going to do it. I'm just going to kind of finish out this kind of day where I'm helping them out for free, and I'm not going to come back. And I'm waiting for the general manager to come by, and this vice president who's kind of been pushing me around different places all day, said, I can't wait for you to meet our general manager. He is so great, and he talks about how this general manager counts the cars in the parking lot every day at 5 p.m. Now, 5 p.m. is kind of an early but normal quitting time in the U.S. A lot of people may be there until 5.30, maybe 6 o'clock. And so this guy goes, because they don't come in until later, and this guy goes out at 5 o'clock and counts the cars in the parking lot. And so I said to the vice president who's got me there, I said, wow, that's great. He counts the cars. Then what does he do? He goes around and finds all the people who are still here at 5 and send them home because they've worked so much? He said, no, no, no, we want people here later. And so this had become part of their company culture. This was horrible that this vice, this general manager was going to walk around and count the cars. And he did. He had a chart. He had a little graph in his office, how many cars were in the office or in the parking lot every day at 5 p.m. He was fired about a year later. And the division of the business was sold about six months after that. So what type of stories are told in the company? What has meaning in the company? Choosing people is a management responsibility. Who is on the team is going to influence how they self-organize. And so when we choose the team, we can do things like adjust team size, location, background, experience, the decision-making style of people, the gender of the people on the team. What's the gender up if that's going to be good, right? The motivation. People who are skeptical versus people who are just very enthusiastic. I remember one guy I had on a team. He was just kind of a mediocre programmer. But man, he was good for helping a team come together. He was the guy that was having people over to his house on the weekend for parties. He was the one encouraging people to go out for beer afterwards or the new Star Trek movies out. Let's go see that. I was considered this guy to be like glue. He was one of the highest paid guys in my department because of this behavior that he had. Not because he was an amazingly talented programmer. He was a little above average. But he was like glue. He kept a team together. And I remember having two teams in two different cities that didn't get along. I put him on one of those two teams so he could help them get along. And he did. So think about the people that we put on a team. So one of the questions that this brings up is should a team have full control over it? My answer is going to be no. I do not think the team should have full control over who's on the team. They should have opinions. They should have influence. But it's a management responsibility to select who is on the team. The very first article on Scrum talks about this and validates me in this opinion. This is back to a team being self-organizing. If you give the team total responsibility for who's on the team, it's very possible that they select team members who are all very similar to one another. So this remains a management responsibility. I want to listen to the team. I want to be very influenced by who they want on the team. But I'm not willing to give that up as management in the organization. Because this is one of the primary levers I can pull to help a team self-organize. So who's on the team? Up to management. Totally should be influenced by the team. But it's a management decision. Yeah? Do you think the team should be able to choose their own roles? Largely. I do. So do I think team members should be able to pick their own roles? Yeah, largely I do. I don't think that we hired you to be a DBA and you think database stuff is boring all of a sudden and you'd like to be our new superstar Python programmer even though we don't program in Python in this company. No, I don't think you have the right to do that. But I do want people to help figure out what they want to do. I do think we should have influence over those things. But the team still has to respond to the challenge that they're given. And if the other team members don't want you doing that because they need you doing the other thing, I think they have influence over that as well. So I don't think you can just completely change your direction on a team. The way I like to think of team members is I think of us as team member first and then JavaScript programmer second or database person second. But you're a team member first doing whatever you can to help the team. But you're largely going to stay within some sort of specialty evolving that over time. Three more things. Number five here. It has to do with reconfiguring the network. I'm not talking about the data network. I'm talking about the people network, the human network. Communication paths in an organization. These can often be more important than the individual people. How do we communicate? And you can introduce or remove communication paths. I talked about having everybody run things by an external architect. Introducing new communication paths. So I want to give an example of a distributed team and reconfiguring the network on a distributed team. So suppose we have this situation. Half of our team is here. Half of our team is back in my hometown Denver, Colorado. One way to structure those teams would be like this. We would have an intact team here in Oslo. Programmer, tester, designer, data. Everybody necessary here in Oslo. We have everybody necessary to be a good team in Denver. And then we just coordinate. That's one option. Another approach would be to create what are called deliberately distributed teams. In a deliberately distributed team, we would set up one team that's half here, half there. A second team that's half here, half there. There are advantages to either approach. If we have an Oslo team and a Denver team, it's entirely possible that we end up with a little us them mentality. It's their fault. No, it's their fault. If we end up with a team half here, half there. A second team half here, half there. Probably not going to have us and them problems. But we're going to have people doing meetings at weird times of the day. Phone calls early in the morning from Denver to late in the afternoon here. There are problems either way here. So I'm not going to tell you do it the top way, do it the bottom way. I do it both ways. Sometimes the top, sometimes the bottom. But this should be a thing that you can consider in terms of how are you going to structure that team. I've been involved in a lot of acquisitions where one company's acquired the other than I get involved to help kind of fix the development problems at the acquired company. When we do that, I far prefer the bottom approach. Because if one company acquires another, I want to get those teams working well together and setting up separate cities. Kind of desirable in a lot of ways, but not when there's an acquisition. Because we've got kind of an us and them thing going already. So top or bottom, either one can work, be aware there's pros and cons. Number six of seven. Evolved vicarious selection systems. So we talked about variation selection retention. One of the things I would love to do is have 20 teams in our company. Have those teams run for five years and at the end of five years, figure out which one of those teams created the most profitable products. And then take that process that that team used and replicate that to all other teams. The problem with that is it just took us five years to find out which one of those teams was more successful. So what we'd like to do is create vicarious alternative selection systems. A selection system that doesn't take an entire generation of giraffes to select long necks. I want to find something that will help us create those mutations and retain them more quickly. So I don't want to trust the marketplace because it's going to be too long of a cycle. So one of the things that you can do here is create alternative selection systems. Google's 20% policy. Everybody's familiar with this. Where Google tells people that you can spend 20% of your time on any project you want. What do you think that tells Google when they see a whole bunch of employees flocking to work on a certain project? That is a really good indicator that that project has captured people's attention. And one of Google's premises for years has been that their engineers are pretty much their audience. Right? They're after people like themselves. Right? They're building stuff for people like themselves. So if their engineers all want to work on a new system, that system is likely to be profitable and they should let those people work on that system. So what we want to do, we want to create these approaches that let us monitor what's successful and select it without having to wait for entire market cycles to indicate this. The last thing that we can do is to pump energy into the system. In the U.S., overtime is a big issue. And people are always trying to get people to work more overtime, work longer hours, things like that. And I've been a vice president in four different organizations and I've never been after overtime from my people. I was never really trying to get people to work 60 and 80 hours a week. What I was after, on the other hand, was having my team members go home after eight hours mentally exhausted. They had left it in the office. They were tired. Did not want to see a computer when they went home. They put so much energy into the day they were done. So what I'm after is people's energy, not just hours. And so what we can do as leaders is pump energy into the system. And we do that by giving teams an igniting purpose. What ignites a team's passion? Sometimes called a clear, elevating goal. What can we do to get that team motivated? And we can do this by giving teams if they're successful. I don't just give them money, but give them opportunity. Bigger roles, chances to work on the better projects. Allow them things like to go to conferences. I remember sending my programmers to a Eiffel conference one time. Eiffel is kind of a weird language, a very fringe language, a very interesting language, but it's never been a mainstream language. And I sent my C++ programmers to an Eiffel conference many years ago. They were all totally baffled. But they all came back kind of energized about what they'd learned. We were never going to use that language, but it taught them new ways to think about things. They got them excited. Do brown bags, little seminars in the office, things like this to pump energy in. Keep a team motivated. I want to give one example. We'll wrap this up. One example of pumping energy into a system. This to me is a very famous example, a very old one, but it had to do with the email. Actually, it wasn't an email. It was a memo. Bill Gates didn't use email back in 95. He did. This is a memo. This is back when Microsoft realized there was something called the Internet out there. And so Bill Gates sent this message to his employees, the Internet is a tidal wave. It changes the rules. It's an incredible opportunity as well as an incredible challenge. I'm looking forward to your input on how we can improve our strategy to continue our track record of incredible success. Pretty bland email when it really comes down to it. Bill Gates did not deliver some, whoa, we got to go take over the Internet message. This is a pretty bland email. I can imagine any boss I've ever had writing that email. There's nothing amazing to that. But this was the email or the message, the memo that really turned Microsoft around, got the Internet Explorer team started, things like that. Got people focused on the Internet. So this was a very energizing message that was sent around Microsoft, even though when you read it, really not much there. Just a memo saying, hey, you think about it. I'm looking forward to your input, you guys own the problem, figure this out. Bill Gates was not laying out the strategy. He was very good at this. He wasn't saying, I got the answers here. He was asking for the answers from his entire company. So self-organization, evolution, subtle control. Remember containers, differences, exchanges, we exert influence on our teams. None of this is evil. We do it as a way to influence our teams. Last things, you guys have seen this, if you've been here before, there's just a website we've got for video training. Want to mention that because we've only had it up for a month or so, so we're trying to get interest in this. There's my contact information, my website up there. Again, you can download this presentation, all the other presentations from today. In fact, you can download any presentation I've ever given at a conference on that website. Just go to mountgoatsoftware.com. Feel free to email me questions later. I'm always happy to talk about this, so you got my email up there. I can back and teach classes through our host here through program of the team every three months. So if you're interested in Scrum, I teach classes on that every three months here. We'd love to have some of you in those classes. Last thing, please do as you get a chance when you're walking out, drop one of the little colored squares in the review box out there. The conference is appreciates that as do I. Thank you guys very much. I appreciate you being here. Have a good weekend. Bye-bye. Thank you.
about leading a self-organizing team. Here's the you can use to influence, exert, subtle control Self-organization, self-organizing, is the proper to exert influence in a good way over how a team highway. Software teams, complex adaptive systems. Now, in this type of a situation, subtle understand why different countries do different means that management commits to guiding the kind of rigid control that impairs creativity and of debated things a little too much. But I knew all three of these things. Now, a container is a power. One of you might be a vice president of exchanges for self-organization to occur. We team will self-organize. Introduce a new they're making decisions. Do it by the questions underlying dissent with the direction they're necessary, and try to get a team to stop that agile thing to do. In this talk, isn't get approval on their design decisions from some problems. You have a problem with the team. idea, but they follow and then they do it better development problems at the acquired company. Just go to mountgoatsoftware.com. Feel free to