Scrum and Scrum Master on a global team

Question

I work in a company that runs on a model of using one developer as tech lead (me), with an onshore co-ordinator/developer who co-ordinates the offshore team, and on the offshore team there's an off-shore co-ordinator. It sounds bizarre but it basically works.

The rest of the developers are offshore. I happen to be on a project now that has an additional onshore developer.

My question is, do you think I can use some agile methodologies here in a loose sense (we're a waterfall company, but maybe I could do scrum, sprints, planning poker, etc)? Also, do you think we could benefit from a scrum master? What if I didn't have the additional onshore developer (so basically I'd be one of two onshore developers then, and neither of us might be on the project full time)? What about me giving up the coding I do and becoming scrum master & tech lead? See my comment below for my duties now.

Answer 1

Many Scrum practices will be useful. Some of them will show up problems which you'll need to address differently, given the Waterfall nature of the project. Here are the things I think will be useful even in Waterfall:

• Daily stand-ups (can be done over the phone or video conf)
• Retrospectives (by phone, video conf or email)
• Incremental and iterative delivery

With regard to estimates and velocity, Scrum is a bit of an oddball in that it relies on the cost of change being fairly constant (see below), but doesn't actually prescribe any practices for doing that. If you'd like to start using estimation and measuring your velocity, I'd also take a look at the XP practices. Things like TDD, pair-programming (or use code reviews where distributed), collaborative code ownership, refactoring and continuous integration will also improve the quality of your software, especially given the team distribution.

However, the purpose of estimation and velocity is to allow effective, adaptive release planning (as well as encouraging team commitment). The idea is that a release-level burn-up or burn-down will show whether you're going to make the deadline or not. In Scrum, you'd respond to the discovery that you'll miss your deadline by cutting scope or extending the deadline. In Waterfall, you may not have that option. At least it will give you more information, letting you perhaps work more effectively over a longer period rather than crunching at the end, and certainly helping you to have conversations about that risk.

The real danger to you will be that by incrementally delivering and showcasing products, the chances of the business changing their mind is increased. This doesn't work well with a Waterfall budget or heavy change-control. Having a distributed team also makes it harder to communicate and adapt to changes. The alternative is to showcase the increments only within the team and deliver software that the business might not want - but that's the Waterfall mentality; the emphasis is on getting it right to start with, rather than reacting to the discovery that you got it wrong. If you can handle the politics of that, then any form of Agile is a good move (Scrum practitioners will often say that it's not Scrum if the team isn't co-located).

An experienced Scrum Master or coach might help. They're used to selling the benefits of iterative delivery and talking through the associated politics.

Answer 2

One of the scenarios where Scrum is generally not recommended is distributed team. It is very hard to make correct Scrum process when team members are not in the same workspace and the same timezone. Scrum is a lot about communication - not only between team members but also between team members and product owner. Is your product owner on your site or on off-shore site? In either case one site can't effectively communicate with product owner. The same occures with Scrum master. How can Scrum master solve impediments as fast as possible if he works in different time zone?

Another problem of your process description is actually tech-lead position. The Scrum team is self organized group of empowered and cross functional people (empower people is one of the main agile tenets). It doesn't mean they can't ask you for some advice but in the same time they don't have to and they can do it their way.

Many companies are doing exactly what you describe and they use something they call Scrum - I used to work for one such company. There is global fairy tale that off-shore development is silver bullet to recude costs but my experience is that you should not combine on-shore and off-shore developers in the same team. Either create two separate teams or move the whole development to one site.

Using distributed team also have additional costs in phone and video conferences as well as high costs in traveling. For example if you start a new project whole site (either off-shore or on-shore) should be moved for one or two sprints to single place so that people meet each other and get some basic relationship. It is always better for morale to personaly know each other.

Answer 3

I was doing this on my last team - Microsoft patterns & practices - for several years. Here's a white paper on what we learnt doing distributed agile (Scrum/XP):

http://www.ademiller.com/blogs/tech/2009/08/distributed-agile-development-at-microsoft-updated/

Here's a talk and some links to other people's work on the same topic:

http://www.ademiller.com/blogs/tech/2010/11/distributed-agile-development-at-oredev/

What's you're seeing seems pretty typical. The tech lead is onshore and spends a lot of time reviewing code, interfacing with onshore stakeholders etc.

Answer 4

My question is, do you think I can use some agile methodologies here in a loose sense (we're a waterfall company, but maybe I could do scrum, sprints, planning poker, etc)? Also, do you think we could benefit from a scrum master? What if I didn't have the additional onshore developer (so basically I'd be one of two onshore developers then, and neither of us might be on the project full time)?

No. The main point in agile development is a close communication loop instead of planing and design upfront.

In your case you will have difficulties with communications to the rest of the team.

Taking into account that you have a "waterfall" type organization and 2 coordinators on both sides I guess that some more or less working processes already established. You have some sort of design upfront, some sort of planning. It won be better with scrum.

Of course, things like daily meetings could be useful, but it is not "scrum" it's just a common sense.

Answer 5

You certainly can and there's no reason not to because your company uses a waterfall approach.

First, scrum meetings, or daily stand ups, or what ever you want to call them are good, just stick to the format of

1. Since last scrum I achieved
2. By the next scrum I will achieve
3. Unexpected impediments that affected what I achieved
4. Expected impediments between now and next scrum.

Then there's the idea of sprints. One of the biggest problems with off shore teams is keeping a handle on what they are producing. Use sprints to chop up the work into manageable sections rather than saying, "Here's a spec, see you in three months with the finished product"

Finally stakeholder involvement and feedback. This ties into sprints and is basically your chance to validate the work to date with the people paying for it and show there is progress. If there are issues you can nip them in the bud quickly.