This is part 2 of an indefinite series of posts centered on using agile techniques in distributed development scenarios. (See also Part 1 on Reinterpreting th Manifesto)
At work, most of our projects have daily Scrums. For some of our projects this simple activity becomes much more laborious because part of the team is in a different time zone. In this post I will write about some key guidelines that we follow to make sure that Scrums remain productive and interesting. Without further ado, here we go:
Mutually agreeable/painful Time: The fact that a majority of times the two teams are in totally opposite time zones makes it very hard to agree on a time slot which is fair to both teams. In such a scenario, it is very important that both teams share the inconvenience by deciding on a time slot which divides the pain equally. One of our teams has their Scrum at 6:30 PM every day; this equates to early in the morning for the opposite team.
This is important because it ensures motivation for both the teams. If one team was getting the short end of the stick all the time, they would quickly become unmotivated and would not be as involved in the Scrums.
Partial participation is alright: The daily Scrums really don’t require every member of the team to be present every day. You only need the key stake holders. This is especially important if you are having the Scrums at inconvenient hours. We usually have the Scrum Master, the Product Owner, and from the Scrum Team we have the Analyst and the Senior Developers. The Senior Developers make sure that they are up-to-date with the progress and status of the members not present.
Standardize communication channels: Whatever means of communication you decide on using, one this is critical: standardize it. Do not go about using a different mode every day, because then you waste time in setting up and getting everyone on the same page. As a best practice, every team at my company has a fixed mode of communication with the on shore team:
- Some teams setup a permanent Dial-in conference bridge where everyone dials in. Everyone has the number and no time needs to be spent on distributing this information every day.
- Some teams use Skype to conference.
- Every team has a fixed time slot and they book meeting rooms in advance for this time slot.
Fix a duration and stick to it: This is probably true for any meeting, but more so for a daily meeting. It is important to make sure that if you have decided to have a 20 minute daily Scrum, then you don’t overshoot it. The best way to ensure this is to plan for the Scrum in advance so that everyone has a clear agenda beforehand and no one strays from it.
Scrum notes: The Scrum Master makes Scrum notes and shares them with the rest of team shortly after the Scrum. Our teams use a variety of collaboration platforms; one of the teams uses Basecamp and maintains all their notes on it. Some of the teams also record each Scrum meeting and share the audio files for anyone to review. This is also helpful if someone is not present during the Scrum and wants to learn what took place.
Have a defined Fallback Plan: Sometimes you can’t help but miss a Scrum. For such cases there should be a pre-agreed plan that everyone should execute when a Scrum doesn’t take place. Most of our teams make sure that they make Scrum Notes and post it onto their collaboration platform the very same day, thus allowing everyone else on the team to get up-to-date with the statuses.
The collaboration platform: It is very important to have some kind of a collaboration platform. This is usually software which allows the team member to share documents and messages from a central place. The team needs to get into the habit of starting and ending their day with a visit to this platform.
This platform is used to store project knowledge, Scrum Notes, Messages, etc. Ideally, there should be no other mode of communication other than through the collaboration platform. This ensures that everything is properly documented and at the same time everyone is aware of what’s happening.
At the end of every work day, our teams post their queries onto this; the team in the other time zone can then take care of these and post the resolutions back. This helps maintain a smooth development cycle.
--------------
A combination of all these helps us manage distributed Scrums quite efficiently, allowing us to maintain the agility in the Agile Development. Do you have any tips that can help improve this more? How do you manage distributed Scrums?
RSS feed
Comments
About scrums...
Your scrums sound very well-managed. At our company, we don't have distributed scrums, just scrums per se. But I'd just like to make some general comments about daily scrums.
First, I think they're a waste of time. At my company, they're mostly pointless gabfests. I just got out of one such scrum two minutes ago. Here's what happened, and it's typical of our scrums. The meeting started late--many stragglers came in up to 10 minutes late. The scrum was supposed to last 30 minutes, but guess what--it ran 25 minutes over. No surprise there. Our scrums rarely start or end on time. They have absolutely no focus. Practically none of the meeting was relevant to me. Mostly, people just started blabbering about their own projects. The meeting just jerked from one tangential issue to the next, with no logic or direction. As usual, one blabbermouth hogged up much of the meeting--he seems to love the attention.
At our scrums, it's as if something takes over as soon as the scrum begins. It reminds me of that science-fiction movie "The Blob," where a strange life form starts to consume everything in its path as it grows and grows. My co-workers just seem to lose all sense of time. There is absolutely no discipline or control. It's as if my co-workers are getting their "fix" for the day! If a TV series were made about our scrums, it would be called "Desperate Co-workers." Or if a song were made, it would be called "Addicted to Scrum." I truly feel that my co-workers are getting unmet ego needs fulfilled at our scrums: 1) the need for companionship, and 2) the need for attention. Anyway, our scrums are complete lunacy.
As I said, I'm speaking only about the scrums at my own company. Maybe if I participated in focused scrums I wouldn't mind them so much. However, having "daily" scrums to me seems like overkill. The vast majority of the time, my co-workers don't care what I'm working on, and I don't care what they're working on. If I really need to know someone's status, I'll already know it--by talking with them or e-mailing them. It's silly and inefficient to waste everybody's time listening to the boring (and often irrelevant) status reports of other people. There are other, better ways to communicate status that don't waste people's time. Having lots of meetings/scrums is a symptom of poor management IMO.
Here's an excerpt from a blog that summarizes my feelings on this issue.
From http://blogs.ittoolbox.com/eai/implementation/archives/why-your-meetings...
"The other complete waste of time is the supposed 'status meetings'. Waste of time. Status is for reporting – NOT MEETING. If you can’t have a team complete status reports on what they have done and what their issues are – get a new team. Even if there is an agenda – I never go to meetings that include status in the title. Project managers that operate with status meetings should simply be taken to the middle of a desert, shot in both knees and left for dead. 9 times out of 10 the other members of the meeting are not interested in my status report any more than I am interested in theirs. Assembling everyone to listen to them is a complete waste of everyone’s time. Don’t ever do this. There is only one reason a project manager should use a status meeting – he doesn’t know how to read. If you have a functional illiterate as a project manager on your project – my heart goes out to you."
It's all about team work...
@Sam
I can very well understand your feelings about the meeting which is (misleadingly) called Scrum in your company.
But there are some indicators in your report telling me, that it's not really what I would call a Daily Scrum what's going on there.
Nothing more, nothing less. There is no discussion going on. If the need of fine grained communication arises, there will be a subsequent meeting arranged after the Daily Scrum, where only the really involved people should participate. In fact, this is the most difficult task to keep in mind for the person who moderates the Daily Scrum (you don't even seem to have such).
If your company would stick to these simple rules (spread by Scrum literature) you would be fine with daily meetings. They assure that the answers to each of the three questions keep short and brief without "compressing" things into big but empty words or even dropping things completely.
Post new comment