Your Path through Agile Fluency
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 |
| |
| Serientitel | ||
| Anzahl der Teile | 150 | |
| 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/51432 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
NDC Oslo 2013108 / 150
3
4
5
6
8
11
12
15
17
22
26
27
31
32
39
40
41
42
44
47
51
53
56
57
59
60
61
63
64
66
67
68
69
71
72
79
80
81
82
83
85
87
89
90
93
94
95
97
98
99
100
101
102
103
106
108
109
110
114
118
119
120
122
125
126
130
132
133
134
135
136
137
138
139
140
141
142
145
00:00
Formale SpracheNatürliche SpracheNatürliche ZahlSelbst organisierendes SystemProgrammierungEDV-BeratungMAPGenerator <Informatik>GruppenoperationMomentenproblemProjektive EbeneE-MailQuick-SortSystemaufrufFamilie <Mathematik>Prozess <Informatik>DruckverlaufDatenfeldAlgorithmische ProgrammierungStrömungsrichtungArithmetische FolgeWort <Informatik>HilfesystemFokalpunktEuler-WinkelDifferenteAutorisierungsinc-FunktionMultiplikationsoperatorZweiSoftwareentwicklerZentrische StreckungE-MailElektronischer DatenaustauschCoxeter-GruppeWeb logTwitter <Softwareplattform>UMLXMLComputeranimationBesprechung/Interview
08:15
DatenstrukturDatenverwaltungFormale SpracheOrdnung <Mathematik>PerspektiveComputerarchitekturRückkopplungSoftwareProgrammierungVerschiebungsoperatorEDV-BeratungIterationWellenpaketMAPProgrammiergerätKalkülProzesssimulationTermZahlenbereichVerschlingungQuick-SortBildverstehenAutomatische HandlungsplanungBasis <Mathematik>Zusammenhängender GraphDruckverlaufDatenfeldOffene MengeArithmetische FolgeUmsetzung <Informatik>Spiegelung <Mathematik>Web SiteEndliche ModelltheorieElektronischer ProgrammführerMultiplikationsoperatorSoftwareentwicklerGeometrische FrustrationCodePerspektiveVerschiebungsoperatorGebäude <Mathematik>Rungescher ApproximationssatzGlobale OptimierungRechenwerkArithmetische FolgeFokalpunktWechselseitige InformationTuring-TestComputeranimationFlussdiagramm
16:25
CodeMathematikNatürliche ZahlOrdnung <Mathematik>SoftwareMAPProgrammiergerätPhysikalische SchichtMultiplikationsoperatorEinsCodePerspektiveGebäude <Mathematik>Arithmetische FolgeFokalpunktComputeranimation
19:15
CodeDatenbankMathematikSoftwareStabVerschiebungsoperatorProdukt <Mathematik>WellenpaketMAPProgrammierumgebungMereologieMultiplikationProzessautomationSpeicherabzugQuick-SortVersionsverwaltungProgrammfehlerSoundverarbeitungDifferenteTest-First-AnsatzMultiplikationsoperatorRefactoringFigurierte ZahlSoftwareentwicklerCodeDatenstrukturPerspektiveVerschiebungsoperatorGebäude <Mathematik>Produkt <Mathematik>EntscheidungstheorieGlobale OptimierungArithmetische FolgeFokalpunktMotion CapturingTuring-TestComputeranimation
25:21
DatenstrukturDatenverwaltungMathematikPerspektiveSelbst organisierendes SystemSoftwareExpertensystemVerschiebungsoperatorProdukt <Mathematik>MAPProgrammiergerätEntscheidungstheorieMereologieProjektive EbeneQuick-SortBildverstehenReelle ZahlProzess <Informatik>PunktRichtungBitrateNP-hartes ProblemDomain <Netzwerk>AutorisierungMultiplikationsoperatorMapping <Computergraphik>DatenstrukturPerspektiveVerschiebungsoperatorProdukt <Mathematik>EntscheidungstheorieGlobale OptimierungPhysikalisches SystemMotion CapturingComputeranimation
31:26
ComputerspielDatenstrukturMathematikSelbst organisierendes SystemVerschiebungsoperatorMAPGeradeLokales MinimumPunktMailing-ListeDatenstrukturVerschiebungsoperatorProdukt <Mathematik>EntscheidungstheorieGlobale OptimierungPhysikalisches SystemMotion CapturingComputeranimation
32:47
DatenstrukturOrdnung <Mathematik>Selbst organisierendes SystemSoftwareSpieltheorieVerschiebungsoperatorMAPProgrammierumgebungEntscheidungstheorieDivergente ReiheFundamentalsatz der AlgebraInhalt <Mathematik>Physikalisches SystemQuick-SortGüte der AnpassungExogene VariableCASE <Informatik>Peer-to-Peer-NetzUmsetzung <Informatik>SummengleichungDifferenteSelbstrepräsentationRandwertRechter WinkelDiagrammPerspektiveVerschiebungsoperatorProdukt <Mathematik>BildschirmfensterEntscheidungstheorieGlobale OptimierungFundamentalsatz der AlgebraPhysikalisches SystemRechenwerkE-MailBildverstehenFokalpunktDiskrete-Elemente-MethodeStreaming <Kommunikationstechnik>Culling <Computergraphik>Computeranimation
39:48
DiagrammFormale SpracheMathematikOrdnung <Mathematik>Selbst organisierendes SystemSoftwareDeskriptive StatistikEDV-BeratungProdukt <Mathematik>WellenpaketMAPEntscheidungstheorieBildschirmmaskeDichotomieGeradeProzesssimulationZählenQuick-SortBasis <Mathematik>CASE <Informatik>Coxeter-GruppeUmsetzung <Informatik>SchätzfunktionSoundverarbeitungClientEndliche ModelltheorieDifferenteCMM <Software Engineering>MultiplikationsoperatorZweiDigitales ZertifikatTwitter <Softwareplattform>SoftwareentwicklerCodeProdukt <Mathematik>EntscheidungstheorieGlobale OptimierungFundamentalsatz der AlgebraProzess <Informatik>Metropolitan area networkFokalpunktSoundverarbeitungSichtenkonzeptSoftwareentwicklerSLAM-VerfahrenComputeranimation
46:48
DatenstrukturNatürliche ZahlSelbst organisierendes SystemSoftwareModallogikProdukt <Mathematik>MAPEntscheidungstheorieGüte der AnpassungPrototypingProzess <Informatik>PunktUmsetzung <Informatik>RichtungSichtenkonzeptEndliche ModelltheorieExtreme programmingDifferenteTest-First-AnsatzCMM <Software Engineering>IdentifizierbarkeitMultiplikationsoperatorSoftwareentwicklerKanban <Informatik>CodeSelbst organisierendes SystemSoftwareGebäude <Mathematik>Produkt <Mathematik>Globale OptimierungFundamentalsatz der AlgebraPhysikalisches SystemRechenschieberGrundsätze ordnungsmäßiger DatenverarbeitungProzess <Informatik>FokalpunktExtreme programmingSoftwareentwicklerComputeranimation
53:48
UMLXML
Transkript: Englisch(automatisch erzeugt)
00:05
All right, thank you for coming. My name is James Shore and I am an Agile practitioner. I've been doing Agile development since late 1999, so over 13 years now. And I started out as a programmer, but my focus,
00:22
and on that first project I had a lot of fun and a lot of success and we introduced extreme programming and then we did more and we did more. And eventually I moved on to do consulting and helping other teams learn and develop their understanding of Agile.
00:40
And I've been seeing something, I don't know, a little disturbing, I would say, in the last several years with regards to Agile. So let me just ask you all, although I can't see you, raise your hand if you are on a team that's currently doing Agile in some way. If the word Agile is used in your organization
01:02
to describe your team. Okay, that's nearly everybody. Now raise your hand if you are satisfied with the way your team is doing Agile. If you feel like you're getting the benefits you were supposed to get. One person, two, two, you are a winner, sir.
01:20
Congratulations, two people. Yeah, this is what I'm seeing in the field is that the promise of Agile is not being realized. So that's what this talk is about. Why aren't teams getting what they expect from Agile?
01:42
Now, go ahead and ask questions throughout. I'm not gonna stop at the end for questions but I welcome questions throughout. There's time in the talk for questions. So as a question occurs to you, just raise your hand and I'll call on you. All right, this is Brian Marek.
02:01
He is a really interesting guy. He's passionate, he's articulate, he's well-read and he is also one of the authors of the Agile Manifesto. And he created something called Artisanal Retrofuturism Crossed with Teamscale Anarcho-Syndicalism in 2009. It just rolls off the tongue,
02:21
Artisanal Retrofuturism Crossed with Teamscale Anarcho-Syndicalism. Just, I love it. He said, we believe Agile software development is being dumbed down, commodified and losing its spirit. We seek to replace the current name Agile with a new one, Artisanal Retrofuturism Crossed with Teamscale Anarcho-Syndicalism, having two virtues.
02:41
First, that it captures more exactly the attitudes originally behind Agile and second, that it will be obscure enough that no one will assume they already know what it means and that amazingly enough, they're already doing it. Brian says, people used to come to me
03:04
and say about Agile, this is the best job I've ever had. Agile has changed my perception of my work. I love my job. That's what people used to say. Now they come to him and say, at least my job doesn't suck as much anymore.
03:22
And that's what I see as well. And it's not something I'm really thrilled about. We'll come back to Brian in a moment. This is Willem Larsson. He's president of a nonprofit, not-for-profit group called Language Hunters. Their mission is to rescue endangered languages
03:42
through accelerated language learning. So what they do is they, this is about natural language, human languages. They work with cultures that are losing their languages. For example, Chinook Wawa is a Native American trade language used in the Pacific Northwest. And they, all the native speakers of that language
04:04
are dying of old age. And none of the younger generation have learned it. So what Language Hunters does is help groups like this regain their languages that are in danger of being lost. And this is happening around the world.
04:20
A lot of sort of obscure languages are being lost because the last native speakers are dying. Willem's stuff is really interesting because he has a focus on language fluency and a lot of very innovative techniques for learning language rapidly.
04:40
And he has family who are involved in the Agile community. So he sometimes shows up at Agile conferences. So if you're ever at a conference and you see Willem there, ask him to conduct a one-hour language hunting session. I guarantee it will be absolutely worth your time. It's an amazing experience and really worth doing.
05:00
And in one hour, you can gain a low level of fluency in whatever language he happens to be working with that day. Willem describes four levels of proficiency in language. And this is based on a standard language learning model. What I like about the way Willem does it though is he really focuses on fluency.
05:22
So Willem will describe the first level of proficiency in language as Tarzan at the party. So you have proficiency at a low level in language. If you can go to a party and say, mm, beer, or good party, or who girl,
05:41
that's a low level of proficiency in language. A second level of proficiency is being able to get to the party. Maybe you say, where is the party? How do I get to the party? A third level of proficiency is when you can discuss the party. What happened to the party at the party? Was Jane there? Did she talk about me?
06:02
And then a fourth level of proficiency is what Willem calls Charlie Rose on party. So Charlie Rose is an American talk show host. He's fairly thoughtful. And he might bring a guest on the show and say, what are the ethical and moral implication of too many parties? Or do lawmakers have a moral imperative
06:24
to legislate parties? But these are different proficiencies of language. I think you can see sort of the natural progression here. The neat thing about what Willem does is he talks about fluency, not just proficiency.
06:42
So the goal of language hunters is to create fluency at whatever level of proficiency they can. So you could be fluent at a very low level. If you can go to a party and you can say, where Jane? Or want beer? If you can do that successfully, then you can be fluent at that level.
07:01
And that's a good thing. It's valuable to be able to do that. It's more than I could do if I were to go to a Norwegian party. So that's useful. Fluency is unconscious competence. So it's how you react under pressure. So perhaps normally you can talk to somebody, oh yeah, I talked to Jane at the party last night. We really got along well.
07:21
I'm looking forward to taking her back to my cave. But if in the middle of the night, you're woken up by the NSA shining a flashlight in your face, hypothetically, actually they wouldn't need a flashlight, would they? They just read your email. But somebody shining a flashlight in your face saying, where were you last night?
07:40
If you revert to at party, then you are fluent at this first level of proficiency. Even if you might normally have a higher level of proficiency, fluency is how well you can speak the language under pressure. Another thing that's interesting here and relevant here
08:01
is that you don't always need fluency at the highest level. In fact, it takes time and effort to learn language at a high level of fluency. And sometimes you just want to go to, well, let's say you're going to the Agile 2013 Conference, which is in Nashville this year. So you don't necessarily need to be able to speak
08:21
converse Southern at a Charlie Rose level. Maybe you just want to say, can you all tell me where the Agile Conference is? And that's good enough. So the amount of fluency you need is really dependent on your situation. All right, so late 2010,
08:41
Diana Larson and I were talking about, well, we were supposed to be working on a training course, but we were procrastinating. And what we were talking about was the dumbing down of Agile and language hunters. Instead of our training course, which was a Agile planning course. And the problem we were having with this course was that every time we taught it, people would complain,
09:04
which is not so good. We started out by saying, here's the big picture of planning. Here's release planning, and here's your vision and mission. And here's how you sort of guide your Agile planning efforts. And the reaction we got was, well, yeah, I see how you might understand the big picture,
09:21
but what about the details? And we'd say, well, we're getting to that. So later we tried switching around. We say, well, let's talk about the details first. Here's stories, here's tasks, here's how you plan an iteration or a sprint. And people would say, great, I see the details, but what about the big picture? That was a little frustrating.
09:41
So we were talking about this and trying to decide how, or actually we weren't talking about it, we were talking about other stuff. And it occurred to us that maybe this fluency model, this travels with Charlie model that Willem uses might be appropriate for us to use with Agile.
10:02
So we looked at what we saw in terms of how people learned Agile. We tried to reflect what we really saw in the field from people who are really adopting Agile for the first time. And we built that into a fluency model like Travels with Charlie. Then we workshopped it at Agile Open Northwest
10:22
in February 2011. We tried it in courses throughout 2011 and 2012. In 2012 we reviewed it with managers and executives and consultants and team members and got the feedback that, hey, this model is actually a really accurate reflection of what we're seeing from our teams.
10:43
This is how our teams are growing in their understanding of Agile over time. So all this culminated with a white paper that we sent out to several colleagues and asked for feedback on. One of those people was Martin Fowler and he liked it so much he asked us if he could publish it for us.
11:01
And so that's what we did. We put it on his site. The short link where you can find this white paper is Agilefluency.com and that will take you to the actual article on Fowler's site. This model turns out to be a pretty good way of showing what happens in the real world.
11:24
Now, as Diana says, every model is wrong. I just want to put this out here. We're all programmers or most of us programmers are here which means we're professional nitpickers. So I just want to say this in advance. Every model is wrong but some models are useful.
11:41
And this model seems to be a pretty useful way to describe how teams grow in their proficiency, their fluent proficiency over time. So this is what it looks like. Now, there's two aspects to this model. First, it is a pretty accurate reflection
12:01
of what we see happening in the real world that teams do tend to grow in their fluent proficiency over time. But it's also prescriptive. You can use this model if you are looking to change your level of fluency or your team's level of fluency. You can look at this model and see, well, where would we naturally expect the team to grow next?
12:20
What kind of issues are we going to face and what sort of investments do we need to make in order to continue to grow in fluency? So that's what I want to talk to you about. The model starts with the assumption of fluency in programming. So maybe not delivering a bug-free code,
12:42
maybe not even shipping on a reliable basis or when people want you to, but it starts with the assumption that your team knows how to program. At some point, there's some sort of foreign element, to use the Virginia's to Tier term,
13:01
which means that something happens. Somebody says, I'd really like to use Agile on this team. Maybe it's management who's reacting. Often what I see is when management brings in Agile, they're reacting to a perceived lack of quality. They want to decrease the number of defects or they want to have a more successful ability to deliver.
13:21
Or in other cases, it's the team members who are really interested in bringing Agile in for some reason. But for whatever reason, there's a foreign element, this desire to bring in Agile. And that usually involves, well, it can involve all sorts of things, but it usually involves, at a minimum, working out as a team on business-oriented goals,
13:42
in other words, on user stories. This requires a shift in team culture. So you're going to introduce user stories. You've got to learn how to work together as a team. You're going to do retrospectives to adapt and reflect and adapt. And there's often some compensation questions
14:02
to figure out, like how do we deal with teamwork versus individual work? What are we going to do about HR and our bonus structure and so forth? None of this is hard, like calculus is hard, but it does take a mindset shift. So as a result, what I see is that with help,
14:21
this takes about two to four months for a team to make this shift. And the investment here is team development and work process design. The benefit that teams get from fluency, that the business gets from fluency, is greater visibility into the work and the ability to redirect the team.
14:42
So now, rather than the team talking about architectural components and layers and so forth and in a way that's fairly obtuse to the business, now they're talking about what are we going to do that the business cares about? That's basically the purpose of User Stories is to change that conversation.
15:01
Any questions about this material so far? All right, this is sort of the most basic level of Agile, and this is what we call a one-star team. A team that's fluent at this first star has the ability to show their progress
15:20
from a business perspective and to redirect. Now, what do I mean by fluency? I mentioned before that fluency is unconscious competence. The NSA comes into your house in the middle of the night with a flashlight saying, where were you last night? Well, that's not what happens with software development. Well, not usually.
15:43
But it's the same thing. Fluency in Agile is how you behave when you're under pressure. So how well do you develop software? What do you do when the VP of engineering comes stomping into your team room at three o'clock in the afternoon saying,
16:00
we need this software shipped yesterday. What are you doing to make sure that happens? And if you throw up your hands and say, ah, everybody go back to their cubicles and work as hard as you can for three weeks without doing any of this teamwork stuff, then you're not yet fluent at this first star. So what you fall back to is your fluency.
16:28
Before we move on to the next star, the next level of fluency, just a little aside, I'm somebody, my background is as a programmer and I'm somebody who loves clean code. I love creating software that's really clean
16:43
and easy to use. I don't always succeed at it, but that's my goal. And I've been puzzled by a common phenomenon, which is that there are a lot of companies out there that are having a lot of success and have terrible code.
17:01
And this frustrated me because I take pride in creating clean code or trying to create clean code and it looked like it didn't matter because you'll see companies succeed producing the most god awful crap you could ever imagine. Have any of you seen this? Oh yeah, does it frustrate you too?
17:27
But I've realized something as I observe these teams. I'm brought in to work with a lot of, due to the nature of my work, I tend to work with smaller, more entrepreneurial companies, the ones that are more interested
17:41
in being daring in some way. And what I was seeing is that these startups were successful, they were very successful. They were successful enough to have an IPO and become a successful business. But five to nine years down the road, they were really struggling.
18:01
And that's why they were bringing me in. They were saying, we can't deliver anymore. We can't make changes to our software. We're gonna do a total rewrite and we want you to help us with that. Well, a rewrite is about the most dangerous thing you can do as a software business because what it means is you're gonna be spending all your time catching up with what you used to do.
18:23
So why would anybody do this? Well, they were experiencing so much technical debt that their software just couldn't be changed. How many of you have experienced this? About everybody in the room. So although business success will make the company
18:41
and technology has nothing to do with that, technology success or rather a lack of technology success will break a company. And then you also need the people involved to feel a sense of success because they will either help or sabotage your efforts. So people glue the company together. All three of these are necessary
19:02
in order to really have long-term success. So good business makes the company. Bad technology breaks the company five to nine years later and people glue the company together. Unfortunately, this first star of Agile fluency
19:21
doesn't say anything about technical success. So some teams also focus on their ability to ship. They might do so from the beginning or they might try to add it after encountering technical challenges. The former is easier. It's easier to work on creating
19:40
really good technical quality at the same time as you introduce the rest of Agile, but you can add it afterwards. It's also typically more successful if you do it from the beginning. And even those companies that do focus on both at the same time, they tend to reach that first star of fluency first because it's easier.
20:00
So fluency at this level means shipping on the market cadence. That means as often as your customers, your market, your real users, the people who are paying for the software, as often as they want to take new versions of your software, that's how often you deliver it. That's shipping on the market cadence. So if you're a web-based property,
20:20
then you might be shipping multiple times per day because you can basically ship anytime you want. As long as you don't change the UI, nobody notices. But if you are shipping software for a pharmaceutical company, I worked for a company in Canada that did mass spectrometers. And their spectrometers were used by the drug industry in the US,
20:41
which is regulated by the FDA. Anytime they got new software, they had to go through a very expensive re-approval from the FDA. So they didn't want new software more than once a year. So shipping on a market cadence for that company would have meant shipping once per year. So fluency at this level means
21:00
shipping on the market cadence, whatever that may be. And this requires a lot of skill development. We're talking about test-driven development, refactoring, continuous integration, automated builds, evolutionary design. If you don't do those things, you can sort of fake it. You can stumble along for a while. But you will discover that
21:24
you're getting more and more bugs and every time you finish a sprint, you're spending the next sprint finishing what you thought you finished the previous sprint and things keep falling further and further behind. So to really be fluent at the second star, you can't do that. Because if you're falling behind every sprint,
21:42
you're not able to ship when your market wants, when your customers ask. I worked with a team that hadn't shipped for two years. This was a team in the United States that did health insurance work. And they were really struggling. They had so much technical debt
22:01
and so much bad feelings amongst their team members that they literally could not ship new code. And their company was desperate because their entire business depended on this internal team building the software they used to run the business. And so if they couldn't ship new software,
22:21
then eventually they wouldn't be able to keep up with the regulations, regulatory changes, and they would go out of business because they couldn't not keep up with the regulatory changes. So they were looking at firing that team and just outsourcing everything, but they didn't want to do that, of course, because it's not a good idea to outsource the software that your business runs on.
22:42
It's okay to outsource secondary stuff, but you don't want to outsource the core of your business. So they took one last shot. They brought me in to introduce Agile, and we focused on getting, well actually we focused on getting to the three star fluency. But to get to the two star fluency, what they had to do was they had to merge
23:01
eight different production branches, create an automated build, automate deployment, automate database migration, learn test-driven development, figure out how to apply test-driven development to cold fusion, which I still don't know how they did that, and learn refactoring for cold fusion. So this is what I mean when I'm talking about a team skill shift.
23:21
This is a lot of work. By the way, if you are ever in an environment where you're delivering software to individual customers, like in a vertical market, and you have the urge to branch your code because you've got a new customer, don't do it. Therein lies madness. This is not really part of the talk, just a hint.
23:41
How many of you have been in that situation? How many of you have been happy with doing that? Nobody. All right, yeah, it's deadly. What you do is every time you branch, you basically double your maintenance costs. Anyway, so yeah, they had eight of these things. They had to bring them all back together. It took them about nine months,
24:02
but now they can ship at any time. And at first, organizational concerns meant they only shipped once per quarter. Their company was worried about training and training the sales people and training the internal staff. But as they became more accustomed to getting frequent deliveries, they allowed the team to deliver
24:20
more and more frequently. And now they ship about two to three times a week. So your investment for the second star is technical skill development. The benefit is low defects and high productivity because honestly, you cannot ship on the market cadence if you don't have low defects and high productivity.
24:42
Well, the high productivity is sort of a side effect that comes along as a bonus. All right, any questions about this material so far? If there's no questions throughout, we're going to be done early. I probably shouldn't tell you that because now nobody will want to ask questions, but just warning you.
25:09
Yeah, so a team that's fluent at the second star, they're going to tend to find problems early because they're going to be integrating their software really frequently. You can't, a team that,
25:21
even if you're shipping once per year, let's say you're in a medical, you know, a highly regulated field. If you wait until the very end to integrate your software, you won't be able to ship when everybody's ready because you'll invariably find problems. So teams that are really good at shipping on the market cadence, they figured out how to do that
25:40
in a way that reveals obstructions early. It's sort of a by definition thing. All right, just because you're shipping doesn't mean you're shipping the right thing. So some teams work on optimizing value,
26:01
not only shipping on the market cadence, but shipping the most valuable thing they can with the resources available every time. Now let me just ask you, let me go back to this two star actually. How many of you would say that your teams are fluent at this second star where they can deliver on the market cadence?
26:22
So that looks like about 20% of the room. All right, how many of you would say that your teams are fluent at this third star? Not only are you shipping on the market cadence, but you are shipping the most valuable thing you could to market every time.
26:42
One person, two people. That's really typical. When I ask audiences to self rate themselves on this, I typically see about 5% or less of people raise their hands and say they're fluent at this level. So there's a real gap here between the second star and the third star.
27:03
What'd you say? That's what makes this hard. So the question is, how do you know what's most valuable? That is a real challenge. So understanding what the most valuable thing is, given the resource available,
27:20
requires shifts to your organizational structure. You have to have somebody on the team full time whose job it is, whose expertise is in understanding the market. And how even that person or those people aren't going to know exactly what the market needs at any point. But part of doing the most valuable thing
27:40
is conducting experiments to find out what you could deliver to market. This takes changes to organizational structure. Yeah, the point was the really difficult thing here is making the organization fail early and fail often.
28:02
And you are absolutely right. Not only does this take somebody on the team who is really focused on understanding business value, who has knowledge, real knowledge and authority, but and has the time to work full time with the team to discover this,
28:21
but is they're also understand that there is no clear answers. You have to be able to try things, fail and learn from those experiences. How many of you are working on a team that has a product owner on it? Okay, I'm seeing about half the team or half the room raise their hand. How many of you see your product owner
28:42
multiple times every day? About half of you, that's actually pretty good. Now how many of you see your product owner multiple times every day and that product owner actually has the authority to make decisions about what the product needs rather than going and asking somebody else for permission?
29:00
About half. You guys are in the minority actually. There are a lot of teams that have a product owner that they see once every week, once every two weeks and that product owner, although they have the name product owner, is actually a glorified project manager whose job it is to talk to the real experts and get advice. To be successful, to be fluent
29:21
at this third star of proficiency, you need to have real expertise on the team. What I find is that often that expertise does not exist in the company at all. So what that means is that you have to develop that, you have to build that on your own. That company I was talking about, the health insurance company,
29:40
they started out as they were trying to develop this fluency at this third star, they started out by trying to work with various department members. When they were working on stories for that department, they would have somebody from the department come in and sit with them full time. And what they found was that, yes, those people had expertise in how they did their work
30:02
but they didn't really have the big picture understanding or vision about how they could positively change the software to make it more valuable. They would know what they did but not what could be done or should be done. So actually, and also it was very hard to get their time. So the team actually stopped doing that,
30:21
stopped bringing those product domain experts in and instead developed a business analyst internally to become a product manager. And that business analyst would go out and talk to the domain experts, sort of synthesize all the different perspectives and define the product direction from that. Eventually he left and they didn't replace him.
30:41
Instead the team, the programmers on the team just sort of took over the role and absorbed it into their normal work. So teams that are fluent at this third star have that expertise somehow on the team. Either they're getting it from the organization, although that seems to be fairly hard to do, or they're developing it themselves.
31:03
If you're doing this, tools like impact mapping, Gojko, are you in the audience? No, Gojko Adzic is here. He has a tool called impact mapping and it's a really interesting tool for doing this level of product management to really understand what the software is about. Techniques from lean startup
31:21
and agile chartering are also helpful. One of the biggest reasons this shift in organizational structure is hard is because it requires a change on mindset from a list of milestones to exploring the possibilities. So you've got this big, fuzzy, unknown future in front of you
31:42
and it's tempting to say, well, we're going to do this. Here's the bright red line we're going to follow. And then as life goes on, you discover new opportunities, but the temptation to just keep following that line is really strong. Really, so this gets to the point you were making,
32:02
really maximizing value requires that you let go of that bright red line because that doesn't get you to the maximum value. It might get you close if you have a good idea understanding the market, but it will never get you as close as you can possibly get. So you've got to let go of that bright red line, say there's this big, fuzzy, unknown future. It's scary.
32:20
We don't know what's going to happen. And as the possibilities come along, we're going to follow them and see where they lead. And we're going to take some false starts and dead ends, but that's how we're going to get as close to the maximum value as we can. This is really hard for a lot of organizations and this is another reason why only about 5% of the teams
32:43
I talked to are at this level. So what you need to invest in in order to get to this level of fluency is you need to really spend social capital on either incorporating business expertise in the company or taking or bringing that responsibility into the team.
33:01
And the benefit you get is higher value deliveries. This star, this level of fluency is what we promise when we talk about agile. When we sell agile, when we say if you do agile, you'll be able to react to the market needs and sort of shift, this is what we're talking about.
33:21
And I think one of the reasons people feel frustrated about what they're getting from agile is we sell this, but we don't deliver it. All right, any questions on this third star?
33:44
Yeah, so the question is comment on the balance between a need for a long-term roadmap and sort of shifting and experimenting. That is going to depend on the market you're in. In general, the less you try to predict what you're going to do, the more opportunities
34:01
and the less waste you're going to have. So I would prefer not to create that roadmap if I can. And there's a difference between having to do the roadmap because your company will fire you if you don't and having to do the roadmap because there's some market need.
34:21
So if you have a legitimate market need, let's say there's a trade show in six months and you have to have certain things to deliver at that trade show, then you need to be able to say, well, this is the date, we're absolutely going to have something on this date. And in some cases you might need to say, and it's going to look somewhat like this. But honestly, mostly when I see people saying
34:42
we need a roadmap, it's because of fear in the organization, not because of an actual market demand. You can often, even if you're trying to have sales conversations with customers about what's coming down the road, those can usually be at a fairly high level that allows you to shift direction underneath.
35:00
So you've got sort of an umbrella of what we're going to deliver. And then the details of that still can vary. Did that answer your question? Right.
35:21
Yeah, Goeko Adzic has a, I wasn't aware of the content of the session, but apparently there's a session this afternoon where Goeko's going to be talking about the difference between roadmaps and just following a road. And I saw him talk about this at the XP conference in Vienna last week, and it was really good stuff. I recommend that you go to it.
35:41
His material is very much focused on what you need to get to fluency at this third star. So if you're interested in that, go to his talk. I highly recommend it. Some teams, very, very few, are working on a fourth level of fluency. And our goal, Diana, my goal with Diana Larsen
36:02
is that we want this level to be more aspirational. We wanted to include a level of proficiency that wasn't actually a good idea for every company. We wanted to see something that was pushing the boundaries and that's what this fourth star represents. Teams that are fluent at this level of proficiency
36:23
are participating as peer decision makers within their organization to set the agenda of the organization. So not only are they delivering the most value they can for their own product, they are also collaborating with other teams in the organization to deliver the most value for the organization,
36:42
however the value is defined, whether it's a nonprofit or a for-profit organization, helping work together to optimize the system. This requires a shift in organizational culture, obviously, because most organizations are not geared
37:01
to this sort of bottom-up decision-making. And it also requires inventing the future because we have some practices around the third star. We have lots of detailed practices around the first and second stars, but there aren't really anything, there's very little about this fourth star. There's some companies that are leading in this area,
37:21
Valve for one, WL Gore, Semco are all companies that have had sort of this bottom-up, team-driven approach to what they're building. I wouldn't say that any of them are necessarily perfectly successful at it yet. How many of you have heard about what Valve's doing with their teams?
37:40
Just a few of you. Valve Software, the game company in the United States, has got an environment where team members assign themselves to teams and decide collectively about what they're gonna work on. There's no top-down structuring of what the team's gonna work on. That's not entirely true.
38:01
They did lay off a whole department recently, so obviously there's something happening there, but they are sort of aspiring to this goal. Semco, a large manufacturer in Brazil, also works in this way. You can read about it by reading the books of Richard Semler.
38:20
And WL Gore famously used to work in this way. I don't know if they still do or not though. They're the people who make Gore-Tex, Gore-Tec or Gore-Tex, I don't know, the waterproof fabric that you find in rain jackets and so forth. All right, any questions about
38:41
that fourth star before I move on? Okay, so this is a series of proficiencies, and fluency at any of these levels is good. The first, fluency at the first star really represents agile fundamentals.
39:01
The second star represents sustainability. So if you just do the first star, then you will find that five to nine years down the road, you're having to rewrite your software because you're overwhelmed with technical debt. So the second star represents sustainability. Three stars is what we promise when we talk about agile. When we say agile is gonna be good for you
39:22
because of this, we're typically talking about three star agile. And four stars represents agile's future. This is what we're going to learn how to do in the years to come. Where you're at really determines how you see the world.
39:43
How many of you have been hearing about the debate between whether or not you should do estimates? All right, so about half the room. There's been this debate on Twitter about estimates are important, no estimates are the agile way. Well, the way you see this is really going to be affected by what kind of proficiency,
40:03
what level of fluency your team is at. If you're a one star team, if you're fluent at this one, that first star of agile, estimates are impossible because you don't have the technical practices to really deliver on a regular basis. So you might say estimates are non-agile
40:20
because they can't be done, or you might hide that and say estimates are non-agile because we don't want to do them. But either way, it boils down to we can't. Teams at the second star have no problem delivering estimates because they have consistent, steady velocity, or if they're using combine, they've got consistent, steady cycle times.
40:42
They have low defect counts so they can predict fairly easily what's going to happen. There's still risk from new work coming in, but you can predict fairly accurately if you're fluent at this second star. So teams that are fluent at the second star say estimates are great. There are times when we need to serve our business partners by telling them what we're going to deliver and when,
41:01
and that's useful. Teams that are fluent at the third star will say, well yes, we could do that, but it's not valuable. It's more valuable for us to deliver the most important thing now, learn from that, and then decide what to do next. So we're not going to do estimates because estimates take time and that's just wasted.
41:22
So where you're at on this model will modify how you think about a lot of the different things in Agile. Similarly, what you try to do depends on which level you're trying to reach. But remember, every level is valuable.
41:42
There's use, any of these, even the first star, which isn't sustainable, is useful if you're not trying to build something that's going to last 10 years. I really want to emphasize that this is not a maturity model. In a maturity model like the CMM,
42:02
it's implied that you want to get to the top level, that you want to be CMM level five or you're crap, and you'll do anything it takes, including bribing the auditor in order to get there. Not that anybody would ever do that, right? CMM is the SEI's Capability Maturity Model.
42:20
It was really big in the late 90s and early 2000s. I'm sorry, I can't hear you. The CMM, the Capability Maturity Model, is a model that describes how well you develop software.
42:43
And it looks, to an unnuanced view, it looks like something like this, where he says, do this, do this, do this. But we're not trying to say, do these things so you get to four star. Actually, four stars of fluency is not appropriate for most teams. Just like if you are going to Rome for XP 2014,
43:04
it's not necessary that you have a Charlie Rose level of fluency in language in Italian. It's also not necessary that every team have four star fluency in Agile. In fact, I think it's impossible for many teams to do that just because of the amount of cultural change required in the organization.
43:23
So here's how to use this model. That's a description of what the model looks like and how we see teams grow. What we see is that regardless of what level you target, teams tend to grow fairly predictably through one star to two star to three stars.
43:40
So you can practice at a three star proficiency level, but you gain fluency sort of gradually down the line. This model is intended for you to use in two ways. If you're in an organization where you are an influencer about how Agile is done,
44:01
this model is intended for you to use to make the case to manage about where to make your investment. If you're a consultant who introduces Agile to other organizations, this model is intended for you to be able to use to help your clients understand what the trade-offs are, what investments to make,
44:21
and what benefits to get back from it. And our hope is that people will start using this. We would like to get people to get away from the this is Agile and this isn't Agile dichotomy. Because honestly, Agile, other than the Agile Manifesto, is not defined at all. So it's not helpful to say you're good Agile
44:41
because you're doing no estimates and you're bad Agile because you're asking for estimates. That's not useful. So this model is at Agilefluency.com. This picture is licensed freely. You probably can't see it, but it says you may reproduce this diagram in any form so long as this copyright notice is preserved. So just like the Agile Manifesto,
45:01
I encourage you to use this in your own presentations. And it's really designed for conversations with decision makers about trade-offs. So here's how it works. Step one, consider the benefits of the various levels. So teams that are fluent in the first star are gonna have greater visibility into their team's work and the ability to redirect.
45:21
Second star, you're gonna see low defects in hybrid activity. Third star, you're gonna see high value deliveries and excellent product decisions. And fourth stars, you're gonna see the alignment with organizational goals and sort of synergistic effects as teams work together to create the most value possible for the organization. So look at that with your decision makers and say, which of these benefits do we want to achieve?
45:45
And trade that off with the investment required. Doing Agile well, fluency doesn't come easy. I think Agile's been done a great disservice by people saying, you can do Agile with two days of training and a certificate.
46:01
But it's because you can't. I mean, you can, that will get you enough to start working on fluency at the one star level. But that's all. So getting those benefits, getting these benefits here requires you to make some investments. So for one star, you've gotta work on team development and work process design.
46:21
For two star, you need to do that and work on skill development and have patients with lowered productivity while the teams learn. If you're gonna do three star, if you're gonna aim for three star, you have to do all those things and you're gonna have to expend social capital on restructuring the way business decisions are made about products in your organization. And then four star, we're talking about
46:42
pretty significant effort in organizational culture. This is really only possible if the organizational leaders are excited about having an innovative company structure. And you're also gonna have to invent the processes to do it because it's not really defined anywhere.
47:02
So that's step two. Think about the benefits. The benefits are cumulative. Think about the investments. Investments are cumulative. And then choose your target. Which level of fluency do we want our teams to have? One star is really appropriate for teams working on software that isn't gonna be maintained long term.
47:22
Now, an experienced team that's fluent at two star is gonna be faster after about six weeks than a team not using test-driven development and everything else. So if your team already knows all the agile engineering practices,
47:41
all the XP engineering practices, you might as well just do that unless you've got a very small prototype you're throwing away right away. But learning those things can take a while. So if you're looking at something that's gonna be delivered in half a year and not maintained, then it may not be worth the time to invest in learning all the agile engineering practices
48:01
as you're doing that work. Two star is really appropriate for large and bureaucratic organizations. They often can't make the leap to three stars. And there's a lot of value in being able to have that high productivity, low defects that you get from being fluent at the second star. But if you have a more entrepreneurial organization, you'll often get more benefit
48:21
out of being able to shift direction to really maximize your product value. And then, again, that fourth star is pretty much for the companies that pride themselves on being innovative, not just in their products but in their company structure. Once you have your target,
48:41
practice everything necessary to get there. So if you're targeting a three star, use Scrum or Kanban and XP or Lean Craftsmanship and Lean Software techniques or Lean Startup techniques or impact, Goico's impact mapping,
49:00
and there's other stuff still to be determined. We don't have a really clear understanding of all the practices necessary to be fluent at this third star yet. Do all those together. And what you'll see is that fluency will grow over time. So you just keep practicing.
49:20
And typically, I see that teams get to the first star of fluency in about two to six months. The second star, three to 24 months after that, depending on how much technical debt they have. And then the third star, because it requires that organizational structure shift, that takes usually several years. Even if you're working on it from the beginning, which I recommend if that's what you want to achieve,
49:41
it still takes a while. If that structure's not already in place. So the comment was that moving from one star to two star
50:01
involves losing your religion and taking a more nuanced view. I wish that were true, but there are extreme programming teams out there that have a very dogmatic, that take a very dogmatic approach to it. So the nature of the one star and two star teams, there's a pretty good body of work out there
50:21
about how to get to that level of fluency. You can do scrum by the book and get to one star pretty reliably. You can do XP by the book and get to two star pretty reliably if you follow its constraints, like having a co-located team. So I don't think there's a tight relationship
50:41
between learning maturity and fluency. The maturity you're talking about just tends to come from experience. Teams start out and they say, we do it this way, it's successful, therefore it's the only way. And you have to see a bunch of different ways before you let that go.
51:04
So my fifth point here is expect that fluency to grow gradually. It will take time. All right, any questions on this material?
51:23
Yeah, so the question is, why is GitHub on here? GitHub, the company, has a pretty innovative bottom-up culture. They're entirely distributed and decisions are made by individual team members. This was true as of a year and a half ago. I think as they've continued to grow,
51:40
that might be breaking down. But I put them on there as an example of a company that you might want to look at for ideas about how to achieve this fourth star, if that's what the right thing for you is. Did that answer your question? Okay. Other questions about this model?
52:05
So again, the way to use this model, please, please use it. We're releasing it free to the world. All we ask is you leave our name on it. And use this in your conversations with decision makers about how to use Agile in your organization.
52:22
We have been selling three-star Agile and delivering one star. And that is honestly not sustainable. We can't continue doing that. We're starting to see articles and mainstream publications about how Agile is failing. And that's because people are hearing one thing
52:40
and getting another. So please use this model. Talk to your decision makers about the benefits of various levels, the investments required to reach there, and then which level is appropriate for your organization. And then given that, practice everything you need to reach that level and expect fluency to take time.
53:00
For the higher star levels, we're talking about several years. So to close, I'm going to paraphrase Brian Merrick. I believe Agile development has been dumbed down, commodified, and lost its spirit. This was a necessary first step in reaching a larger audience.
53:22
And now it's time to regain that spirit of innovation and value by working together on what we can deliver with Agile and talking to people about how we can realistically get there. So please use this to help your teams identify and reach the level of fluent proficiency
53:41
that's right for them. Thank you for your time.
Empfehlungen
Serie mit 10 Medien