What is a Self-Organizing Team?
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Alternativer Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 110 | |
| Autor | ||
| Lizenz | CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben | |
| Identifikatoren | 10.5446/50965 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201232 / 110
1
2
3
5
7
9
11
12
15
19
20
23
24
27
28
29
31
32
33
35
36
37
38
39
41
43
46
47
51
52
56
59
60
61
62
63
65
67
70
71
74
75
77
79
80
81
83
87
91
92
93
94
95
96
97
98
100
103
106
108
110
00:00
SoftwareentwicklerInteraktives FernsehenDifferenteTermTVD-VerfahrenSoundverarbeitungZahlenbereichMereologieOrdnung <Mathematik>KonditionszahlInformationTaskTabelleMultiplikationsoperatorMAPTelekommunikationGruppenoperationProzess <Informatik>KanalkapazitätOverhead <Kommunikationstechnik>Ideal <Mathematik>Spannweite <Stochastik>Charakteristisches PolynomKontrollstrukturGeradeRandomisierungDatenverwaltungUntergruppeEntscheidungstheorieMixed RealityPhysikalische TheorieQuaderSchnittmengeFlächeninhaltLokales MinimumDreiecksfreier GraphVertauschungsrelationDynamisches SystemFormation <Mathematik>Basis <Mathematik>Metropolitan area networkInverter <Schaltung>Quick-SortArithmetisches MittelLeistung <Physik>Gemeinsamer SpeicherBestimmtheitsmaßComputervirusComputerspielExogene VariableSummierbarkeitSelbst organisierendes SystemTotal <Mathematik>Demo <Programm>UmwandlungsenthalpieProdukt <Mathematik>SummengleichungBildschirmmaskeRechter WinkelRandwertWort <Informatik>SoftwareWasserdampftafelAdditionDatenbankGamecontrollerBenutzerschnittstellenverwaltungssystemMessage-PassingThumbnailSchaltwerkKlasse <Mathematik>LoopWellenpaketResultanteZählenBiegungGüte der AnpassungSoftwareentwicklerCASE <Informatik>SoftwaretestEDV-BeratungDomain <Netzwerk>ExpertensystemCodeEinsIterationSchreib-Lese-KopfPunktFehlermeldungData MiningFigurierte ZahlBildgebendes VerfahrenRechenwerkSchlüsselverwaltungSpeicherabzugMinkowski-MetrikStellenringGlobale OptimierungHyperbelverfahrenFitnessfunktionVektorpotenzialZentrische StreckungProfil <Aerodynamik>KoroutineFunktionalParadoxonElement <Gruppentheorie>Knoten <Statik>Automatische HandlungsplanungSpielkonsoleMathematikProgrammiergerätTrennschärfe <Statistik>ProgrammierungOrtsoperatorRichtungRelationentheorieAnalysisDiagrammHilfesystemAnfangswertproblemVirtuelle MaschineUltraviolett-PhotoelektronenspektroskopieAuflösung <Mathematik>Vollständiger VerbandWeg <Topologie>BitLesen <Datenverarbeitung>AggregatzustandQuellcodeZellularer AutomatInstantiierungHinterlegungsverfahren <Kryptologie>EreignishorizontMusterspracheRückkopplungAutorisierungGesetz <Physik>Kontextbezogenes SystemKurvenanpassungNeuroinformatikMaterialisation <Physik>GraphfärbungEinfach zusammenhängender RaumSoftwarewartungCodierungFaltung <Mathematik>Nichtlineares GleichungssystemStrömungswiderstandWeltformelMeta-TagBetrag <Mathematik>Luenberger-BeobachterComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:01
The time has arrived. Thank you for coming to my session. My name's Esther Derby, and I'm here to talk to you today about self-organizing teams, what it really means. How many of you were in Mike Cohen's session on leading self-organizing teams? So some of you were. Okay, I have a little different take,
00:20
so you might hear some different things. That's okay, there's more than one way to think about things. I wanna start by asking a question. How many of you have been on a really fabulous team?
00:40
Yeah, so just take 10 seconds and think about what it was like to be on that team. And now tell me, in a word or two, what were some of the characteristics about those fabulous teams that you've been on? Just a word or two.
01:04
Yeah? Recommendation? Oh, communication? So it was helpful, there was good communication. There was motivation. Self-contained. There was a lot of cooperation. It was fun!
01:22
Who else has a word about one of these great teams they've been on? Any other words? Ending with fun is not a bad word. Most of us who have had one of those team experiences always want to return to it, because it just is a fabulous way to work.
01:43
I mean, you go in every day, and you have ups and downs, but you're generally energized, and you find you can do more than you could on your own. It's one of those experiences we always wanna go back to. Making a team is not a random event.
02:03
On the other hand, there are no guarantees, but there are some things we can do to make it more likely that the patterns of self-organization, and the pattern that we described within this group, where we have good communication, motivation, fun, or helpful to each other,
02:21
where all of those words play out. There are things we can do to make that more likely to happen. So that's part of what I'm gonna talk about today, is how can you create the conditions for self-organizing teams? What it means to managers, what it means to people on the team
02:40
to be part of a self-organizing team, and then just a couple of words about coaching, because within the Agile world, there's a lot of emphasis on coaching. So I wanna say a little bit about how that plays out with self-organizing teams. Sound like a reasonable way to spend an hour? Yeah, okay. How many of you have had this experience
03:03
when you start a team? We're self-organizing. We don't need no stinking managers. Does that ever come up? Yeah, there's a myth about that,
03:21
that teams don't actually need managers or management. They actually need both, but in very different ways than we're used to. So let's talk about an interesting set of numbers. What comes to mind when you see these numbers? 60, 30, 10.
03:47
Any guesses about what these mean? They're percentages. Yep, absolutely. Any idea what they refer to?
04:02
This comes out of the work of a guy named J. Richard Hackman, and they reflect the percent of variation in a team and the sources of those variation when you look about team effectiveness. So 60% of the variation in team effectiveness comes from the way the team is designed.
04:24
And when we're talking about designing, we're talking about how the team is selected, and there's lots of ways to select team members. We can appoint them using the five use method. Does anybody know the five use method of selecting a team? I bet some of you experienced,
04:41
it goes you, you, you, you, you're a team. That's not a good design principle, but there are many other ways to do it. You could self-select, you could use a process that's much like hiring. There's various ways to select a team. So that's one aspect of it.
05:00
Thinking about the goal is another aspect of it. Thinking about the space the team will be in. All of these things are aspects of the design of the team. So that's 60%, 60% of the variation. The five use method does not help very much when we're looking at design of a team.
05:22
Where do you think most of the time gets spent in a typical organization on helping a team excel? What would your guess be? Any guesses?
05:44
In many organizations, most of the emphasis on helping a team succeed goes into coaching. So which one of those numbers do you think is related to coaching? 10, right, right. 10% of the variation is accounted for by coaching.
06:01
The 30% refers to how a team is launched and how they're brought together and how the issues are presented to them and how they go about narrowing the gap between their understanding about what their task is and how they go about figuring out how are we gonna make the best use of our diverse skills and what are our diverse skills?
06:24
That accounts for 30% of the variation. And those are two of the big issues in any self-organizing team, which is what are our diverse skills? Because skills that are not held by the majority of the team members very often are not taken into account.
06:45
There's some research that shows that people who have divergent knowledge have to bring that to the table 20 to 30 times before it gets heard. So the ability of a team to take advantage of all of the knowledge that's contained in the team is critical and that's often established
07:01
in the very early stages of a team. These critical initial conditions make a big difference. Also the agreements the team makes on how they're gonna work together often happen at the inception of the team and of course evolve over time. But that makes a big difference too
07:22
about how the team's gonna work. So the design of the team counts for 60. The way the team is launched and the way their first interactions happen accounts for 30% of the variation in terms of team effectiveness. Is that number surprising to anyone? No?
07:42
Okay, well, given what I see in the US and the way people treat teams, this number surprises a lot of people. So this is good to hear that this is not surprising here in Norway. Okay, so something changed order but that's okay.
08:09
We've talked about the design. Part of what goes into a team being successful is not just who's there but how they have enabling conditions. So enabling conditions have to do
08:20
with having information about the task, having information about the context that they're in, so the big picture of the work they're doing so they understand how their work fits into the overall picture of what the organization is doing. Having access to outside expertise because even though you try to have a cross-functional team
08:41
there's almost inevitably something that they don't know and rather than always disbanding and forming teams in the effort to get the perfect team it makes more sense to have a team stay together and then have access to outside expertise for issues where they may not have the particular knowledge or skill that they need.
09:02
The third pillar which I am doing in a different order is material support which means that they have access to the right materials, the right computers, the right space and all of those material things that enable them to do their work. And finally a connection to the organization which you can think of as a feedback loop
09:21
that keeps them aligned with what the organization needs them to do. So in Agile that's often the product demo that happens at the end where folks get together and show the product to the customer so that they can stay aligned with what the company actually needs the team to do.
09:42
So those are the enabling conditions, those are part of the design work, part of the design work for the team. And of course we have to consider that we have a real team. It's very often all sorts of groups of people are called teams whether they actually meet the characteristics of a team or not.
10:02
One of our American presidents once said, you can call a tail a leg but that doesn't mean you have a five legged dog. So you can call any group of people a team but that doesn't mean they are an actual team. They have to have a handful of characteristics which are that they have interdependent work.
10:26
So that's not that they are each doing their own work and somehow the sum total of that adds up that their work is interdependent on a day to day basis that they are mutually accountable and mutually responsible. So it's not a matter of, well, if you get your work done
10:42
then the devil take the rest. They are mutually accountable for the success of the whole team. They all fail or succeed together. They have complimentary skills. So there may be some overlap but each person has unique skills.
11:00
There's a lot of talk in the agile world about generalizing specialists and specializing generalists. It's not the goal that everybody have exactly the same set of skills or everybody can do every job but that they are complimentary and the collection of the skills is sufficient to do the work at hand. And again, you may need access to outside expertise
11:21
because you're never gonna have the perfect team. So that's important to consider but complimentary in general. Small in size. How many of you are on teams of three people? Yeah, that's kind of the minimum to have any sense of teaminess. If it's just two,
11:41
it just doesn't feel like it's a team generally but when you have three people, you can feel like, well, some other people have my back, we have a different set of skills, we have different viewpoints, we have a mix here that we can bring together in different styles and different knowledge. How many of you are on teams bigger than 10?
12:01
Yeah, just a couple. When you have more than 10 people, it tends to break down into subgroups either because the work naturally breaks down, the work is big enough that there's a natural breakdown in the work or because the communication overhead is just too big to keep going with that number of people.
12:22
So it'll break down either on the basis of the people who have similar work if you're lucky or if you haven't thought about it enough, it will break down on the people who are friends or who see other people as enemies, it'll break down on some random fracture line which may not be helpful to the team.
12:40
So when you get more than 10, it tends to break into subgroups, less than three doesn't feel like a team and according to some research, five, five is the ideal number of people on a team. How many of you are on a team of five? Yeah, a couple of you. The number five comes out of research again from Hackman
13:02
that says, in theory, each person you add brings more capacity. However, each person also adds to the process overhead in terms of coordinating communication, in terms of maintaining relationships,
13:21
in terms of how do you pass knowledge through the group. So at five, the process overhead starts to cancel out the theoretical capacity of another person being added to the team. And the more people you add, the actually, the less you are able to take advantage
13:40
of that theoretical capacity. So five, according to some research, is the ideal. Not every team can be that. Seven, nine, they're usually reasonable. So somewhere in that range, seven plus or minus two contributes to having a real team. I wanna go back to the goal for a minute
14:00
because that's an essential characteristic of a team. It's part of the design, but it is so central to a group being a team because I have never seen a group succeed if they didn't have some sort of compelling work goal. And I have seen groups do amazing things when they do have a compelling work goal.
14:20
This is something that we often don't pay a lot of attention to when we're putting groups together. We give them something like, oh, go do maintenance. How compelling is that? Write this feature. How compelling is that? It's not very interesting. People don't get engaged in it.
14:40
Goals that relate to how we're going to make life better for some other people tend to be more engaging. So if you can frame the goal for the team in terms of how we are gonna make life better for some other group of people, that's more likely to engage people and tap into their intrinsic motivation.
15:01
Now, we have a tendency to over-specify goals. So it must do this, then X, Y, Z, A, B, C, Q, R, S, and we add on conditions and conditions and conditions until there's not much room for creativity left. So there is an art to coming up
15:22
with the minimum specification for the team's goal that allows them to really take advantage of all of the diverse skills they have and make the most use of their creativity. So minimum specification and the thou shalt nots.
15:42
So the goal forms a sort of boundary and thou shalt not sets out the unacceptable solutions and the behavior and the solutions that are unacceptable. So that's an equally important part of setting a goal for a team. Because one of the most demoralizing things
16:01
that can happen to a team is that they're given a goal and they go off and do something and they think it's wonderful and they bring it back and the customer or their manager says, oh, well, anything but that. That's demoralizing. So the unacceptable solutions are equally important.
16:24
One sort of silly example, well, it's not silly, it's actually an interesting example that I do some work in a workshop called problem solving leadership. And one of the things we do there is we design an exercise, we have teams design an exercise for another team to solve.
16:42
It's an exercise in delegation. And one of the thou shalt nots is that the exercise that you give this other team should not include killing anyone. Because one time a group came up with a design that said, well, we're going to pretend
17:02
that we have this terrible virus and everybody's affected and we can only cure three people and you have to decide who's gonna die. So that was clearly an unacceptable solution because it brings up too many horrible things for people to deal with. So thinking of the thou shalt nots is equally important
17:23
as to thinking about what is the goal and what we're trying to accomplish. Who are we making life better for? I'm gonna skip that one. One of the things that we run into when we try to have self-organizing teams
17:42
is a dynamic that exists in many organizations where the managers are looking down to the team saying, you need to get some stuff done. You're empowered now, you're self-organizing, you need to make decisions. And the team is looking back up at the manager saying,
18:04
I wonder if he really means it this time. Last time they told us we were empowered, it only lasted for about six weeks. Does anyone ever, does that sound familiar to anyone in this group? You've had that experience?
18:21
It's very common, it's very common that this dynamic is in place and this is something that we need to work against when we're moving into working with self-organizing teams. Because it's present and if we don't acknowledge it and take some steps to counteract it, then we'll run into problems.
18:42
Because the manager will say, you're empowered, make this decision. And the team will either be wondering if he really means it or they may not know how to do the decision or do the task that the manager has delegated to them. And the manager will be getting impatient and tapping his foot and the team will be saying,
19:02
and sooner or later the manager gets frustrated and steps in and then they say, see, it's just like last time, he didn't mean it. So we need to attend to this dynamic. And there's a couple things we can do about that as part of designing a team and launching a team.
19:21
One is to be clear about what is the mix of technical and management work that people are taking on. How much self-management are they actually taking on when they become self-organizing? Many teams and manager-led teams are way on this end of the box. So they have a lot of technical work and not much work that's involved with self-management.
19:45
That doesn't really allow them to take advantage of their creativity. It doesn't allow them to reach the surpassing results. It doesn't create the sort of fun team where there was good communication and people took self-responsibility and they were collaborative and helpful that we talked about at the very beginning
20:00
when you told me about those teams. Nor do most teams want to be at the other end where they're doing all management work and not much technical work. I talked to one company where they had spent millions and millions and millions of dollars getting their teams to be completely self-managing. So they took on all management work.
20:21
And they were doing so little technical work that many of them started leaving because they hadn't come there to do management work. They'd come there to do technical work. And eventually someone noticed that there was this huge amount of turnover and said, well, why are you leaving? A lot of people are leaving to go work at this company that's really top-down and control-oriented
20:41
and you're gonna be under your boss's thumb. Why do you wanna do that? And the people said, well, at least we'll get to do the work we really are trained to do and we love to do. So we'll put up with a boss but we'll at least get to do work we like. So there's a balance in here. There's always a balance in here when you're looking at creating a team
21:02
that's really going to be excellent, that's gonna do excellent work and it's gonna be a... Did I get too close? Is it okay now? Sometimes when you stand too close to these, they make horrible sounds. So I'll try not to do that again.
21:22
Okay, my brain just rebooted. What was I talking about? Oh yes, the company that that pushed people too far to that end of the box where they were doing too much management work. It's always a balance, right?
21:40
You wanna create a relationship where it's partnership, not all of the management shoved onto the technical teams who are trying to actually produce software and not all of the management and self-management kept by the manager, right? It needs to be a partnership that shares power.
22:04
And part of how we can look at that is by being careful about how we delegate decisions and being clear about which decisions belong to the team, which decisions stay with the manager and which decisions are shared.
22:23
This is one of the areas where teams often get into that looking up and looking down cycle where the team will believe that they have been delegated a decision and they'll make a decision and then the manager comes back and says, no, you can't do that. Which sets that dynamic up and says, you really didn't mean we're empowered. You told us we were empowered, you didn't mean it.
22:43
And that shuts down the team. So being clear about this is very, very helpful. And I generally do an exercise when I'm launching a team, this is part of that 30%, the launch, that says, let's look at the sorts of decisions that typically happen and we'll figure out
23:01
and we'll come to an agreement about, you know, which ones the team can take care of within some boundaries and within some thou shalt nots, which ones are shared, where we're going to make the decision together in various ways and which ones stay with management. So who can give me an example of a decision
23:21
that would most likely rest completely with the team within some boundaries? Anyone?
23:49
So you think that should be a team decision? I think that's a great decision for a team to make. And I think in many organizations
24:01
it needs management support. But that's a very interesting one because if you tell a team, I want you to learn and improve, but then you don't give them any time to do research, you're sending a contradictory message, right, which sets up that cycle again of oh, you don't really mean that. Yeah, so that's a reasonable thing for a team to decide.
24:21
What might be a shared decision between the manager and the team?
24:46
Hiring often falls in this one as a shared decision. I think it's really critical for the team to have a very big say in who comes on to the team.
25:01
They may not make the final arrangements with HR, they may not make the final salary decisions, but they should be involved in deciding what sort of skills we're looking for, what are the interpersonal characteristics we're looking for. They're involved in interviewing candidates
25:21
and might be involved in pairing auditions with candidates because after all, they're the people who have to work with this person. So it's important that they have a vested interest in making this person, helping this person work, work out on the team. Because when the manager makes the hiring decision alone,
25:42
he's the one with the most vested interest in this person succeeding. And it's very easy for the team to say, not our fault, you stuck us with this bozo, your problem. So I think that's a critical shared decision. I think that's really critical as a shared decision
26:00
if you want a team to self-organize and be self-responsible. Decisions, I think budget decisions can be shared. I think how the training budget gets spent should stay with the team. I think that's an important one to stay with the team
26:21
because that's another one where you can send a very mixed message to a group when you say, we want you to learn and improve and you have a training budget, but then when you select a class, you must come to me and get approval. I talked to one guy who took his boss to heart
26:40
when they delegated the training decision and selected a course he thought would be very useful and he had to go to his manager for approval and says, well, his manager said, no one in our company has taken that class, how do we know it's any good? And so the guy went back and did some research and brought that back to his manager and he says, well, you must take it to HR now
27:02
and have it vetted by HR. And he had it vetted by HR and then he had to, and finally he just said, no, I'm not gonna work to get myself to this class anymore because clearly you were not being honest when you told us that we had responsibility for the training budget.
27:22
So when you delegate some decision like that, the money has to go with it because it's a very confusing message to send to a team to say, you're empowered, you're self-organizing, you take responsibility for your improvement but then you have to come to the manager on Bended D.
27:40
So looking through these decisions is a very important thing to do and talking about where they're gonna be because that eliminates some of the tendency for that cycle of looking up, looking down to kick in. You guys have invisible fence here, do you guys know what that is? Any dog owners in the room?
28:02
Yeah, well in the US they have this thing called invisible fence, which is actually a terrible thing but they bury electric wire in the ground and then the dog wears a collar so that if he goes across this line, he gets a shock.
28:24
And the theory is that then the dog will learn to stay in his little box. I don't recommend it, it does exist. But if you don't, as a manager, if you're not clear and you don't negotiate with the team
28:42
what the decisions are, the team ends up feeling like, if we step over this line, we might get shocked and we don't know exactly where the line is buried because it can move all the time. And if the team has that experience often enough of crossing a line they didn't know exists,
29:01
eventually they stop making any decisions that paralyzes the team. So this is a critical, critical part to launching. Okay. Within the team, for the folks on the team, there are some balancing acts that always take place. And Rachina Hoda, who did her PhD research
29:23
on self-organizing agile teams, was the first that I know that named these, but they do ring true to the teams that I've seen and I've worked with. So the first is balancing learning and delivery, which goes right to the point that you mentioned, that if you really want a team to learn and improve,
29:43
you have to balance learning and delivery. So if you say you want the team to have retrospectives and come up with actions to improve, but then you never leave any room on the plan for those pieces of improvement work to be done, there's no room for learning.
30:01
On the other hand, they can't be learning all the time, there's still a need, you're still a business, you need to keep the delivery in mind. So that's a balancing act that plays out for members on the team. They're always looking at that balancing act. If you don't have learning, for most people, it gets to be sort of boring to be on a team.
30:22
That's a critical part of being on a team, is the ability to learn and the ability to learn together. That's really one of the core improvement, units of improvement for a team. Jerry Weinberg did research long ago that showed that the possibility for improvement,
30:42
if you didn't have some structured way to look at it within a team, was essentially random. But if you did have some structured way to look at improvement and you built the time for that, that was a critical unit of improvement within an organization, was improvement within the team. Their ability to learn together, to think together,
31:00
to take on new skills. And later research has confirmed that teams do learn to learn together over time. So critical balancing act, something to pay attention to. And as managers, going back to the manager's role, supporting that ability by protecting some time for the team to spend on learning
31:20
and improvement activities. Specialization versus our work, my specialization versus our work is another critical balancing act. And this goes back to the cross-functional skills and making sure that people are making use
31:43
of the diverse skills within the group, within the team. I worked with one group not too long ago who the testers were still very much in I do testing. And the developers were still very much in I do development.
32:01
And so they would get to the end of their iteration and the developers would be done, done, as in it works on my machine and I didn't find anything that broke. And the testers would still be testing. So their work would slop over into the next iteration.
32:22
So it would often be three or four iterations before they actually knew that something was done. So what we did with that group was we looked at what's our shared definition of done. And if the development is done, but the testing isn't done, it doesn't count for done. Right, so that's part of balancing what my specialization
32:41
is versus our work and our goal. Our goal is to deliver this feature, not my goal is to get the development done and if the testing isn't done, well, it's not my fault. If the testing isn't done, it's a failure of the team. Right, so balancing my work versus our work,
33:02
balancing my specialization versus the needs for all of us to get our work done. Actually, I spoke to someone yesterday who was saying, you know, we have a bunch of new guys on our team and they don't understand the domain and some of them are just learning the technology,
33:20
but the experts, our senior guys, don't wanna work with them because it slows them down. So the senior guys are doing their work and being really productive and half the team is sitting there unable to do anything. So this is another one, my specialization versus our work.
33:43
Yes, personally, you might go slower if you're helping the new guy, but as a team, you're developing the capability to speed up and so as a team, you're developing your capability, you're bringing everybody up, you're allowing people to be productive who weren't productive before. It plays out also in terms of specific skills,
34:04
like well, I'm a database guy, you're not a database guy, so all database work has to go through me which creates a bottleneck. You know, this guy might be able to do some database work, maybe not as fast, but he'd learn if the work were shared. So over time, over time, there's a diffusion of skills.
34:28
So people may not become as good a database program or as good a UX program or whatever, but they gain some skill in that and having that redundancy creates flexibility in the team
34:41
and allows them to respond more effectively to challenges. So it's a balancing act and if you keep it in balance, it creates more capability for the team over time. Flexibility leads to speed, flexibility leads to better decisions, and allows the company as a whole
35:02
to be more flexible in how they do work. The third balancing act has to do with autonomy and responsibility. Self-organizing teams, agile teams, are given a lot of autonomy,
35:20
but they also have responsibility. This ties back to that first picture of, well, we don't need no stinking managers, leave us alone. Well, you may not need the same kind of manager, but you still are a team within a context and you're responsible for producing a product. Responsible for producing a product
35:41
that's valuable to the company, that's paying your salary. So there's responsibility that goes with that to be checking in with the customer, to be developing valuable software that goes along with the autonomy that you're given. Being clear about the decision boundaries helps this one.
36:02
Having those robust feedback loops with the organization helps this one, making sure that you're tied back to the organization. I talk to all sorts of groups that do all sorts of sort of silly things. They're really smart people, but they end up doing these silly things.
36:21
So it's not that I think people are stupid, it's just these are the stories that I get to hear. Silly things that happen. So I talked to one group that the managers were just, they were beside themselves. They didn't know what to do because they had set up a self-organizing team and the team had been working for two years
36:43
and hadn't produced one single bit of software. What do you think I told the managers to do? Get in there right now. So this team had gone way too far on the autonomy side.
37:07
They had said, we don't need no stinking managers, don't bother us, leave us alone, we're working. We'll show you when you're ready. And that went on for two years. So they had ignored the responsibility
37:23
part of this balancing act. And their managers had fallen into the trap of saying, oh no, we don't want to interfere. Which leads us to the managers balancing act, which is when do you step in? When do you step in?
37:42
It's possible to step in too soon, which kicks in that loop of the manager and the team and the team saying, well, he didn't really mean it when he told us we were empowered. Or you can wait too long, in which case the team feels like they've been abandoned.
38:02
I talked to one group who, they had a person who their manager had stuck on the team without any consultation. And it turned out that the guy didn't really want to follow any of the shared approaches that the team had agreed to.
38:21
And they did their best to kind of bring him along and say, well, this is how we work here. And we have a stand up every day and we talk about what we've been working on. So they'd have a stand up and everybody would go around the room and say, I've been working on this feature, I've been working on this story, I'm running into this problem. And the guy that the manager had stuck on the team
38:40
would say, I'm coding. They'd say, well, what are you coding? I'm coding, leave me alone. So this went on for a while. They tried to bring him into the fold. And finally they said, we never know what you're doing so don't take any of these stories
39:03
because we need to know where they're going. And so he would surreptitiously take stories and he would take the code and lock it on his own machine so no one else could see what was going on. They did everything they could think of and they finally went to their manager and said, we've tried everything we know how to do.
39:23
And we can't, you know, this guy that you brought to our team, he won't work. You know, he goes off and he does things that take weeks, we don't know what's going on, he doesn't come to our stand ups anymore, he threatened to slap one of our team members, which he really did, he threatened to slap her.
39:43
She'd had some dental work done and he said, well then you won't even feel it, you've had Novocaine so I can slap you all day. This is kind of bizarre behavior. So they went to their manager and the manager said, well, you're self-organizing, it's your problem, solve it.
40:01
They felt abandoned, right? So there's a balancing act for managers to know when to step in. And there are ways to go about it. You can always ask if a team needs help. You can always bring the team back to the purpose. You can always reiterate what the goal of the team is
40:22
and say, how do you feel you're doing on meeting that? Do you feel like you're tracking? Let's look at the evidence. You can always do that sort of thing because sometimes that sort of feedback loop resets the team and helps them re-energize around the goal and the purpose that they're supposed to do. You can always state what you're observing.
40:41
You know, it seems to me that, you know, you guys are struggling on this and you've been churning on this decision for a while. Here's the implications of not making the decision. Here's some ways I can help. Would that be helpful to you? At a certain point, if the team doesn't respond to that suggestions, then you can be a little more forceful, right?
41:01
But if you start from a directive position, if you start by saying, get with it. This is what you're supposed to do. That kicks in that dynamic again. That kicks in the looking up, looking down dynamic. And again, reinforces to the team that you didn't really mean it when you said we were empowered and self-organizing. So we're going to be paralyzed.
41:22
So that's a balancing act that takes some discernment. Okay, something about coaching. How many of you have coaches on your teams? On your teams?
41:43
Anyone? One, one. Okay, are these coaches that stayed with the team for a long time? Yeah. So when you think back to the 60-30-10, 60% of team effectiveness is related to the design, 30% to the way they're launched,
42:01
10% to coaching. But what this diagram says, what this, this is from, again, research from Hackman and one of his colleagues, Wajeman, that if you have a well-designed team and you have effective coaching, it can really help.
42:24
If you have a poorly, if you have a well-designed team and you have poor, all right, let me do a little reset there, if you have a well-designed team and you have poor coaching, it might help a little.
42:43
If you have a poorly designed team and you have ineffective coaching, it's going to hurt a lot. And even if you have good coaching, it's not going to be very effective. So design is everything, right?
43:02
Design is 60%, you need to really pay attention to those initial conditions for the team so that if you have coaching, effective coaching will help the team. You can have a great coach and if you have a poorly designed team, they're not going to be able to make a lot of difference.
43:21
And the first thing that coach should probably be doing is revisiting the elements of design and making sure that those design elements are in place. There's also a paradox of coaching that came up once again for me just a couple of weeks ago when I talked to one of the teams I had worked with.
43:45
And they said to me, we couldn't have done it without you and we couldn't have done it with you. So I had spent some time with this group
44:01
in their initial conditions. I spent some time with them, helping them understand the tasks that they were working on, looking at the goal, looking at the shouts and the shout nots. I spent some time with them, helping them figure out how they were gonna work together. I spent time with them, helping them to self-observe
44:21
what was going on in their team so that they could do some diagnosis of what was going on and make some changes within their team. I let them know something about the pitfalls and then I went away. And I heard later about all this drama that happened on the team while I was away.
44:42
And then I saw their result and their result was fantastic. They really did a fabulous job. And this is what they said to me. That initial setup was crucial to them. They couldn't have done it without that initial setup. But if I had stayed there the whole time,
45:03
they never would have gone through some of that drama they needed to go through to really form as a team and figure out their relationships and figure out how to work together. So they needed both. They needed me there to help them with the initial conditions.
45:22
They needed some space to figure out how to work together and how to be a team. Because essentially, and in the end, if we want a self-organizing team, we have to set the initial conditions. And then it's up to the team
45:41
as to whether they're going to really self-organize and produce and work together as a team. When we come right down to it, self-organizing really means that the team is capable of coming up with new responses and new routines based on the challenges
46:00
that they're experiencing. That depends on the initial conditions that we set for the team, how we help them understand their goal, how we help them take advantage of their diverse skills, how we help them have a process that is robust
46:21
and that will enable them to make decisions. It depends on how we clarify as managers how we're going to work with the teams. Doesn't need to be the manager who initiates that, a team member can initiate that. Any team member can say, well, let's talk about what sort of decisions we make and how we're going to make them.
46:42
Because we don't want to step on your toes. We want to know what we can do so we can do a good job without feeling like we're going outside our boundaries. That negotiation can start from either side. We need to help the team understand some things
47:03
about how they're going to work together. We need to make sure they have access to outside expertise. And then we stand a chance, no guarantees, but we stand a much better chance of having a team that's going to really produce the experience that we talked about of being fun, of being helpful, of having great communication,
47:23
of producing great results. But we stand in uncertainty. I think it's worth investing the 60% in design and the 30% in launch to give a team a great chance. Because that is when work works really well,
47:40
it's almost always because of teams. So how many of you have questions at this point? Who has questions? Yeah, so the question was,
48:01
if you have a team with a Scrum Master, is that part of the team or part of the manager? It's a tricky role. And because the Scrum Master's role is to help the team follow a process and help the team self-observe, they are by definition sort of out of the team,
48:22
because they're working on the meta level. And anytime you have a team and one person goes meta, and the other people don't, that, whether it is named that or not, they feel like they're someone not in the team.
48:40
So in your case, is the Scrum Master also writing code? Yeah, so he's not writing code. So he's not mutually accountable in the same way that the other team members are. So that goes back to the definition of the team, right? That they're mutually accountable to each other and they make commitments to each other.
49:01
The Scrum Master has a different sort of role in that he's not making commitments to doing work within, to create the product. The role is of the team, but not in the team. Most Scrum Master's don't have management authority,
49:23
so they can't negotiate what the decision boundaries are. They're there in a role that doesn't fit either of those and spans both of them in that they are in a position
49:40
to help the team because of their observations, if they know something about team dynamics and a position to help the team make the best use of their resources and make good decisions about their group process, if they understand group process. If they only understand the rudiments of Scrum,
50:01
then that's the only thing they can help with. So they're in a netherworld there in between. Did that answer your question? Yeah, okay. Other questions, yeah.
50:45
So how big is the company? So the question was if you have two self-organizing teams and they're starting to make decisions, two or more, that are starting to make decisions that affect the company work process, how big is the company?
51:01
That's a theoretical question. Well, you know, a lot of companies have the company process. Well, actually what they have is they have the company process document, right? And I think expecting every team to follow a rigid prescribed process
51:25
is in some ways an exercise in futility and in some ways is a detriment to the ability of the team to self-organize. So it depends on what level that definition is. I mean, there can be some core agreements as a company
51:42
about how we act and what our process is as it relates to our ability to deliver value to our customers. As it relates to the day-to-day work of the team, if they wanna come up with a process that is most effective for them,
52:01
as long as it does not make someone else less effective, I'm fine with that, right? I don't think every team has to hue to the same process or stick to the same process because they're working on a different problem, they've got a different group of people, they're under different conditions in various sorts of ways.
52:21
So it seems normal to me that they would develop their own unique way of dealing with the situation. Otherwise, they're not taking advantage of the skills they have. The key is, is it making it harder for someone else to do their work? That's another question of local optimization versus global optimization. So did I answer your question? Yeah. Okay.
52:41
Other questions about this curious thing called the self-organizing team? Oh, I'm sorry, I almost didn't see your hand.
53:25
So the question is, so if you're putting together a great, you know, you're putting together good teams, you're trying to pay attention to the design of a team, and you've found a place for all of the people who are the good performers,
53:41
and then you have some people who are not so good, what do you do with them? First, I try to get really curious about why they're not so good, right? Because presumably, when you hired them, you hired them because they were a good fit. That's what I presume, right?
54:02
And so then I try to figure out why have they, you know, why have they not lived up to what was perceived as being the potential? Were they, you know, are they lacking some key skills? And then can we get them the skills so that they will be contributing team members?
54:23
Do they, you know, some people just aren't cut out for teamwork. So if you get people who just absolutely, positively cannot work on a team because of their interpersonal skills or their psychological profile, you know, then sometimes there's work
54:42
that can be done by, you know, a single person. And I might try to find that sort of work. If they've just been having a, you know, a negative experience or they weren't engaged in their work because the goal was stated in such a way that no one would engage in it, then I might give them a try on a team.
55:03
I think it depends on precisely what the issue is and if I feel like they can still provide some value in one of the teams and not be destructive to the team.
55:26
So the second part of the question is, should they raise their skill levels before they go onto a team or do it as part of a team? I would say do it as part of a team because people just learn better when they're actually doing something that makes sense.
55:42
And then you have to take that into account when you are looking at what you expect the team to produce because they will, you know, a learning curve always takes time and it will, in the short term, take some time for the rest of the team.
56:01
There's a woman in the US, Nancy Von, this long Dutch name that no one can pronounce so we just call her Nancy Van S. If there's anyone Dutch, they might be able to pronounce it in the room. She took a team that had been identified as the losers,
56:22
you know, it's like here Nancy, you get this team that's the losers. She says, oh joy, oh happy day, I get that. But she decided to not look at them as losers and she's slowly but surely introduced all of the XP practices to them and they actually ended up doing great stuff.
56:42
They ended up actually doing really good work. So there was something else going on with that team and I've seen that happen more than once. There are people who should not be employed in your company. Maybe they should be employed for the competition. And I don't know how difficult,
57:02
excuse me, I don't know how difficult it is to actually go through the process of terminating employment in Norway. Some extremely difficult. Well, and sometimes I think even though it's extremely difficult, that's what you have to do.
57:22
Because he was fired, but it was a U.S. company.
57:41
So, excuse me, can I get you to turn this off for just a, thank you, you didn't want to hear me cough in your ears and magnified, did you?
58:37
I hope I'm okay. Right, so this is not a defense
58:40
against difficult questions. The thing you have to be careful about with these folks who just, for whatever psychological reason, can't work, is that not giving them work is such an assault to their self,
59:02
their sense of self that I know of at least one instance where someone was very, very difficult and so they denied him all work. They just said, you go sit on that desk over there and don't do any work. And he committed suicide. So, it's a tricky thing, right?
59:21
Because you don't, software development is too hard to have someone on your team who is acting as a boat anchor, right? And just arguing all the time and holding the team back. On the other hand, you know, work is really associated with self worth, so you have to figure out a way to work it. And sometimes the best way is to deal
59:41
with the really difficult thing of getting someone out of your company. I assume it costs money to do that, money and management time, and there's a trade off between how much drag it is putting on a team, how much lost productivity.
01:00:00
you have because of this versus what it takes to actually terminate employment. And if you look at the impact on the other team members, it's very often an equal equation. Plus it depresses the morale. So once you make the move, the morale often goes up. So, but again, I am not familiar
01:00:21
with the Norwegian employment laws. So that's the best I can offer you. All right, other questions? Yes.
01:00:54
I think it really depends on the situation of the team.
01:01:00
So I think it's helpful for a coach, for them to have a coach when they start. I think it's helpful for people to have a coach if they have a fairly large group and they need to make decisions because they'll need facilitation. I think it's helpful for a team to have a coach if they are taking on some new processes
01:01:21
or a new skill, a technical skill. I think it can be helpful when they've done some retrospectives and they want to make a significant change. That's my experience. The research I've read about this, which again comes from these fine folks,
01:01:44
says that the most effective coaching happens during launching when you're getting them started and then about halfway through their work together because they've done some things together and they've had a chance to work together and they might have a better idea about where they want to make some changes. Coach is very trendy in the U.S. too.
01:02:02
And I think one, you need to be real clear about what sort of coach you need for what team and do a job analysis so you pick the right person for the right team.
01:02:21
So thank you for coming for my talk. And I think it better be over now because I'm just coughing.