Transcript
We're talking about scaling agile up and distributed teams You got three key topics I want to discuss in this one.
First one, dependencies.
Talk about how to manage dependencies on an Agile project.
Second, I wanna talk about, how do the iteration planning meeting.
This is probably the most challenging meeting when we scale Scrum or Agil up and we have lots of people.
How do we plan a Sprinter iteration in the next couple of weeks?
And then third, wanna to talk how 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.
A couple of things we can do the manage dependencies.
The first thing I'd like you to do is to what is called rolling look ahead planning.
Now, if you heard one of my earlier sessions today, 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 on a meeting called iteration planning meeting or sprint planning.
And I said that that meeting's long and painful.
I say that the meeting might go three, four hours.
And said some teams might spend eight hours doing that.
So here's what I want you to do when you scale Agile up, when scale Scrum up.
Don't just plan one sprint.
It takes four to two hours to plan.
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.
And that's going to take two, three, four hours, then I you want to plan two more sprints.
But I wanted to do those in no more than 10 minutes, OK?
No more 10 than minutes.
We're going plan that second and third sprint at a much lower level of fidelity, a must lower-level.
That's higher level but lower level 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 is going 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 tend to think of these as something called user stories should be our last session
today and And so we take these user stories, we break them into tasks.
We estimate those tasks in hours.
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 task 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 minute, we plan the second and third iteration.
In this case, that'll be iterations five and six, because we're doing iteration four here.
So we want to plan iteration five in six in a maximum of 10. We're going to do it at a velocity level.
What this means is, were going look at the high level estimates we put on those backlog items.
Were going say something like, our average is 20 units of work per sprint.
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.
But you'll notice here we are not doing it at the task level.
We're bringing these things in at user story or product backlog level The idea here is to look ahead to sprints.
Here's why.
Suppose we only plan one sprint, my team plans its sprint you are 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 teams, very politely, can you please do this task for us?
It's part of your part in the system.
Can you do please this?
We need it done so we can finish our work.
You tell me no.
Because you've just planned your sprint.
Your full.
you can't do that six hour thing for me.
So what I want to do on my team, I wanna look ahead a second and third sprint, now I walk up to you and say, hey can please you this thing from me?
And you still say no.
You say, no, we're busy.
And I say I don't need it now.
Can you do it next sprint?
Oh sure, sure.
We can do a free next print.
So you'd do for me in the next spring, which would be sprint five up here, and now my team has it by the time we start sprint six.
so we are always looking ahead two sprints here.
Now this is not a commitment, it's not guarantee, not very rigorous at all.
It's just a best guess of what we gonna do one and two sprint ahead.
That's all we 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 is to share team members.
I got to list this.
This is a possibility.
But I've got say I'm not the biggest fan of this one.
Right?
I am not a big fan multitasking, of spreading people across multiple teams.
We spread people are cross multiple team, we lose a tremendous amount of productivity.
But we'll help address dependencies here.
So if one of your issues, one 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.
Here we might see sharing a couple people across different teams.
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 interface is what we're going to call an unattended interface.
An unattented interface, is one that, we know that exists, But we're not very worried about, right?
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 is nothing there to worry about.
And so we just don't pay attention to it.
It is there, But were not going to attend to.
We're just going 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 is going bite us.
But right now we are unaware of it.
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 type to be worried about.
One of the things that with these interfaces here is use an integration team.
Sometimes when we scale Scrum up, we need to introduce an Integration Team.
Often the Integration team can be a virtual team, let's say we have five teams, each of five team is 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 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.
It runs night, checks for interfaces between the code.
If it finds any problems, that build breaks.
The five members of the virtual integration team show up tomorrow morning.
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 to fix.
Right?
They talk about it, and they figured out who it was.
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, 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.
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.
I will see this very commonly where a company will say, yeah, well, I don't need this guy.
I'll put him on the integration team.
And 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.
All right, and I know it can be tempting to not put them there.
But the Integration team needs the best performers, 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 gonna blow up.
That team just said this, this thing just the other.
I remember one of the guys I was talking to was on a team like this and he happened to just, you know, 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, they needed to set headless equals true.
It just happened to come up in a discussion, and he heard it.
And then he's like about a week later in another meeting with a different team where they had come with the reason why they have to have head less equals false.
And these are all part of the same application.
And he was able to pick that up and notice it, and he ran the application with the wrong settings just to see what was going to happen.
It was some very subtle bugs.
This is a guy who was smart enough to pickup on that.
Now, obviously, you can't have headless true and headlessness false.
Even if you don't know what it is, it doesn't sound good.
It can't be both numbers or both values.
But this is a guy who is smart enough to remember it.
Most of us would have just heard that.
It's some weird statement.
I don't remember.
This guy heard the two statements, put that together.
So I need people in here who can look for dependencies, look subtle interactions.
so it's not a dumping ground for our poor performers.
That's three of the ways we handle dependencies.
I want to talk about the iteration planning meeting.
It's one of our bigger, more complex meetings, probably the hardest one to scale up.
So in iteration planting, 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, two general approaches to this.
The first thing is to stagger our meetings by a day.
Have some teams plan today, other teams planned tomorrow.
And that works up to a certain size.
This is a nice approach.
You have somebody on a large scale, Scum or Azole product we call a chief product owner.
Our chief product owner can now go to some meetings today, some meeting tomorrow.
Our Chief Architect can go 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 is an approach called the big room.
Now I'm going to let you in on a secret.
I have some clients that do this.
I've introduced this to them, and we do.
And I, of course, charge them.
I'd probably do this for free.
This meeting is so much fun when we do that.
I love this.
Now, you don't know any of my clients I'm doing this, of course.
You can't email them and tell them or tweet, hey, Mike will do big room techniques for for.
But I actually love doing.
It's one of favorite days when I get to go work with some of clients.
So let me describe what we're talking about here.
What we doing here is we bring all the teams together into a room.
All right, now let's assume we're all co-located for a moment.
We got our entire project here in Oslo.
So we are going to get a big room.
It holds 50 or 100 people, whatever we got on the project.
Typically, this meeting is going start out by somebody like our chief product owner making a few announcements.
You know, we've got the whole team together.
Let's make some announcements if there's anything to share with everybody.
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 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 grab some space around the realm.
each Team sits down with, if they have a dedicated product owner, their product 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.
Let's say we've got 10 teams, we may have six product owners total.
I got a chief product donor and maybe four or five product donors to help out.
So each team sits down.
If they have a product owner, their dedicated product sits with them.
And what's nice about doing this all in one room is each teams starts their planning meeting, but key resources like that chief architect can move between teams.
Our chief architecture can back and forth from teams who need him or her.
Or chief product owners can around between team.
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 walkover 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, so you just kind of wave me off.
And I go back to my team and I'm sitting here with my Team doing my work.
Look over five minutes later and you give me a nice thumbs up.
So I don't have that guaranteed dependency that we had in the first section of this class.
So the big room technique.
Now what I like about doing this is the ability for people to move around.
This is, when you do this, this why I liked 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 is to get nautical signaling flags, those flags that mean Admiral aboard, about to turn to starboard,
stuff like that.
Get those type of flags.
Give each team a set of that you are going to use.
So each might have four or five flags pick a meaning for the various flags.
One of the flags might mean something like, we need the chief architect.
Now any team that needs the 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 architects looks round and sees three people, three teams with his flag up.
Wow, I better go.
I got to see what they need me for.
Chief product owners 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'd better to go, right?
So we pick some nautical signaling flags.
Common one we need the product owner.
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.
We have a team of 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 for teams to single each other.
And this is great.
If you think about this, boats out at sea, and you signal each without being able to email each.
Well, this how we are going to see each in that meeting.
This to me is a good way too run the sprint planning meeting, If you have any questions as we go, let me know.
I want to talk about how do we coordinate teams, some of the techniques we'll use to coordinate team during the sprints.
The most important thing I find for coordinating work among teams is something we call a community of practice.
A community practice is a group of like-minded or like skilled individuals.
It's a groups of people who have something in common.
Maybe it's their skill set, maybe it is their interest.
We have a people inside of our company after going to a conference like this who go back excited, about test-driven development.
And they're going to go back and they are going figure out a way 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, testing community.
One of the first places I ever discovered the need for a community of practices was a game studio I had consulted to.
We were doing a sprint review.
Now, game studio sprint reviews are fun.
You play the game.
So we're doing the sprint interview, playing the games.
And we were playing level five, and we finished the review, And in level six, we are doing review of the team that did level 6 of this game,
the bad guys behave differently.
In the first level, the bad guys, now this game is what's called a first-person shooter.
You're basically a game, you're a gun, and you just shoot at everything that runs at you.
And in the 1st level the Bad Guys spread out.
The challenge was to see if you could shoot all these guys who are all spread-out.
In then next level The Bad guys ganged up and the challenge is could you shoot them fast enough as they all ran at from one direction.
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 guy's an hour ago?
And he says, well we're on separate Scrum teams.
I said yeah, I know you're in separate scum teams, but why are your guys behaving differently?
He said because we are on a separate team.
It turned out some bad scrum consultant had told them, you're only allowed to talk to your scrumb team.
You're not allowed talk other scrumm teams.
Bad advice.
And we said, not only do we want you talking to other scrum teams, we're going to make you talk the other Scrum Teams.
So we created a community of practice in this case of artificial intelligence programmers.
We said you have to get together and talk.
Now in their case it was a very informal community practice.
Put it in the lunchroom with a sign, artificial intelligence programmers only.
Told them to meet and talk about artificial intelligent stuff.
They would get together and thought about, should we script this?
Should we code it?
Shouldn't it be table driven?
They're taught 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 could be formal.
We might have a QA community that is led by a qa director 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 we'll get together in person like our artificial intelligence programmers did.
These are some of the attributes I find successful for a community, meant to be self-organizing, normally going to best when we don't have somebody directing them.
All right?
Fairly organic.
I'd like them to form up naturally within the company, within a project.
Id like to have a group get together, discover they need to get to together and start discussing things, rather than a boss saying,
OK, you group have to talk together.
You group to talked 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 too.
Right?
But for now, what I'm mostly focused on is the idea that we use these across a single large project Not going to be a full-time job.
I mean, this is something where you're spending an hour a week as part of a community.
You're reading the emails that go.
It might be more active than that.
Might be less, but it's certainly not a whole 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.
And they actually do have, if not full-time close to it, community coordinators.
They have a thousand people in their Scrum Master community.
That's not spanning a project, that's spanning across all of IBM, right?
So community co-ordinators can be a part- time to full time job if necessary.
Now when we think about communities, 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 of some that might in your organization.
Especially this first one here.
Unrecognized.
An unreconnaised community.
This is a group of people, they don't even know they're a community yet.
All right, this is you and I going to lunch, not on any regular basis, but just occasionally, once a week or so, maybe every other week,
you an I go to a lunch and we just talk about automated testing.
You and love automated test, our favorite topic.
And so we go lunch periodically, grab a sandwich and talk automated on our project.
We don't even know it yet, we are the beginnings of a community.
The next level up is what's called a bootlegged community.
A bootleg 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.
All right, now we've identified ourselves.
We've realized we have a common thing here.
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, right?
Or the bosses letting us do this during work time, all right.
The boss saying, you know, 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 it's starting to be legitimate.
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 we're given specific responsibilities as well.
You are the group to figure out how to get continuous integration going across our entire company.
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' always end at that bottom one.
A community might come in in the middle.
Team might move up rather than down in 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 5, 10, 15 Scum teams, I need on those teams talking to each other.
So here's what we can do to help 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 this to be like 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 some things that we just discussed in our community.
But I want to have sort of dialogue we can engage with outsiders.
I don't want have a single level of participation.
This is an easy example here.
Here we think about news discussion lists, Yahoo groups, Google groups.
Do I want every email or do I wanna 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, I could read weekly digest instead of every e-mail.
Maybe we have e mail discussion lists, we also get together in person.
And I don't have time to get to gather in-person, but I like to follow the e mails.
All right, so try to have your communities exist at difference levels, One of the things that you can do is to have public and private events.
It is sometimes nice to private event, 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 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 practices they called the testing grouplet.
They call them grouplets.
What they did is they could have just focused 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've read them.
But they did instead is the testing group there created a program they called Testing on the Toilet.
Testing on the toilet, you might have heard of this.
And they did, they wrote white papers, little one or two page whitepapers, and they posted them where you may expect given the name of that initiative.
So their idea was that while you were in there, while they had you as a somewhat captive audience, You might read a little bit about testing.
And this was a very successful initiative there.
They were focused on value.
There were not just some ivory tower thing putting out white papers.
Yeah, they were putting white paper, but they're putting them where they might catch your attention.
So focus on values, delivering value to people.
Combine familiarity with excitement.
Do novel things, 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, help our communities be successful.
To me, one of the most important things in scaling up.
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 scrumb.
Even if you're not doing scrumm, you might be doing some agile process.
A lot of teams will do this.
I'll have a Daily Standup or a Dayly Scrum.
So that's what I'm showing down here.
And I suppose these are the teams on Microsoft Office.
We'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 team's on the right are Excel.
Each of those teams doing their daily stand-up, some in the morning, a couple in afternoon.
But every team doing it once a day.
Word is one product, though.
I want the Word teams to talk.
So we're going to introduce something we are going call a scrum of scrums.
And so I'm going have those Word team send one person and get together once, twice, maybe three times a week to talked about Word.
But Office is a single product.
Let's get one person to come from Word, one from PowerPoint, and one for Excel.
And we're going to call that a scrum of scrums of scums.
That one we are going do once a week.
So this is 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.
What has your team done since we last met that might affect others?
What will your time do before we meet again that may affect other teams?
And what's your teams 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 as quickly as possible.
Get done with 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 have just called it open issues list.
At Scrum, you've got to call it an open-issues backlog.
So here's a backlog of coordination issues, things that need to be resolved.
And so we come together to talk through those issues.
Scum of scrums.
Three levels up, be called scrum, of scum.
Each team picks one person to go, does not need be the scrumm master, doesn't need the tech lead or senior technical person,
anything like that.
each team selects who it is who should go.
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, but it was too long and skinny to put all the dots in, right?
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 US, a of set people France, we can set up two separate teams.
We got the French team, I got US team.
And they don't necessarily need to talk to each other much.
They collaborate, they 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.
I Could have an in tact us team I had all the skills I needed in France to have in intact team there I'd programmers and testers and database people and
designers in france, but we choose to deliberately distribute I'm going to instead have a team that is half in the US half In France a second team,
that has happened each as well, so I've deliberately distributed the team and 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, acquired another company another country, things like that.
And one of things I learned from acquisition is there's often a between people.
And 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.
We actually had pictures up in the conference room of their executives.
And they had bullseyes on them and stuff like that.
And then we had just cut out pictures of people who looked like programmers out of newspapers and we have them up in the wall.
We had made up names for them.
So we hated these guys.
They were the enemy.
Then all of a sudden we merged.
Now you're merging, you were supposed to get along with these people that you've made names up for and that's tough.
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.
So sometimes when we distribute, this is a better approach.
Now this more of a day-to-day hassle, but it gets rid of some of that us and them mentality.
So I'm not advocating either one of these approaches.
I am not saying one is better than the other.
That would be impossible to do without seeing the situation, seeing work, the skill sets, talking to the people.
So, I can't say one these are better then the others.
My point with this right now is make a deliberate decision.
Most of the time, and I will back up one more time.
We just do this because it is easier.
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 is not, and maybe we should be doing this.
So the point would be, if you're on a scaled up project, you are probably distributed across multiple locations, so you have to be deliberate.
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.
But it depends on how far distributed we are.
This is one thing.
If I'm in the US and Paris, if I am in Denver and in Paris and I seven hours apart, that's a hassle!
If i'm Bergen and Oslo, not so bad.
I can get on the phone anytime of day.
Could fly to each other if we need to.
So it's much more feasible than if we're seven hours apart.
Another thing we have to do when we are coordinating teams is to create coherence.
And 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 type, one of the things you need to do is create coherence.
I said, oh, I should look that word up.
But I want to make sure that that means what I think it does.
So I looked up coherent to see what it meant.
It's like, wow, that definitely is the right word.
Because it said it's from the Latin for sticking together.
And this is what we want to do, we wanna create a team that is going to stick together.
That is absolutely the right word.
So one of the things, some of things we're gonna have to doing creating a teams that sticks together is acknowledge our cultural differences.
Now, we have to think about the big cultural differences.
We have think the little cultural difference.
They're small things between different cultures.
And even if we're in the same region or same country, perhaps, right?
We to have about our functional and team subcultures.
Right here, I'm talking about, OK, in Colorado, the US, you're here in Norway.
But we're both technical, right?
That's a culture.
That is a common culture, all right.
So I want to strengthen that.
I wanna build on that as a fight against any other cultural issues that can be stronger.
And I 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 difference.
Right?
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.
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?
And so he studied these different types of things.
And these are big cultural differences among us.
We have to aware of these things, so if we have a team that is spread across different cultures, we need to being aware those things and we talk about
that a lotta times on projects.
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 outsourced part of our team in India.
And we had to figure out when to do some meetings, and we talked about it, we picked a particular time, I think we said we'd do it.
It was gonna be eight o'clock in india.
Now eight in the US, not a great time to meet, but if we have to get on the phone occasionally, eight is not the worst time for most people in US that
they need to go on phone, occasionally.
This is gonna like a once a week, 15 minute phone call.
Um, it wasn't the worse time in world.
Most people, they got kids, starting to the kids in bed, or already in bad by then.
Nobody really eat dinner at 8 o'clock in the US.
It's kind of late for dinner.
So I was kind an OK time.
I said, OK, 8 O'Clock.
Let's do it at eight in morning in US, eight o clock in India, and then every month we'll switch.
We'll do the opposite.
And it turned out to be an absolutely horrible time in Indian.
Right?
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 pick inconvenient time, picked a horrible time.
Even worse, when I asked them, I said, hey, is 8 o'clock OK?
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 got learn those type of things but I think just as big as a lot, just important as the big cultural things
is often being aware of the smaller cultural differences.
Right?
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.
Right, we don't work the same hours.
I was talking to somebody yesterday about, oh, when would you do a meeting here in Norway?
And somebody said, well, you might do it at 8 AM.
And I was talking about a team in California.
No way would a time in a California do a meeting at 8 AM.
There's no way.
Now, you may think that's early for you.
I know not all Norwegian teams are going to be by 8 am.
But the team I'm talking to said, yes, that when they'd be in.
Seems plausible.
They go to the middle of the US.
Teams will be him by eight AM, but California, no.
Way a Team in Californias all in by 0 o'clock.
These are little tiny cultural differences, things like, You know, it's May 16th, and we're scheduling a meeting for tomorrow.
I'm not here, right?
So we are going to have problems like that.
We're going have issues, you guys don't mind a meet on July 4th in the US, they do, because that would be the equivalent of May 17th.
So you 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 the team, and I want to build on that.
I wanna us to feel like we're part that team.
And I focus on our function culture.
For example, I travel around a fair amount.
One of the things I've learned from all the countries I have been in, despite all these differences we have, there's one thing I learned about people in
our industry and the technology industry, software industry.
A couple of things, 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 population.
These are things that are common to us.
I assume some of you own those.
Is it just me?
I'm the only one with a Darth Vader costume?
Don't tell me that.
So I know some of you have one, right?
There are certain things that bind us together as our technology nerdiness, so I want to focus on some those things.
Early in my career I hated, one day a year, 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.
Right?
And people would stand behind and have to catch me.
I was a little worried they're going to actually catch ME.
But we had to do those type things and we have these days where we'd go to the lake and just party and stuff like that and I'm like,
Please just let me stay in the office and 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 as the boss and I didn't have to those things.
Right?
And say, we're not doing that stuff!
And, I'm not totally opposed, but here's what I found out about that.
Or later read this article that really resonated with me.
Because the article said, don' do those.
It's real point, though, was don do them too early.
All right, don't do them too early.
Now, I want a team to bond and come together and feel a shared sense of purpose.
But if we have the team do that too earlier, they bond around surface level things.
Whoever happened to sit together at the company barbecue, right?
And they don' bond anything meaningful, just whoever happened talk to each other.
And so early emphasis on relationship building is not good.
I wanna have that, Let's call it that team-building 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 about each other.
And then you and I are going bond because we are the ones who are passionate about automated testing, not because were the two who sat together during
the barbecue.
So I want to have team members bond around real things.
And the best way to do that is to save that team building budget for later.
One of the ways to get teams to bond together, and this is from this study I was reading, is put them under pressure to deliver something early.
We put a team under a pressure.
You gotta have this done by middle of July.
They don't have time for fighting and politicking and posturing, they just gotta figure out a way to get it done by July.
They're gonna have to work together.
So I'm a big fan of putting a team under, not artificial pressure, but having a time have that first early deliverable.
We gotta have something done soon.
It's a step towards our bigger goal.
And not artificially, having the team focus on something early.
Let's talk about how we communicate.
Last few things here, all in communication.
We've got to get together in person.
I do not mind scaling a project up.
And you not mine when we distribute.
What bothers me is when I see a company choose to distribute a product and choose, to cut the travel budget.
That is not going to work.
All right, we're going have to have together, in-person, occasionally.
Now, there's a couple of times that we can do this.
The first is what is called a seeding visit.
A seedings visit is where we try to get the whole team, or a large portion of the team together at the beginning of a project.
One of my favorite teams that did this had a team in, I think some of team was here.
Some of them was in Amsterdam, and then they had part of their team Bangalore.
And the Team in Banglore 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, three members would come at 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 a 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.
I'm a big fan of what are called traveling ambassadors on a project.
I like old jazz.
Old jazz music.
And there was a famous jazz singer, trumpet player, Louis Armstrong.
You may have heard of him, probably have.
In the 50s, There were some problems 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, you know, that what he did is he traveled around, played the blues, and met people face to face.
And, he says, I'm a real ambassador.
Right?
It's not these guys and you always picture ambassadors like out of movies, right?
You know?
Stuff suits and stuff like that.
They said I am the real Ambassador.
I travel around and I meet people.
That's also what I want on Agile projects.
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, but we are going have write more.
When you scale this up, when you distribute, you're gonna have more to write.
It's just going happen.
And I want to encourage what is called lateral communication.
in the middle.
I kind of assume that's our Scrum Master.
Especially I don't want to have that going by RSS, which is what that looks like I've got going on there.
So I should probably get that off of his head.
When I was a kid, I as 11 years old, had a grandmother who lived in Louisiana, southern part of the US.
I went to spend a month with her one summer, hot, sticky, horrible place to be in the summer.
And even worse, she lived a mobile home, this metal trailer thing.
No air conditioning, hottest, stickiest part in US, as I 11-years-old.
All I remember was complaining about the heat, just constantly complaining to my grandmother about heat.
And my grandmother, all I remember about her was her getting mad at me and yelling at.
It's not the heat, it's the humidity.
Okay, yeah, and it wasn't all that hot there.
If I were to look at the temperature, like 27, 28, but it was also about 150% humidity, right?
It was horrible.
I just remember laying in front of a fan the whole trip.
And so it's not the distance.
It's the time zones, right?
It is not a distance on a project that kills us.
This is a map of a product I was involved in.
We had a team in San Francisco, another one in London, and another part of the team Cape Town.
You can imagine who the communication problems were with.
London and Cape Town got along fine.
They communicated great.
There 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 Scum 15-minute daily stand-up or daily scrum 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's your kid doing in the football tournament?
How's How's your mother-in-law's surgery?
Did that turn out OK?
Things like that.
So we don't have those type of discussions with team members when we're distributed.
I will often tell a team that we are going to do a 20-minute meeting, and I'll tell them I mandate the first five minutes of small talk.
And I just sit down and make them.
OK, somebody talk about your family.
Somebody say something.
We're just going get to know each other a little bit.
Share the pain.
Don't ever take the attitude, we' re headquarters, We are 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 p.m.
in Oslo.
We're doin' it 10. 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 of the Californian team and the India team meeting at 8 o clock.
And I screwed up because I didn't know that 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 conferenced, but it didn't work very well.
So I want to tell you what they did.
They invented a technique called low-fidelity video conference.
And they took digital photos of each team member, sent them to the other city.
The other the city printed out the digital photo, and they taped them onto little sticks.
Then whenever they were doing a meeting, when somebody on the others side started to talk, somebody in this city would hold up the stick of the person
who was talking, right?
Sounds silly, doesn't it?
It sounds really silly.
Here's what's sillier, people would stare at the 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, you got two points if you held up the right stick.
So whoever grabbed the person first would get two point.
But if he held the wrong person, he lost three points.
And they would track this, and at the end of three months or something, announce a winner.
It's 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.
There's a weird little effect to this.
So low fidelity video conferencing here.
We're still struggling with some of the technologies behind video conference.
It's starting to get there.
You 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 about just briefly about a couple of meetings here.
So if you're distributed, here's what you can do for iteration planning.
One approach is to get everybody on the phone.
Did I lose the microphone?
It's still working?
Okay.
Okay, I know I moved it and it scratched.
All right, this works.
This will work.
We're in Oslo.
we're Trondheim.
That's fine.
All we can all get on the phone.
Oslow 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 go through all the pros and cons.
Here, all these slides are on my website.
You can download the Pros and Cons.
you can imagine most of the Pro's and Con's with something like this, getting everybody on their phone for iteration planning meeting.
Not going work for a long meeting, people are going zone out.
They're not gonna pay attention.
Another approach for doing iteration planning, and this is actually my recommendation, 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 Let's have California get on the phone at maybe 730. 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 calling at 7 30. That's going be 4 30 here.
And that's gonna balance the pain, I think, about equally.
We're going stay on their phone for an hour.
Sorry, but you guys are here from 430 to 530, But they had to get in the Office, or at least on phone, at seven thirty.
California, that is painful.
So we're gonna do 7 thirty to 4 thirty, on our phone one hour, after one-hour, We're going to go home, it's 5.30, we're getting out of here.
They are going stay and continue planning.
I can't finish it, they need us to finish.
But they're gonna take it forward a level.
There gonna do it for another hour or so.
We'll come back tomorrow morning, will pick up where they left off.
Though have left us a couple questions.
Will change some numbers, you're crazy, that's going take longer.
Oh yeah we can do that in that amount of time.
Well answer questions, well maybe add another backlog item, product backlog into the sprint.
Right, though come in tomorrow.
They won't come in early.
They'll come into their normal time, 10 o'clock or whatever it might be.
they'll look at what we did.
There'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.
The meeting is done in two parts, in to cities.
It'd take a little bit longer that 24 hours to do, 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.
All right, we are here and in Buddha, fine, get on the phone.
No problem.
Right here in California, that's going to be tough.
California does not want to get the on phone at 8 o'clock every day.
You do not wanna stay for a 5 o clock phonecall every.
So this is going 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 gonna read those things.
So I don' recommend doing this.
Another approach is to do regional meetings.
For the daily stand-up, do a regional meeting.
Have the California group do their meeting, they'll do it when they want, at 10 o'clock.
You guys do your meeting.
Do it at 8.30 here.
So you do you're meeting, they do their meeting but it's very likely we've got one guy in California 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.
You know, their home, it's 7 o'clock at night.
Their willing call a couple times a week and listening to the California phone-call.
It's 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 once every two months.
So every 2 months, you spend 3 nights on a phone call with California.
We can have one person dial into a regional call happening to the other, and they can represent the local city to other team.
That's the more common approach to doing this.
Now, we talk about as a daily stand up.
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 7 o'clock to the California meeting.
The California guy is not up Sunday night, perhaps, willing call into your Monday morning meeting, so often we have four days a week,
it's not quite a daily stand-up 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 you guys want to raise altogether.
Anybody have 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 Scum and Agil I think help.
The fact that make progress visible, the fact we talk a lot.
These things make it harder, but it shouldn't be.
Other than that, thank you guys very much.
