Scaling Agile with a Distributed Team
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 110 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/51026 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
SoftwareCodeSoftware testingDisintegrationSoftware developerProduct (business)Lattice (order)Commitment schemeMultiplicationPlanningExecution unitLetterpress printingPoint (geometry)Task (computing)Level (video gaming)Right angleHand fanIterationWave packetMereologyScaling (geometry)Physical systemExpert systemEstimatorMultiplication signHypermediaSpring (hydrology)Subject indexingPlastikkarteElectronic mailing listMaxima and minimaCASE <Informatik>VelocityData managementAverageProjective planeShared memoryComputer animation
04:40
Software developerSoftwareType theoryInterface (computing)BitShared memoryOnline helpProduct (business)Hand fanAddress spaceComputer multitaskingMultiplicationDifferent (Kate Ryan album)Computer configurationComputer animation
05:35
SoftwareType theoryInterface (computing)InferenceInterface (computing)Type theoryIdentifiability1 (number)INTEGRALPhysical systemComputer animation
06:38
Interface (computing)SoftwareSoftware developerDisintegrationProjective planeINTEGRALCartesian coordinate systemSet (mathematics)BuildingLattice (order)Type theoryInteractive televisionIterationSoftware testingCodeInterface (computing)Library (computing)Java appletProcess (computing)VirtualizationPlanningMereologyStatement (computer science)Figurate numberGodVirtual machineSequelRight angleSoftware bugNumerical analysisControl flowComputer animation
10:00
SoftwareIterationPlanningScale (map)Scaling (geometry)Lattice (order)ArchitectureProduct (business)IterationLimit (category theory)Computer animation
11:02
SoftwareSoftware developerLattice (order)Food energyProduct (business)FlagThumbnailArchitectureClient (computing)Sheaf (mathematics)Task (computing)PressureFunctional (mathematics)Set (mathematics)PlanningKey (cryptography)Table (information)SpacetimeArithmetic meanPlastikkarteWaveSubject indexingProjective planeBitFreewareOnline helpRight angleInformation technology consultingSocial classVideo gamePhysical systemMoment (mathematics)WhiteboardType theoryComputer animation
14:56
Product (business)SoftwarePlanningComputer programmingControl flowArtificial neural networkTest-driven developmentInformation technology consultingBand matrixProgrammer (hardware)PlanningProduct (business)2 (number)Game theoryGoodness of fitFlagLevel (video gaming)Flow separationCASE <Informatik>First-person shooterReal numberScripting languageDifferent (Kate Ryan album)Group actionLattice (order)Software testingForm (programming)Computer programmingShooting methodView (database)Arithmetic meanRight angleSign (mathematics)Table (information)Multiplication signSoftware developerDirection (geometry)Computer animation
18:31
Organic computingCharacteristic polynomialSoftwareProgrammer (hardware)Process (computing)MereologyLevel (video gaming)EmailArtificial neural networkGroup actionProjective planeQuicksortBoss CorporationVirtualizationInformation technology consultingCoordinate systemClosed setForm (programming)Modal logicAttribute grammarElectronic mailing listMultiplication signSelf-organizationComputer animation
20:24
Local GroupSelf-organizationSoftwareType theoryBasis <Mathematik>Dependent and independent variablesSoftware testingSqueeze theoremMultiplication signScheduling (computing)Level (video gaming)Boss CorporationSelf-organizationProjective planeGroup actionData conversionContinuous integrationLattice (order)Right angleAutomationSet (mathematics)Type theoryGreatest elementDifferent (Kate Ryan album)Computer animation
22:39
Integrated development environmentFocus (optics)Time evolutionOpen setLevel (video gaming)SoftwareSoftware developerEvent horizonLattice (order)Level (video gaming)EvoluteSet (mathematics)Data miningSoftware testingTowerCombinational logicComputer programmingBookmark (World Wide Web)Different (Kate Ryan album)Electronic mailing listGroup actionEmailQuicksortBitCartesian coordinate systemWeb pageType theoryPoint (geometry)Focus (optics)Client (computing)CoroutineMultiplication signOnline helpProcess (computing)Closed setMiniDiscEvent horizonServer (computing)Row (database)GoogolRight angleComputer animation
26:03
SoftwareOpen setMathematicsCoordinate systemSoftware developerFunctional (mathematics)Term (mathematics)WordRight angleDifferent (Kate Ryan album)1 (number)Dot productSemiconductor memoryPoint (geometry)Lattice (order)Set (mathematics)Power (physics)Level (video gaming)Term (mathematics)BuildingCoordinate systemOpen setMultiplication signBasis <Mathematik>Latin squareBoss CorporationType theorySimilarity (geometry)Decision theoryProduct (business)TextsystemProgrammer (hardware)Process (computing)Software testingDatabaseArithmetic progressionMereologyOffice suiteFlow separationDistanceSelectivity (electronic)BitScaling (geometry)BackupProjective planeSystem callWritingIntegrated development environmentStreaming mediaUniform resource locatorOffice <Programm>Internet forumHypermediaOnline helpComputer animation
34:47
Term (mathematics)Software developerSoftwareBuildingFunctional (mathematics)Machine visionAttribute grammarSubgroupIterationMusical ensembleMultiplication signEquivalence relationOffice suiteType theoryBoss CorporationReal numberMereologyBuildingHand fanProjective planeDifferent (Kate Ryan album)SurfaceLevel (video gaming)WritingSystem callSuite (music)SoftwareFocus (optics)CodeLattice (order)1 (number)MultilaterationPressureRing (mathematics)Term (mathematics)CuboidSet (mathematics)Keyboard shortcutScheduling (computing)TelecommunicationRoundness (object)Arithmetic progressionPoint (geometry)Right angleSoftware testingWordProgrammer (hardware)Reading (process)Computer animation
43:32
SoftwareMathematicsTelecommunicationProduct (business)MereologyHand fanTime zoneDisk read-and-write headTelecommunicationBitPerturbation theoryRight angleDistanceWeightComputer animation
45:05
SoftwareSoftware developerInclusion mapProjective planeTelecommunicationStorage area networkDistanceMereologyLevel (video gaming)Multiplication signLattice (order)Tournament (medieval)Shared memoryBitHypermediaPoint (geometry)Euler anglesVideoconferencingSurgerySound effectType theoryDigital photographyPhysical systemFamilyLipschitz-StetigkeitRight angleVideo gameIterationTelepräsenzDistribution (mathematics)Game theoryComputer animation
48:15
System callProduct (business)SoftwareIterationCommitment schemeInformationLocal ringSoftware developerLattice (order)System callSingle-precision floating-point formatGroup actionMultiplication signSlide ruleComputer configurationScaling (geometry)PlanningSoftware developerBitIterationTime zoneKey (cryptography)PlastikkarteLevel (video gaming)Programmer (hardware)Arithmetic progressionMereologyTraffic reportingDialectProduct (business)INTEGRALOffice suiteRight angleNumerical analysisMathematicsMetropolitan area networkWebsitePoint (geometry)Electronic mailing listSheaf (mathematics)Royal NavyHypermediaComputer animation
Transcript: English(auto-generated)
00:00
Let's talk about scaling. We're going to talk about scaling Agile up and distributed teams. We've got three key topics I want to discuss in this one. First one, dependencies. We're going to talk about how to manage dependencies on an Agile project. Second, I want to talk about how to do the iteration
00:21
planning meeting. This is probably the most challenging meeting when we scale Scrum or Agile up and we have lots of people. How do we plan a sprint or iteration in the next couple of weeks? And then third, I want to talk about how do we coordinate teams together. What can we do to get teams working together within an iteration or sprint? So let's start with our dependencies here.
00:43
A couple of things we can do to manage dependencies. The first thing I'd like you to do is to do what is called rolling look ahead planning. Now, if you heard one of my earlier sessions today, if you're here and we talked about first thing this morning, we talked about Scrum. Right after lunch, I was talking about estimating. And in both of those, I kind of hinted and touched
01:02
on a meeting called an iteration planning meeting or sprint planning meeting. And I said that that meeting's long and painful. I said that meeting might go three, four hours. I said some teams might spend eight hours doing that meeting. So here's what I want you to do when you scale Agile up, when you scale Scrum up. Don't just plan one sprint, or it takes four hours to do.
01:22
Don't just plan one sprint. I want you to plan three sprints. But no, you're not locked in that room for 12 hours. That would be unbearable, right? I want you to stay in the room and plan one sprint. That's going to take two, three, four hours. Then I want you to plan two more sprints. But I want you to do those in no more than 10 minutes.
01:41
Okay, no more than 10 minutes. We're going to plan that second and third sprint at a much lower level of fidelity, a much lower level. Higher level, but lower level of fidelity. We're not going to plan as precisely as we plan the coming sprint. So here's how I want this to happen. We get the team together, and the team
02:00
is going to plan one sprint. They do that by taking product backlog items, which I'm showing there on the left on index cards, how I like to do this. I tend to think of these as something called user stories. This will be our last session today. And so we take these user stories, we break them into tasks, we estimate those tasks in hours.
02:20
This is the part that takes two, three, four hours. Maybe an entire day if you're doing a long iteration. Then what I want the team to do is to grab a second user story. They break that into tasks and hours. They repeat this until they're full. That's one sprint, one iteration. Now what we do is we stay for another 10 minutes. And in that 10 minutes, we plan the second and third
02:41
iteration. In this case, that'll be iterations five and six, because we're doing iteration four here. So we're going to plan iteration five and six in a maximum of 10 minutes. We're going to do it at a velocity level. What this means is we're going to look at the high-level estimates we put on those backlog items. And we're going to say something like our average is 20 units of work per sprint.
03:02
20 story points, 20 ideal days, if you're familiar with those terms. And we're going to pull that amount of work into the fifth sprint, and we're going to pull that amount of work into the sixth sprint. But you'll notice here we're not doing it at the task level. We're bringing these things in at the user story or product backlog level. The idea here is to look ahead to sprints.
03:23
Here's why. Suppose we only plan one sprint. My team plans its sprint. You're in another room planning your sprint. My team discovers a dependency on you. And we walk over, and we tell your team or ask your team very politely, can you please do this task for us? It's part of your part of the system.
03:40
Can you please do this? We need it done so we can finish our work. And you tell me no, because you've just planned your sprint. You're full. You can't do that six hour thing for me. You're full. So what I want to do on my team, I want to look ahead a second and third sprint. Now I walk over to you and say, hey, can you please do this thing for me?
04:01
And you still say no. You say, no, we're busy. And I say, I don't need it now. And can you do it next sprint? Oh, sure, sure, we can do it for you next sprint. So you do it for me in the next sprint, which would be sprint five up here. And now my team has it by the time we start sprint six. So we're always looking ahead two sprints here. Now this is not a commitment. It's not a guarantee.
04:21
It's not very rigorous at all. It's just a best guess of what we're going to do one and two sprints ahead. So that's all we're looking at here. So rolling look ahead planning, one way to manage dependencies. Look ahead a couple of sprints, be able to predict what you need from another team. Second thing we can do to manage dependencies
04:42
is to share team members. I got to list this. This is a possibility, but I got to say I'm not the biggest fan of this one. I'm not a big fan of multitasking, of spreading people across multiple teams. We spread people across multiple teams, we lose a tremendous amount of productivity.
05:03
But we'll help address dependencies here. So if one of your issues, one of the big issues in your company are dependencies, this might be a much better option. And I can live with the fact that I'm losing a little bit of productivity due to that multitasking. So here we might see sharing a couple people across different teams.
05:22
In thinking about dependencies across teams, I want to think about the type of interfaces that we have between teams. Teams interface have dependencies in different ways. One type of interface is what we're going to call an unattended interface.
05:41
An unattended interface is one that we know that exists, but we're not very worried about. It's not a big deal. There's an interface between these two systems, but I'm not worried about it. There's no problems there. These teams used to have to interact, but there's nothing there to worry about. And so we just don't pay attention to it.
06:01
It's there, but we're not going to attend to it. We're just going to let it go. It's low risk, it's not important. The other type of interface that we have is what is called an unidentified interface. An unidentified interface, we don't even know there's a dependency there. Later we're going to find one and it's going to bite us. But right now we're unaware of it.
06:22
So two types of interfaces that can affect us. Unattended, unidentified. Then of course there's ones that are identified that we are attending to. So these are the two types to be worried about. One of the things that we can do with these interfaces here is use an integration team.
06:41
Sometimes when we scale Scrum up, we need to introduce an integration team. Often the integration team can be a virtual team. We might have, let's say we have five teams. Each of five teams doing their own good work, but they're all building something together. We create a virtual integration team. What that would mean is we have one person
07:01
from each of those teams, and they get together in the morning each day. And talk about any integration issues. One of the best things to do would be to have an integration test that runs at night. Runs at night, checks for interfaces between the code. And if it finds any problems, that build breaks. The five members of the virtual integration team show up tomorrow morning.
07:21
They notice the broken build, and among the five of them they figure out whose problem it is. It's your team, you go fix it. No, you go fix it, right? They talk about it, they figure out who it is. They may get it wrong, but at least they take a first stab at who should address that problem. Later as we build that project up, maybe we get 12, 13, 14 teams,
07:41
we're going to introduce a dedicated integration team. Right, it'll be people. Each team will give up one person perhaps, and that person goes and lives on an integration team. That is their job now, be on that integration team. Now one of the tips with an integration team is do not use this as a dumping ground for poor performers.
08:03
I will see this very commonly where a company will say, well I don't need this guy, I'll put him on the integration team. That is not the type of person we want on the integration team. The integration team often needs to be some of our better performers. I know it can be tempting to not put them there, but the integration team needs the best performers.
08:22
This is the type of person who needs to go to a meeting with team A today, and listen to team A, three or four days from now they're in a meeting with a different team, and they're the person who's smart enough to connect what this team is talking about with what that team said three days ago. Oh my God, it's going to blow up, right?
08:42
That team just said this, this team just said the other, right? I remember one of the guys I was talking to was on a team like this, and he happened to just, there were just very innocuous little comments. One team had discovered because of a library they were using that in their JVM, their Java virtual machine,
09:00
they needed to set headless equals true, right? It just happened to come up in a discussion, you know, and he heard it, and then he's like about a week later in another meeting with a different team where they had come up with a reason why they had to have headless equals false, right? And these were all part of the same application, right? And he was able to pick that up and notice it,
09:22
and he ran the application with the wrong settings just to see what was going to happen, and it was some very subtle bugs. This is a guy who was smart enough to pick up on that. Now obviously you can't have headless true and headless false, even if you don't know what it is, it doesn't sound good, right? You have this, it can't be both numbers, right, or both values. But this is a guy who was smart enough to remember it, right, most of us would have just heard that,
09:41
it's some weird statement, I don't remember it. But this guy heard the two statements, put that together. So I need people in here who can look for dependencies, look for subtle interaction. So it's not a dumping ground for our poor performers. It's one of the ways, three of the ways we handle dependencies. Wanna talk about the iteration planning meeting.
10:03
This is one of our bigger, more complex meetings, probably the hardest one to scale up. So in iteration planning, there's two general approaches for how to do this when we scale, I don't know what that was. When we scale Scrum up, right, two general approaches to this.
10:21
The first thing is to stagger our meetings by a day. Have some teams plan today, other teams plan tomorrow. Right, and that works up to a certain size. Right, this is a nice approach. You have somebody on a large scale Scrum or Agile product we call a chief product owner. Our chief product owner can now go to some meetings today,
10:42
some meetings tomorrow. Our chief architect can go to some meetings today, some tomorrow. So staggering by a day helps us scale up to a certain size, but there's a limit. You can't really go more than maybe five, six, seven teams at the most by staggering. The approach that I prefer for doing this
11:00
is an approach called the big room. Now I'm gonna let you in on a secret. I have some clients that do this, and I've introduced this to them and we do this, and I of course charge them. I'm a consultant, I charge them to be there. I probably do this for free. Right, this meeting is so much fun when we do this.
11:21
I love this. Now you don't know any of my clients. I'm doing this for you so you can't email them and tell them, right, or tweet, hey, Mike will do big room techniques for free. But I actually love doing this. This is one of my favorite days when I get to go work with some of my clients. So let me describe what we're talking about here. What we do here is we bring all the teams together into a room.
11:42
Right, now let's assume we're all co-located for a moment. We got our entire project here in Oslo. So we're gonna get a big room. Holds 50 or 100 people, whatever we got on the project. Typically this meeting is gonna start out by somebody like our chief product owner making a few announcements. You know, we got the whole team together. Let's make some announcements if there's anything to share with everybody.
12:01
I had a great client visit. Our customers are real excited about this set of functionality. I've got, man, we're getting some deadline pressure from this other client, but I think I've put them off. We'll start out with a few announcements like that. Then what happens is each team grabs a corner, some wall space, maybe a table in the middle of the room, whatever it is, each team grabs some space
12:22
around the room. Each team sits down with, if they have a dedicated product owner, their product owner. It's very common when we scale up, 10, 15, 20 teams, that we might have a product owner shared across a couple of the teams. Right, if we've got, let's say we've got 10 teams, we might have six product owners total. I've got a chief product owner
12:41
and maybe four or five product owners to help out. So each team sits down. If they have a product owner, their dedicated product owner sits with them. And what's nice about doing this all in one room is each team starts their planning meeting, but key resources like that chief architect can move between teams. Right, our chief architect can move back and forth
13:01
from teams who need him or her. Our chief product owner can move around between teams. Right, it's very easy to get all of us done. Now if I need something from your team, I just walk over and ask for it. I might walk over and hand you an index card and say, hey, can your team do this for me? And you're too busy, you can't answer me right now,
13:21
so you just kind of wave me off. I'm like, okay, I'll go back to my team. I'm sitting here with my team doing my work. I look over five minutes later, you give me a nice thumbs up. I know you've got that task covered for me now. I said, I don't have that guaranteed dependency that we had in the first section of this class. Right, so the big room technique.
13:41
Now what I like about doing this is the ability for people to move around. This is, when you do this, this is why I like this so much, it's a very kind of loud cacophonous meeting, but it's very energetic. You can feel the energy in the room when you're doing one of these. Now a little tip for doing this, one of the things I like to do
14:01
is to get nautical signaling flags. Right, those flags that mean, you know, admiral aboard, about to turn to starboard, stuff like that. Get those type of flags, give each team a set of the flags that you're gonna use. So each team might have four or five flags. Pick a meaning for the various flags. One of the flags might mean something like,
14:21
we need the chief architect, right? Now any team that needs a chief architect sticks that flag up on the wall near them. The chief architect is over here working with a team. Every now and then looks around, nope, nobody needs me. And our chief architect stays over here. Maybe they finish, they walk over and just see if another team needs any help. A little bit later, chief architect looks around
14:40
and sees three people, three teams with his flag up. Wow, I better go, I gotta go see what they need me for. Chief product owner's got a flag. Our chief product owner does the same thing. She's sitting with a team, she looks up, uh-oh, two teams have my flag up, I better go, right? So we pick some nautical signaling flags, right? A common one, we need the product owner,
15:01
we need the architect. Got a recommendation for a couple of other flags, two other flags I always use. One flag, we need a pizza, right? Give a team a way to signal that we need some food. Another flag that I tend to use is we're on a break. So real good kind of high bandwidth way
15:23
for teams to signal each other. This is great, if you think about this, boats out at sea and you signal each other without being able to email each other, well, this is how we're gonna signal each other in that meeting, okay? So this to me is a good way to run the sprint planning meeting.
15:40
If you have any questions as we go, let me know. I wanna talk about how do we coordinate teams, some of the techniques we use to coordinate teams during the sprints. The most important thing I find for coordinating work among teams is something we call a community of practice. A community of practice is a group
16:01
of like-minded or like-skilled individuals. All right, it's a group of people who have something in common. Maybe it's their skill set, maybe it's their interest. We have a group of people inside of our company after going to a conference like this who go back excited about test-driven development, right? And they're gonna go back and they're gonna figure out a way
16:20
to make test-driven development work inside of our company. So here I'm showing a couple of different communities of practice, a programming community, a testing community. One of the first places I ever discovered the need for a community of practice was a game studio I had consulted to. We were doing a sprint review. Now, game studio sprint reviews are fun.
16:40
You play the game, right? So we're doing the sprint review, playing the game. And we're playing level five and we finish the review. And in level six, we're doing a review of the team that did level six of this game. And the bad guys behave differently, right? In the first level, the bad guys, now this game is what's called a first-person shooter.
17:01
You're basically a game, you're a gun, you just shoot at everything that runs at you. And in the first level, the bad guys spread out. And the challenge was to see if you could, you know, shoot at all these guys who are all spread out. In the next level, the bad guys ganged up and the challenge was could you shoot them fast enough as they all ran at you from one direction?
17:21
Well, the poor programmer on the second team, artificial intelligence programmer, we asked him, he said, why do your bad guys behave differently than the bad guys an hour ago? And he said, well, we're on separate scrum teams. I said, yeah, I know you're on separate scrum teams. Why do your bad guys behave differently? And he said, because we're on separate scrum teams.
17:41
It turned out some bad scrum consultant had told them, you're only allowed to talk to your scrum team. You're not allowed to talk to other scrum teams, right? Bad advice, bad advice. And we said, not only do we want you talking to other scrum teams, we're going to make you talk to other scrum teams, right? So we created a community of practice in this case
18:01
of artificial intelligence programmers. We said, you have to get together and talk. Now in their case, it was a very informal community of practice. We got them together. We put, what we did is we ordered pizza every other week, put it in the lunchroom with assigned artificial intelligence programmers only, told them to meet and talk about artificial intelligence stuff.
18:21
They would get together and talk about, should we script this? Should we code it? Should it be table-driven? They're talking about things that were relevant to them. So communities of practice can take on lots of different forms. They can be informal, like the one I just described there. They can be formal. We might have a QA community that is led by a QA director
18:41
who formally gets people together and they talk about QA issues across a project. So communities take all different forms. Most communities will have some sort of virtual aspect, something like an email discussion list. Some communities will get together in person like our artificial intelligence programmers did. These are some of the attributes
19:01
I find successful for a community. Meant to be self-organizing. Normally going to be best when we don't have somebody directing them. Fairly organic. I'd like them to form up naturally within the company, within a project. I'd like to have a group get together, discover they need to get together and start discussing things
19:20
rather than a boss saying, okay, you group have to talk together. You group have to talk together. Sometimes a boss needs to do that but I prefer it when these things are more organic. Communities can span projects if we need to. But for now what I'm mostly focused on is the idea that we use these across a single large project. Not gonna be a full-time job.
19:41
I mean, this is something where you spend an hour a week as part of a community. You're reading the emails that go. I might be more active and that might be less but it's certainly not a full-time job. Some communities will have a community organizer, community coordinator. Done some consulting to IBM. IBM has a couple of communities where they have over 1,000 members
20:01
and they actually do have, if not full-time, close to it community coordinators. They have over 1,000 people in their Scrum Master community. That's not spanning a project. That's spanning across all of IBM. So community coordinators can be a part-time to full-time job if necessary. Now when we think about communities,
20:20
now I know I'm talking about this. You might be thinking about do you have any of these. Here are five levels of communities. So as we go through this, think about some that might be in your organization. Especially this first one here, unrecognized, an unrecognized community. This is a group of people, they don't even know they're a community yet. This is you and I going to lunch
20:41
not on any regular basis but just occasionally, once a week or so, maybe every other week, you and I go to lunch and we just talk about automated testing. You and I love automated testing, our favorite topic. And so we go to lunch periodically, grab a sandwich and talk about automated testing on our project. We don't even know it yet but we are the beginnings of a community.
21:02
The next level up is what's called a bootlegged community. A bootlegged community is where it's visible. Maybe we've invited one other person. Hey, we get together once a week and talk about automated testing. I know you're interested, come along with us. Now we've identified ourselves. We've realized we have a common thing here.
21:22
We talk about automated testing a lot. So now we're visible, not very big yet. Third level up is legitimized. This is where maybe the boss is picking up the bill or the boss is letting us do this during work time. The boss is saying, hey, I like those conversations you guys are having. You don't need to just do it at lunch, schedule meetings if you want. So starting to be legitimate.
21:41
We're not given any responsibilities yet. That comes with a supported one. A supported community of practice is one where we are given company facilities. Legitimized is where, or institutionalized is where we're given specific responsibilities as well. We are told, you are the group to figure out
22:02
how to get continuous integration going across our entire company. Right, so now we've been given a set of responsibilities. So five levels of community. We don't always start at the top one and we don't always end at that bottom one. Team might come, or community might come in in the middle. Team might move up rather than down
22:21
in the example I was giving. But just five different types of communities. Totally encourage you to do this. This to me is one of the most important things in scaling up. When we scale Scrum or Agile up, we need people talking across the teams. We might have five, 10, 15 Scrum teams. I need people on those teams talking to each other. So here's what we can do to help
22:42
have a vibrant set of communities. Design them for evolution. Know they will change. Do not make it too rigid. We want to have a dialogue between those in the community and those outside the community. I do not want to have this be like
23:00
a closed discussion list where nobody can see what's going on. The best way to bring others into the process is let it be visible. So let others, let outsiders talk into with this. Now we may have some private meetings. We may have some things that we just discuss in our community. But I want to have some sort of dialogue we can engage with outsiders. I don't want to have a single level of participation.
23:23
This is an easy example here. We think about news discussion lists, Yahoo groups, Google groups. Do I want every email or do I want a daily summary? That's a different level of participation. So an effective community allows us to participate at different levels. I can be involved for a while, then not.
23:41
I can read weekly digests instead of every email. Maybe we have email discussion lists. We also get together in person. I don't have time to get together in person, but I like to follow the emails. So try to have your communities exist at different levels. One of the things that you can do is to have public and private events.
24:02
It is sometimes nice to have private events. Members only, that makes us feel good. Members only get to go to this meeting or this celebration that we might have. But to bring others into our community over time, we need public events, both types of things here. Focus on value. One of my favorite communities of practice
24:21
is, it's disbanded now, but it was at Google. Google's been a client of mine for years and Google had a community of practice they called the testing grouplet. They call them grouplets. And the testing group there, what they did is they could have just focused
24:41
on writing a bunch of white papers. Think about testing Google. What a complex application to test, right? And so they could have had a testing community that wrote a bunch of white papers. And they would have posted them on a server. Nobody would have read them. What they did instead is the testing grouplet there created a program they called testing on the toilet.
25:04
Testing on the toilet, you might have heard of this. And they did, they wrote white papers, little one or two page white papers. And they posted them where you might expect, given the name of that initiative. And so their idea was that while you were in there, while they had you as a somewhat captive audience,
25:20
you might read a little bit about testing. And this was a very successful initiative there. They were focused on value. They were not just some ivory tower thing putting out white papers. They were putting out white papers, but they were putting them where they might catch your attention. So focus on value, delivering value to people.
25:41
Combine familiarity with excitement. Do novel things, but have the regular routine. Gets people involved, which is kind of the point with this last one, create a rhythm. Having our annual meeting or our monthly meeting, things like that, a monthly summary, things like that, help our communities be successful. To me, one of the most important things in scaling up.
26:02
Another thing that we do, and we hear a lot about this one, is something called a scrum of scrums meeting. Now you've probably heard about a daily scrum. Even if you're not doing scrum, you might be doing some agile process. A lot of teams will do this. I'll have a daily stand up or a daily scrum. So that's what I'm showing down here. Now suppose these are the teams on Microsoft Office.
26:22
I've got four teams on the left. They're doing, let's make that Word. The three teams in the middle are PowerPoint. The four teams on the right are Excel. Each of those teams doing their daily stand up, some in the morning, a couple in the afternoon. But every team doing it once a day. Word is one product though. I want the Word teams to talk. So we're gonna introduce something
26:41
we're going to call a scrum of scrums. So I'm gonna have those Word teams send one person and get together once, twice, maybe three times a week to talk about Word. But Office is a single product. Let's get one person to come from Word, one from PowerPoint, one from Excel,
27:00
and we're gonna call that a scrum of scrum of scrums. That one we're gonna do once a week. So this is a way to scale up the coordination on a project. Who goes and what do they do? Here we go. The agenda for this meeting, we start out with three questions.
27:20
What has your team done since we last met that might affect others? What will your team do before we meet again that might affect other teams? And what's your team having problems with that others might be able to help with? So we start out with three questions like that just to get the discussion going. If you're familiar with the daily scrum, you'll recognize those questions. Those questions were meant to be covered
27:40
as quickly as possible. Get done with that part of the meeting in five minutes. We do this just as a way to refresh each other's memory about what we're working on. The rest of the meeting is meant to be a discussion of open issues. In the old days, we would've just called it open issues list. At scrum, we gotta call it an open issues backlog. So here's a backlog of coordination issues,
28:02
things that need to be resolved. So we come together to talk through those issues. Scrum of scrums. Three levels up, we call scrum of scrum of scrums. Each team picks one person to go, does not need to be the scrum master, does not need to be the tech lead or senior technical person, anything like that. Each team selects who it is who should go.
28:26
Let's talk about distributing our teams. When we distribute a team, there's two general approaches we can take. The first approach is what I'm going to call a collaborating co-located team. Apologize for not using Norway in the example here,
28:42
but it was too long and skinny to put all the dots in. So I grabbed a map of France here instead. So here's one way to do this. If we have a set of people in the US, a set of people in France, we can set up two separate teams. We got the French team, I got the US team,
29:01
and they don't necessarily need to talk to each other much. They collaborate, but they don't work together on a daily basis. They collaborate a little bit, make sure they're building similar things, but they mostly let each other go. The other approach is to do what is called a deliberately distributed team. Deliberately distributed. Here I could have had an intact French team.
29:22
I could have had an intact US team. I had all the skills I needed in France to have an intact team there. I had programmers and testers and database people and designers in France. But we choose to deliberately distribute. I am going to instead have a team that is half in the US, half in France, a second team that is half in each as well.
29:42
So I've deliberately distributed the team. I have a background where a lot of the times where I've had distributed teams, it's been because of acquisitions. We acquired a company in another city, we acquired a company in another country, things like that. And one of the things I've learned from acquisitions is there's often a lot of animosity between people.
30:03
And when we set things up in a backup, when we set things up like this, that animosity can be a problem. I had one company where we worked and we had this fierce competitor, this company that we were just fighting. And we actually had pictures up in the conference room
30:20
of their executives. They had bull's eyes on them and stuff like that. And then we had just cut out pictures of people who looked like programmers out of newspapers and stuff. And we had them up in the wall and we had just made up names for them. And so we hated these guys. I mean, they were the enemy. And then all of a sudden we merged, right? And now you merge and you're supposed to get along
30:41
with these people that you've made up names for and stuff and that's tough. And so sometimes when you have this type of environment, even if it's not because of acquisition, this is tough. There's an us and them mentality that can come into things, right? So sometimes when we distribute, this is a better approach. Now this is more of a day-to-day hassle,
31:02
but it gets rid of some of that us and them mentality, right? So I'm not advocating either one of these approaches. I'm not saying one's better than the other. That would be impossible to do without seeing the situation, seeing the work, seeing the skillsets, talking to the people. So I can't say one of these is better than the other. My point with this right now
31:21
is make a deliberate decision, right? Most of the time, I'm gonna back up one more time. Most of the time we just do this because it's easier, right? Most of the time we just do this because it's easier. But I want you to make a deliberate decision. Maybe that's right, maybe it's not. Maybe we should be doing this. So the point would be if you're on a scaled-up project,
31:41
you're probably distributed across multiple locations, you have to make a deliberate decision. Should we be coordinating co-located teams? We're separate in our separate cities. We just coordinate our work. Or should we deliberately distribute things out? We get rid of some of the us versus them problems, but we got more hassle, right? But it depends on how far distributed we are, right?
32:01
This is one thing if I'm in the US and Paris, right? If I'm in Denver and Paris, I'm seven hours apart, that's a hassle. If I'm in Bergen and Oslo, not so bad, right? Get on the phone any time of day, could fly to each other if we need to, right? So it's much more feasible than if we're seven hours apart.
32:23
Another thing we have to do when we're coordinating teams is to create coherence. And I was writing, I was writing a book called Succeeding with Agile a couple years ago, and I wanted to write about distributed teams. And so I'm sitting there in my word processor and I type, one of the things you need to do
32:41
is create coherence. And I said, oh, I should look that word up. I want to make sure that word means what I think it does, right? So I looked up coherent to see what it meant. And I was like, wow, that definitely is the right word. Cause I said it's from the Latin for sticking together, right? And this is what we want to do. We want to create a team that is going to stick together. That is absolutely the right word, right?
33:03
So one of the things, some of the things we're going to have to do in creating a team that sticks together is acknowledge our cultural differences. Now we have to think about the big cultural differences. We have to think about the little cultural differences. They're small things between different cultures.
33:20
And even if we're in the same region or same country, perhaps, right? We have to think about our functional and team subcultures. By here, I'm talking about, OK, I'm in Colorado in the US. You're here in Norway. But we're both technical, right? That's a culture. That's a common culture, right? So I want to strengthen that. I want to build on that as a fight
33:41
against any other cultural issues that can be stronger. I want to build on the strength of our relationship as technologists. And I want to build trust by pushing the team towards early progress. Let me explain what I mean by these things. So acknowledge the cultural differences. There are, of course, great big cultural differences, right?
34:02
There was a great study done by an IBM employee years back where he looked at IBM employees across the globe and studied differences in terms of how different nationalities view uncertainty, how we view the long term, to something he called power distance, right?
34:21
Are we comfortable with a boss who's a lot more powerful than us? Or do we not like that? Do we want everybody to be equal, right? And so he studied these different types of things. And these are big cultural differences among us, right? We have to be aware of these things. So if we have a team that is spread across different cultures, we need to be aware of those things.
34:40
We need to talk about that a lot of times on projects, right? I always hate doing some of this because we start to generalize whenever we talk about things like this. But one of the things that I learned early on was with a team I was working with that was in California, where I was. And we were working with an outsourced part of our team
35:01
in India. And we had to figure out when to do some meetings. And we talked about it. And we picked a particular time I think we said we'd do it. It was going to be 8 o'clock in India. Now, 8 o'clock in the US, not a great time to meet. But if we have to get on the phone occasionally, 8 o'clock is not the worst time for most people in the US if they need to get on the phone occasionally. This is going to be like a once a week 15 minute phone call.
35:23
It wasn't the worst time in the world. Most people, if they got kids, starting to get the kids in bed or already in bed by then, nobody really eating dinner at 8 o'clock in the US. It's kind of late for dinner. So it was kind of an OK time. And I said, OK, it's 8 o'clock. Let's do it at 8 in the morning in the US, 8 o'clock in India. And then every month we'll switch. We'll do it the opposite.
35:42
And it turned out to be an absolutely horrible time in India. I found out that that was actually a very common dinner time for them. I didn't know that. So I was trying to be nice, trying to pick a convenient time, picked a horrible time. Even worse, when I asked them, I said, hey, is 8 o'clock OK?
36:00
Yeah, yeah, yeah, right? And I learned the other thing about India. And again, I'm generalizing here. Not real comfortable saying no to me. So more inclined to just say yes and go along with things. Don't really want to cause any trouble. So we've got to be careful with these things. We've got to learn those type of things. But I think just as important as the big cultural things
36:22
is often being aware of the smaller cultural differences. Little things like holidays, stuff like that. We've got to be aware about those type of things and the impact that those are going to have on our projects. We don't work the same hours. I was talking to somebody yesterday about, oh, when would you do a meeting here in Norway?
36:41
Somebody said, oh, we might do it at 8 AM. And I was talking about a team in California. No way would a team in California do a meeting at 8 AM. No way. Now, you may think that's early for you. I know not all Norwegian teams are going to be in by 8 AM. But the team I was talking to said yes, that's when they'd be in. Seems plausible. They go to the middle of the US, teams will be in by 8 AM.
37:01
But California, no way. No way a team in California is all in by 8 o'clock. These are little tiny cultural differences. Things like it's May 16, and we're scheduling a meeting for tomorrow. Not here, right? So we're going to have problems like that. We're going to have issues, right? You guys don't mind a meeting on July 4 in the US.
37:23
They do, because that would be the equivalent of May 17, right? So we've got to be aware of those type of things, just little things. As a way to fight against some of this, I'm real big on building up our functional and team subcultures. We are part of this team, and I want to build on that. I want us to feel like we're part of that team.
37:42
And I want to focus on our functional culture. We are all programmers, or testers, or whatever we are within our company. For example, I travel around a fair amount. One of the things I've learned from all the countries I've been in, despite all these differences we have, there's one thing I've learned about people in our industry, in the technology industry, software
38:02
industry, couple of things I've learned, in fact. We are much more likely to do things like own the Lord of the Rings box set and a Darth Vader costume than the rest of the population. These are things that are common to us. I assume some of you own those. Is it just me?
38:20
I'm the only one with a Darth Vader costume. Don't tell me that. So I know some of you have one. There are certain things that bind us together as our technology nerdiness. So I want to focus on some of those things. Now, early in my career, I hated one day a year.
38:40
One day a year I hated. I had the boss that made us used to go do these team-building things. And everybody's seen the joke ones where it's like, I'll catch you when you fall over, type of thing. We actually did that. And people would stand behind and have to catch me. And I was a little worried they were going to actually catch me. But we had to do those type of things.
39:01
And we had these days where we'd go to the lake and we would just party and stuff like that. And I'm like, please just let me stay in the office in code. I don't want to do this type of stuff. And I was so thankful when I soon progressed far enough up in my career that I was the boss and I didn't have to do those things. And I'd say, we're not doing that stuff. And I'm not totally opposed, but here's
39:22
what I found out about that. I later read this article that really resonated with me because the article said, don't do those things. It's real point, though, was don't do them too early. Don't do them too early. Now, I want a team to bond and come together and feel a shared sense of purpose.
39:41
But if we have the team do that too early, they bond around surface level things. Whoever happened to sit together at the company barbecue, they don't bond around anything meaningful, just whoever happened to talk to each other. And so early emphasis on relationship building is not good. I want to have that, let's call it that team building
40:02
budget, the amount of time or money we're going to spend on team building. I want to do that much later, once people have started to really learn each other, learn about each other. And then you and I are going to bond because we're the ones who are passionate about automated testing, not because we're the two who sat together during the barbecue. So I want to have team members bond around real things.
40:22
And the best way to do that is to save that team building budget for later. One of the best ways to get teams to bond together, and this is from this study I was reading, is to put them under pressure to deliver something early. We put a team under pressure. You've got to have this done by middle of July.
40:41
They don't have time for fighting and politicking and posturing, they just got to figure out a way to get it done by July. They're going to have to work together. So I'm a big fan of putting a team under, not artificial pressure, but having a team have to have that first early deliverable. We've got to have something done soon. It's a step towards our bigger goal. And not artificial, but having a team focus on something early.
41:06
Let's talk about how we communicate. Last few things here, all on communication. We've got to get together in person. I do not mind scaling a project up. I do not mind when we distribute. What bothers me is when I see a company choose to distribute a project and choose
41:21
to cut the travel budget. That is not going to work. We're going to have to get together in person occasionally. Now there's a couple of times that we can do this. The first is what is called a seating visit. A seating visit is where we try to get the whole team, or a large portion of the team, together at the beginning of a project.
41:41
One of my favorite teams that did this had a team in, I think some of the team was here, some of the team was in Amsterdam, and then they had part of the team in Bangalore. And the team in Bangalore would go live in Amsterdam. Part of the team would go live there for, I think, two months at a time. They had an apartment.
42:01
I think three members would come at a time. The apartment was more than big enough for the three people. And they'd live together in Amsterdam. They had some bicycles so people could get around. And those people came and essentially lived as part of the team. These were seating visits to get that initial relationship established. We need what are called contact visits. These are just kind of occasional visits.
42:21
And I'm a big fan of what are called traveling ambassadors on a project. I like old jazz. I like old jazz music. And there was a famous jazz singer, trumpet player, Louis Armstrong. You may have heard of him, probably have. And in the 50s, there were some problems
42:43
with countries kicking their US ambassadors out. US trouble, imperialism, all this crap. They were kicking US ambassadors out. And Louis Armstrong was talking about it and referred to himself as the real ambassador. And he said that what he did is
43:00
he traveled around, played the blues, and met people face to face. And he said, I'm a real ambassador. It's not these guys in there. You always picture ambassadors out of movies, stuff suits and stuff like that. They said, I'm the real ambassador. I travel around and I meet people. And so that's what I want on agile projects. I want people who travel around, meet people face to face, and write code together.
43:20
That's part of what this is about, establishing these longer term relationships. So it's important to have people who can do this on our projects, beyond just the initial seating visits. When we communicate on an agile project, when we get large, we're going to have to add more written documentation. I love the idea of face to face, of oral communication,
43:42
but we're going to have to write more. When you scale this up, when you distribute, you're going to have to write more. It's just going to happen. I want to encourage what is called lateral communication. I don't want to have all communication going through our scrum master here in the middle. I kind of assume that's our scrum master. I don't want to have that. I especially don't want to have that going by RSS, which
44:01
is what that looks like I've got going on there. So I should probably get that off of his head. I want team members communicating with each other, not every bit of communication through the scrum master. When I was a kid, I was 11 years old, and a grandmother who lived in Louisiana, southern part of the US. I went to spend a month with her one summer.
44:21
Hot, sticky, horrible place to be in the summer. And even worse, she lived in a mobile home, this metal trailer thing. No air conditioning, hottest, stickiest part of the US. I was 11 years old. And all I remember was complaining about the heat. Just constantly complaining to my grandmother about the heat.
44:40
And my grandmother, all I remember about her was her getting mad at me and yelling at me. It's not the heat, it's the humidity. OK, yeah, it wasn't. It wasn't all that hot there if I were to look at the temperature of like 27, 28. But it was also about 150% humidity. It was horrible. I remember laying in front of a fan the whole trip.
45:01
And so it's not the distance, it's the time zones. It's not the distance on a project that kills us. This is a map of a project I was involved in. We had a team in San Francisco, another one in London, another part of the team in Cape Town. You can imagine who the communication problems were with.
45:21
London and Cape Town got along fine. They communicated great. They were, what does it say, two hours apart. The challenge was the San Francisco team. They had no real overlap. It was a huge problem. Here's some things I want you to do for every meeting. So if you know anything about Scrum, you probably know there's this thing called a daily Scrum, 15-minute daily stand-up or daily Scrum
45:41
meeting. When I have distributed teams, I often make that a 20-minute meeting. And I tell people, start with five minutes of small talk. Because this is something that we miss when we have a distributed team. We don't talk about, hey, how'd your kid do in the football tournament? How's your mother-in-law's surgery? Did that turn out OK?
46:01
Things like that. So we don't have those type of discussions with team members when we're distributed. So I will often tell a team that we're going to do a 20-minute meeting. And I will tell them I mandate the first five minutes of small talk. I'll just sit there, I'll make them. OK, somebody talk about your family, somebody say something. We're just going to get to know each other a little bit.
46:20
Share the pain. Don't ever take the attitude, we're headquarters, we're doing the meeting at the right time for us. I'll see this sometimes, like the California team will say, we're doing it at 10 o'clock. I don't care that that's 6 PM in Oslo, we're doing it at 10 o'clock. Don't do that. Don't do that. Share the pain. Make it equally painful for both cities. That's what I was trying to do earlier when I gave the example
46:42
of the California team and the India team meeting at 8 o'clock. I screwed up because I didn't know it was dinner time. Make sure you know who's talking. Video conferencing is great for this. One of the teams that I worked with had video conferencing, but it didn't work very well. So I want to tell you what they did. They invented a technique called low fidelity video
47:02
conferencing. They took digital photos of each team member, sent them to the other city. The other city printed out the digital photos. They taped them onto little sticks. And then whenever they were doing a meeting, when somebody on the other side started to talk, somebody in this city would hold up the stick of the person who was talking.
47:22
Sounds silly, doesn't it? Sounds really silly. Here's what's sillier. People would stare at the stick. Thinking it was like his lips were going to start to move, people would look at it. They built a game out of this. I think it was, if you got two points, if you held up the right stick. So whoever grabbed the right person first
47:40
would get two points. But if you held up the wrong person, you lost three points. And they would track this, and at the end of three months or something, announce a winner. It was actually a very beneficial approach, because then when that person would come from the other city, we all felt much more like we knew the person. It was a weird little effect of this. So low fidelity video conferencing here,
48:02
we're still struggling with some of the technologies behind video conferencing. It's starting to get there. Get to see things like Cisco telepresence and stuff. We're going to have some really neat stuff in the future. So that's for every meeting. I want to talk just briefly about a couple of meetings here. So if you're distributed, here's what you can do for iteration planning.
48:22
One approach is to get everybody on the phone. Did I lose the microphone? Is it working? I know I moved it and it scratched. So one approach for iteration planning, get everybody on the phone. This works. This will work. We're in Oslo. We're in Trondheim. That's fine. We can all get on the phone.
48:41
Oslo and California, nine hours apart. This one's going to be pretty tough. So we may not be able to do this. I'm not going to go through all the pros and cons. All these slides are on my website. You can download the pros and cons. You can imagine most of the pros and cons with something like this, getting everybody on the phone for iteration planning meeting. Not going to work for a long meeting.
49:01
People are going to zone out. They're not going to pay attention. Another approach for doing iteration planning, and this is actually my recommendation, so this one I do want to talk about a little bit more, is to do it as two phone calls. Here's how we might do iteration planning here in California. Let's have California get on the phone at maybe 7.30.
49:25
They're not going to make it into the office. Most of them will have to call in from home. But let's get them to call in at 7.30. That's going to be 4.30 here. That's going to balance the pain I think about equally. We're going to stay on the phone for an hour. Sorry, but you guys are here from 4.30 to 5.30. But they had to get in the office
49:41
or at least get on the phone at 7.30. California, that's painful. So we're going to do 7.30 to 4.30 on the phone for one hour. After one hour, we're going to go home. It's 5.30. We're getting out of here. They are going to stay and continue planning. They can't finish it. They need us to finish it. But they're going to take it forward a level. They're going to do it for another hour or so. We'll come back tomorrow morning.
50:00
We'll pick up where they left off. They'll have left us a couple of questions. We'll change some numbers. You're crazy. That's going to take longer. Oh yeah, we can do that in that amount of time. We'll answer questions. We'll maybe add another product backlog item into the sprint. They'll come in tomorrow. They won't come in early. They'll come in their normal time, 10 o'clock or whatever it might be.
50:20
They'll look at what we did. They'll make one or two last changes. We're done. On the clock, this probably took 26, 27 hours. But for any one team, it only took two and a half, maybe three hours. So it didn't take any longer than an in-person meeting would take. But the meeting's done in two parts in two cities. Take a little bit longer than 24 hours to do,
50:40
but done very effectively. This is a normal way for doing this when we have a highly distributed team planning a sprint. Daily stand up, single phone call. We're distributed again. And we're perfectly fine. We're here and in Buddha, fine. Get on the phone. No problem. Here in California, that's going to be tough.
51:02
California does not want to get on the phone at eight o'clock every day. You do not want to stay for a five o'clock phone call every day. This is going to be a tough one. Another option is to write the meeting. Don't bother. Nobody's going to read it. If this is your answer, don't even bother. Nobody's going to read those things. So I don't recommend doing this.
51:22
Another approach is to do regional meetings. For the daily stand up, do regional meetings. Have the California group do their meeting. They'll do it when they want. They'll do it at 10 o'clock. You guys do your meeting. Do it at 830 here. So you do your meeting, they do their meeting. But it's very likely we've got one guy in California
51:43
who's up at midnight, California time. They're happy to call in and listen to the Oslo phone call. There's always a programmer up at midnight. So if we've got one of our team members who's up most nights at that time, they can call in and listen to your phone call. They'll report to their team. Maybe somebody here is willing to call in.
52:00
They're home, it's seven o'clock at night. They're willing to call in a couple times a week and listen to the California phone call. Not too big of a hassle. Somebody do it, maybe rotate it through the team members, do it three nights a week. You're only going to do it once every two months. So every two months, you spend three nights on a phone call with California. So we can have one person dial
52:21
into a regional call happening to the other and they can represent the local city to the other team. So that's the more common approach to doing this. Now we talk about it as a daily standup. I want to make something that's probably real obvious. We tend to not do this on the Fridays then. Nobody here is willing to call in Friday at seven o'clock to the California meeting.
52:42
The California guy's not up Sunday night perhaps willing to call into your Monday morning meeting. So often we have kind of four days a week. So it's not quite a daily standup when we do it with distributed teams. That's everything I had that I wanted to cover. We got a few extra minutes if you have any questions
53:01
you guys want to raise altogether. Anybody have any thoughts on doing this? Agile and Scrum do scale is one of the big keys for me to leave you with. So it definitely scales up. Distributed development's hard, it should be hard. All the things that we get out of Scrum and Agile I think help. The fact that we make progress visible,
53:22
the fact that we talk a lot. All these things make it harder, but it should be hard. I don't need to go anywhere. I'm just gonna hang around here for my next session which is on user stories while I hang around. Those of you who've been here before know I got a lot of stuff I'm trying to get rid of. So if you want planning poker cards or Scrum tattoos help yourself to any of the stuff I've got up here.
53:41
Other than that, thank you guys very much. I'll hang around and take some one-on-one questions. Thanks. Thanks.