Leading a Self-Organizing Team
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 170 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/13967 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 2014169 / 170
2
3
5
6
8
11
12
16
21
22
23
27
31
35
37
42
43
45
47
48
49
50
52
54
56
57
58
61
65
66
67
71
74
77
80
81
83
84
85
87
88
89
90
91
94
95
96
97
98
100
102
107
108
112
114
115
116
118
120
121
122
123
126
127
128
130
133
135
137
138
139
140
141
142
143
144
145
147
148
149
150
153
155
156
157
158
159
160
161
162
163
166
169
170
00:00
Integrated development environmentSystem programmingAerodynamicsComputer networkDecision theoryControl flowPhysical systemParallel portEvent horizonSoftwareFlock (web browser)Rule of inferencePersonal digital assistantSelf-organizationData managementIndependence (probability theory)Time evolutionPhysical systemData managementNatural numberDifferent (Kate Ryan album)Product (business)Right angleGame controllerDecision theoryData managementIntegrated development environmentGroup actionSocial classProper mapSoftwareStatement (computer science)Dynamical systemComplex (psychology)Multiplication signRule of inferenceSelf-organizationOffice suiteComputer programmingDependent and independent variablesEvent horizonAdaptive behaviorType theorySign (mathematics)Water vaporSpontaneous symmetry breakingTable (information)NumberEvoluteResultantFamilyTerm (mathematics)Software testingCASE <Informatik>Programmer (hardware)Task (computing)BitFigurate numberWorkstation <Musikinstrument>ArmFlock (web browser)CodeCellular automatonIndependence (probability theory)PlastikkarteChaos (cosmogony)Projective planeCommitment schemeInteractive television1 (number)Shared memoryMathematicsArithmetic meanComputer animation
08:13
Control flowSystem programmingCondition numberBoundary value problemSelf-organizationPhysical systemTime domainGenderMachine visionFood energyInformationFormal grammarData modelElement (mathematics)MathematicsGroup actionNumberDifferent (Kate Ryan album)Data conversionGenderLevel (video gaming)Projective planeSoftware developerClient (computing)Row (database)Term (mathematics)Decision theoryTransformation (genetics)Domain nameProduct (business)POKEPhysicalismBoundary value problemDependent and independent variablesSelf-organizationComputer programmingStorage area networkGame controllerRandomizationBitBroadcasting (networking)QuicksortPower (physics)MathematicsDatabaseGroup actionMoment (mathematics)Order (biology)Element (mathematics)Right angleForcing (mathematics)Direction (geometry)InternetworkingElectronic mailing listEndliche ModelltheorieGreatest elementTraffic reportingData centerComputer animation
16:26
MathematicsElement (mathematics)Group actionBoundary value problemTelecommunicationSlide ruleDampingDatabaseIterationCodeSoftwareSoftware developerTask (computing)PlanningEstimatorDecision theoryPersonal digital assistantMathematicsGoodness of fitData managementProgrammer (hardware)Boundary value problemComputer architectureMultiplication signDecision theoryDifferent (Kate Ryan album)NP-hardDatabaseTouchscreenSlide ruleCASE <Informatik>Projective planeDirection (geometry)Line (geometry)Software testing2 (number)Software developerNumberExterior algebraCodeIterationTelecommunicationRight angleData conversionComputer programmingWeb page1 (number)Group actionSelf-organizationAdditionGradient descentComputer animation
24:39
Software developerTask (computing)IterationPlanningEstimatorDecision theoryPersonal digital assistantTerm (mathematics)Direction (geometry)Product (business)Self-organizationView (database)Time evolutionDirected setControl flowIntegrated development environmentSelf-organizationWeb pageDecision theoryIntegrated development environmentNumberDifferent (Kate Ryan album)Lattice (order)Software developerSpring (hydrology)Point (geometry)EstimatorMultiplication signProjective planePlastikkarteCASE <Informatik>Endliche ModelltheorieMathematicsRight angleProcess (computing)Arithmetic meanIndependence (probability theory)PRINCE2INTEGRALProduct (business)Roundness (object)Direction (geometry)Dependent and independent variablesTime evolutionPlanningIterationShared memoryComputer animation
32:52
Self-organizationWage labourDivision (mathematics)Integrated development environmentCoroutineDependent and independent variablesSet (mathematics)Data managementFitness functionTime evolutionPlanningElement (mathematics)Bounded variationRandom numberSystem programmingPhysical systemComputer networkEnterprise architectureBit rateType theoryFocus (optics)Message passingTerm (mathematics)CodeFitness functionData managementIntegrated development environmentProduct (business)ResultantSelf-organization1 (number)Selectivity (electronic)Message passingType theoryPhysical systemPosition operatorBoss CorporationOffice suiteMereologyMultiplication signProcess (computing)Sign (mathematics)Division (mathematics)Projective planeWage labourDisk read-and-write headSoftware testingMechanism designSurvival analysisNoise (electronics)Right angleAbsolute valueBounded variationDependent and independent variablesEvoluteTerm (mathematics)PlanningPhysicalismExpected valuePoint (geometry)LaptopLattice (order)Cue sportsFocus (optics)Extension (kinesiology)Flow separationInsertion lossGoodness of fitGroup actionMathematicsMachine visionWordData managementDataflowSocial classCoefficient of determinationComputer animation
40:42
Message passingPhysical systemDecision theoryGenderControl flowComputer networkFormal grammarTelecommunicationSelf-organizationDistribution (mathematics)Goodness of fitDependent and independent variablesDatabaseData managementData structureDirection (geometry)Mixed realityNumberSoftwareData managementLattice (order)2 (number)MereologyProgrammer (hardware)Multiplication signComputer configurationTotal S.A.GenderBuildingType theoryOffice suiteTelecommunicationDivision (mathematics)Computer programmingRight angleGraph (mathematics)QuicksortInformation technology consultingDecision theoryPoint (geometry)Game controllerSelf-organizationArithmetic meanComputer animation
48:32
Computer networkDistribution (mathematics)System programmingMechanism designBounded variationLocal GroupInformationMachine visionSurjective functionStatement (computer science)Physical systemSet (mathematics)Food energyEntropie <Informationstheorie>TrailWaveInternetworkingStrategy gameoutputPlanningEstimationTwitterTerm (mathematics)Physical systemSelectivity (electronic)Boss CorporationEmailoutputFood energyStrategy gameNumberFlow separationCuboidContext awarenessDifferent (Kate Ryan album)Row (database)Cycle (graph theory)Rule of inferenceSoftware developerGame controllerLattice (order)Multiplication signTrailNeuroinformatikWebsiteProcess (computing)Self-organizationVideoconferencingWave packetFigurate numberProduct (business)Bounded variationInternetworkingProjective planeElectric generatorSocial classMessage passingData structureComputer programmingSystem callPresentation of a groupExterior algebraProgrammer (hardware)Square numberEntire functionDrop (liquid)WaveCausalityOnline helpPrice indexGreatest elementBuildingGoodness of fitFormal languageComputer animation
56:21
Computer animation
Transcript: English(auto-generated)
00:02
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 in 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.
00:23
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, right?
00:40
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. We're going to talk about team evolution, how a team evolves over time.
01:01
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.
01:23
Some people 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, right? So self-organization responds to a challenge defined by the product owner.
01:41
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, right? There's no police officer saying, you go next, you go next, why don't you go in that lane? Right, cars self-organize. So self-organization responds to a challenge, right?
02:02
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.
02:20
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, right? I didn't say people, right? 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, right?
02:42
So a programmer is reacting to what a tester finds. A tester is reacting to how well the programmer did their code, right? 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, right?
03:01
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, right? Being made, remade, adjusted. And this is how teams behave,
03:20
or should be allowed to behave. A few examples of complex adaptive systems, right? Things like ant colonies, beehives, flock of geese, right? A family preparing a meal, right? You got little kids, you might have the mom or the dad assigned tasks to the little kids, right? But a more mature family will figure out how to do this.
03:41
Us right now, we self-organized. You had to figure out where to sit, right? You had to walk in, somebody wanted to sit near the front, maybe forgot your glasses today, wanna sit here. Few other people wanted to sit near the door in case I get real boring, right? You had to figure out where to sit, right? That's self-organization, right?
04:02
I use cars on a 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, right?
04:20
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, right? I think a lot of other things are evil and perpetrated on me by my government, right? But not rules about the highway, right? That's a pretty realistic thing. You know, I don't care what side of the highway we drive on.
04:41
For me, it's pretty natural to drive on the right side like you do here, right? But the English, India, going on the other side of the road, okay. I get it, kind of a random decision. I don't really care, right? Certainly used to one by now, so I don't wanna change it, but I understand why different countries do different things. Bio teams, teams in biology or nature,
05:01
their rules are provided by their environment, right? These are born with a desire, an innate desire to produce honey, right? So these rules or incentives to behave are okay, right? And managers, leaders, scrum masters, product owners can add rules, can add incentives on top of a team, right? To help that team.
05:21
We don't do it because we're evil, manipulative jerks, right? 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 six o'clock the first day
05:40
to make sure the tables were set up exactly how I wanted them, right? I taught a class a couple of days before and 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, right? 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.
06:01
I couldn't do anything here, right? These chairs are where they are, right? So I didn't get a chance to really exert subtle influence over you, right? But I did over that class, not because I'm evil, but because I wanted to create the best experience we could, right? 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.
06:23
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.
06:40
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.
07:01
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, right? 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.
07:22
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.
07:42
Scrum teams are often talked about acting on the edge of chaos, right? 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 gonna go out of control, but they're going just slow enough to be in control.
08:02
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.
08:22
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.
08:41
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,
09:00
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 asked a lot of questions.
09:21
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
09:41
and they say, hey, why'd 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.
10:00
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.
10:21
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.
10:40
And she said that for, and I 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.
11:04
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 got a person in every other seat. So where somebody sat who influenced where the next person said, I want two armrests.
11:21
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.
11:43
Your role as 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 Norwegian. I love my one fourth Norwegian-ness. Thank you, grandmother. But my nationality kind of American.
12:01
We have a number of people here, 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.
12:21
Pretty easy to have differences when we're talking about humans. We're gonna 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.
12:42
I got here 10 days ago. We have differences in terms of gender. Differences in power. One of you might be a vice president in 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.
13:02
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.
13:24
We leave that conversation excited about how many people are gonna 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. Right? That's a transforming exchange.
13:42
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.
14:01
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.
14:22
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 who had a different decision-making style. I was trying to create a bigger difference in personality.
14:41
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
15:02
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 gonna respond.
15:20
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.
15:41
We do it to improve the team. Constantly trying to help a team get better. I wanna 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.
16:02
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 change in 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.
16:20
Move him off Huron. 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.
16:41
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.
17:03
What three alternatives did you reject before you chose this approach? What's the worst thing that could happen if we selected, 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.
17:22
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.
17:43
Exchanges, 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.
18:01
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. And 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.
18:21
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,
18:41
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 gonna 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
19:02
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 gonna 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 an agile.
19:21
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
19:42
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
20:03
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 of people next to you
20:20
and talk through one of these cases and decide what would you do in that case. If you don't have a handout, I'll just leave one of them up on the screen and you can talk about the two that'll 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.
20:41
Programmers work in isolation until two days are left in the iteration and then they throw the code over the wall to the testers. Anybody got an idea of what would be a good thing to change in that situation? Suggesting for what you might do there? Yes.
21:01
Change how they're seated, right? Move people around. Would that be a change in container, differences 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 gonna lead to additional differences, right? It's gonna get people who are different
21:21
talking to each other, right? Another good example, I could introduce the idea of pairing, right? Have a programmer and tester pair. They're not doing it on their own. Let's just decide we're gonna do this. As a scrum master for that team, I might say, hey guys, let's try cross-discipline pairing.
21:41
We're gonna 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. I see some people going, ooh, I don't know, right? You're right, a lot of times things will cross boundaries.
22:02
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, all right?
22:21
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, okay? So what I want you to do, I'm gonna put these up here. Two's up here, three, four. You got these in the handout. If you didn't get one of these,
22:40
I'm just gonna 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.
27:55
Okay, let's talk about this. I'm just gonna pick one on each page. So we talked about one on the first page.
28:03
Which one do you wanna talk about here? Anybody talk about three or four? You got a tip for me on this one? Anybody doing three or four? Let's talk about it then out loud. 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.
28:23
Product owner hasn't complained yet, but you're worried as the coach, you're worried the product owner's gonna complain. What might you change here? Yes. That's a good point. Is this something that's been persistent?
28:41
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. Right, what would you think to change? Okay.
29:01
Might've been a spectacular failure five or six sprints ago, right? And it's been consistent since then. What else? Okay, bring a senior onto the team who consistently underestimates, right? That could do it, right? Now that would be which?
29:21
Get some tension on the team, right? Teams 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.
29:41
Just swap two people out. I'm not saying we bring anybody better on or anybody worse, 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's nervous, but this guy's got an outgoing, let's do it personality.
30:01
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. May not be the team's fault. It may be that the backlog isn't groomed, isn't really ready to go, right?
30:20
In which case I might want to do what? Might want to introduce a meeting to make sure the backlog is groomed, is prepared, right? 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, right? Before we start a sprint, right?
30:41
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 to him on every decision, even though he's a horrible estimator. You notice the glances the other team members exchange whenever he suggests very low estimates. What do you wanna do about this guy?
31:01
Yes. Do what? Yeah, play poker, play planning poker, estimating poker. One of the nice things with estimating poker or playing 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, right? Before this guy gets a chance to dominate the meeting,
31:23
right? That would be in my, if I'd look at that as a way of introducing a new, or amplifying the differences, right? So that'd be a new difference to me, right? We've already got an exchange going or we got an estimation meeting of some sort, or we're gonna change our technique. This would be a way of amplifying the differences between team members
31:40
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?
32:02
It's working, okay. I wasn't hearing it, so I wanted to make sure. All I hear is this other group, so. The last thing I wanna talk about is influencing that team over time, evolution, right? Self-organization is not a one-time thing, right? We don't self-organize and we're done. Self-organization is a path, right?
32:23
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, right? Is 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, right?
32:43
Again, I consider these things like nudges. You're pushing the team in certain directions and you never know for sure how they're gonna respond. I wanna share with you one other quote. This is from the same guy we looked at before, Phillip Anderson. He said, self-organization proceeds from the premise that effective organization is evolved, not designed.
33:02
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 successful divisions of labor and routine not only emerge, but also self-adjust in response to environmental changes, right? A good team will self-adjust as the environment changes.
33:21
This happens because management sets up an environment and encourages rapid evolution toward higher fitness. 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.
33:42
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
34:03
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, right? In a giraffe, variation occurs, right? When the first giraffe suddenly develops a long neck, right?
34:24
Selection 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,
34:41
having a mechanism that lets us determine which of those things they tried was good, right? 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.
35:02
Here are seven things you can do to influence evolution. All right, from selecting the environment down to energizing the system. So we're gonna 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.
35:27
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,
35:40
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 teams evolving and teams going away. I'm talking about practices with those teams, things like that.
36:01
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 gonna talk about each of these seven. All right, selecting the external environment.
36:22
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, right? Now, you probably can't influence that, but somebody can in the organization.
36:41
This has to do with your company's approach to innovation. Some companies are innovators. Others are fast followers. I'm not gonna judge and say one's better than the other. Being a fast follower, Hewlett-Packard, known for making printers. They're known as a fast follower, right?
37:00
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, right? Which type of projects are praised in the organization?
37:24
Do we try to do too many projects at once, right? All of these things have to do with 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, right? Do we wanna have people focused, get one thing done?
37:42
Or are we one of 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, I was teaching a class, and I looked up too many times during the first day, and I could not make eye contact with a single person in the room. It was like 30 people in the room,
38:00
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, I'm sorry, those aren't even the right words, right? You know, they're not getting it. And so this was a culture where everybody was expected, because the boss did it,
38:20
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 gonna be successful. I don't wanna be a part of this, right? 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?
38:43
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?
39:01
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? We 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 plan to come here today, come here this week,
39:22
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
39:41
versus the short-term? We don't want to invest in 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?
40:01
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?
40:21
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.
40:40
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
41:01
if you can put it off. Please don't buy office supplies this quarter if you can put it off. Buy 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,
41:22
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.
41:44
Totally ridiculous. But man, what a way to make his point. What a way to make his point. This is 20 years ago and I remember this as though I were still there, right? 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.
42:00
I'm just going to kind of finish out this kind of day where I'm helping him 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. So I can't wait for you to meet our general manager. He is so great, right? And he talks about how this general manager counts the cars in the parking lot every day at 5 p.m.
42:22
Now 5 p.m., kind of an early but normal quitting time in the U.S., right? A lot of people maybe be there till 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.
42:41
He counts the cars. Then what does he do? Does he go around and find all the people who are still here at five and send them home because they've worked so much? He said, no, no, no, we want people here later, right? And so this had become part of their company culture. This was horrible, right? That this vice, this general manager is gonna walk around and count the cars.
43:01
And he did, he had a chart, he had a little graph in his office of 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, right? And the business, that division of the business was sold about six months after that, right? So what type of stories are told in the company? What has meaning in the company?
43:21
Choosing people is a management responsibility, right? Who is on the team is gonna influence how they self-organize, right? 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, right? Mix the gender up if that's gonna be good, right?
43:41
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.
44:00
He was the one encouraging people to go out for beer afterwards or the new Star Trek movies out, let's go see that, right? I always considered this guy to be like glue, right? And 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.
44:21
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, right? 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, right?
44:44
My answer is gonna be no, right? I do not think the team should have full control over who's on the team. They should have opinions, they should have influence, right, but it's a management responsibility to select who is on the team, right? The very first article on Scrum talks about this
45:02
and validates me in this opinion, right? This is back to a team being self-organizing, right? 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, right? So this remains a management responsibility.
45:21
I wanna listen to the team, I wanna 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, right? So who's on the team? Up to management. Totally should be influenced by the team, right,
45:41
but it's a management decision. 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
46:01
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, right, no, I don't think you have the right to do that, but I do want people to help figure out what they wanna do. I do think we should have influence over those things, but the team still has to respond to the challenge
46:22
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, right? 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,
46:42
but you're a team member first doing whatever you can to help the team, but you're largely gonna stay within some sort of specialty, evolving that over time, so. Three more things, number five here, it has to do with reconfiguring the network. I'm not talking about the data network,
47:01
I'm talking about the people network, the human network. Communication paths in an organization, right? These can often be more important than individual people. How do we communicate? Right, and you can introduce or remove communication paths. I talked about having everybody run things by an external architect, right? Introducing new communication paths.
47:22
So I wanna 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.
47:42
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.
48:03
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
48:21
with a little us, them mentality. It's their fault, no, it's their fault, right? If we end up with a team half here, half there, a second team half here, half there, probably not gonna have us and them problems, but we're gonna 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.
48:43
So I'm not gonna tell you do it the top way, do it the bottom way. I do it both ways, right? Sometimes the top, sometimes the bottom, but this should be a thing that you can consider in terms of how are you gonna structure that team? I've been involved in a lot of acquisitions, right? Where one company's acquired the other, then I get involved to help kind of fix
49:01
the development problems at the acquired company. When we do that, I far prefer the bottom approach, right? Cause if one company acquires another, I wanna 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 a kind of an us and them thing going already, right?
49:20
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,
49:41
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.
50:03
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, right? I wanna find something that will help us create those mutations and retain them more quickly, right?
50:23
So I don't wanna trust the marketplace because it's gonna 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, right? Where Google tells people that you can spend 20% of your time on any project you want.
50:43
What do you think that tells Google when they see a whole bunch of employees flocking to work on a certain project, right? 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?
51:02
They're after people like themselves, right? They're building stuff for people like themselves. So if their engineers all wanna 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 wanna do, we wanna create these approaches that let us monitor what's successful and select it without having to wait
51:22
for like 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
51:42
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, right?
52:03
They had left it in the office. They were tired, did not wanna see a computer when they went home, right? They put so much energy into the day, they were done. Right, so what I'm after is people's energy, not just hours, right? And so what we can do as leaders is pump energy into the system and we do that by giving teams an igniting purpose, right?
52:24
What ignites a team's passion? Sometimes called a clear elevating goal. What can we do to get that team motivated, right? And we can do this by giving teams if they're successful. I don't just give them money, right? But give them opportunity, bigger roles, right?
52:41
Chances to work on the better projects, right? Allow them things like to go to conferences, right? I used to, I remember sending my programmers to a Eiffel conference one time. Eiffel was 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
53:01
to an Eiffel conference many years ago, right? They were all totally baffled, right? But they all came back kind of energized about what they'd learned. We were never gonna use that language, but it taught them new ways to think about things. They got them excited, right? Do brown bags, little seminars in the office, things like this to pump energy in, right? Keep a team motivated.
53:22
I wanna 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, right? This is back when Microsoft realized there was something called the internet out there.
53:42
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.
54:02
Pretty bland email when it really comes down to it. Bill Gates did not deliver some, whoa, whoa, we gotta 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, right? But this was the email, or the message, the memo,
54:21
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. All right, I'm looking forward to your input, you guys own the problem, figure this out.
54:41
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.
55:00
We exert influence on our teams. None of this is evil. We do it as a way to influence our teams. Last things, if you guys have seen this, if you've been here before, there's just a website we've got for video training. Wanna 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.
55:21
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 mountaingoatsoftware.com. Feel free to email me questions later. Always happy to talk about this. So, you got my email up there. I come back and teach classes through our hosts here, through program at Fickling every three months.
55:41
So, if you're interested in Scrum, I teach classes on that every three months here. Would 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 conferences appreciates that, as do I. Thank you guys very much. I appreciate you being here.
56:01
Have a good weekend. Bye bye. Thank you.