Geographically Distributed Scrum Teams

They say Scrum is difficult and it quickly points out your weaknesses. After 2 years of inspecting and adapting with geographically distributed Scrum teams, and even though our processes are far from perfect, I can honestly say it usually feels pretty and my teams agree. We have high team satisfaction, client satisfaction and on the road to high profitability. Distributed Scrum seems to be working...

I am discussing a development team in Poland - SaaS (asp.net/silverlight/sql/soa) with product owners in Seattle, ... 9 time zones are a bit painful, but the whole team averages 40 hour work weeks, during basically normal work hours.

So what about Scrum? No 3x5 cards, that's too bad. Microsoft's Team Foundation Server (TFS) holds our electronic artifacts. We are using the eScrum Template for TFS. Every project always has a working burndown chart. Prior to the Daily Stand up we get an email with the burndown chart. In a Skype based meeting everyone answers the 3 questions fairly religiously. Because the answer to the question "What did you work on today?" is in TFS, we have some overlap. Hearing it on the phone frequently sparks some ideas for further followup discussions.

We run a hybrid scrum process, and I am more of a manager or director, but I do my best to maintain the role of "inspiration enforcement," not the "ruler." I also assist with removing blocking issues due to the lack of product owners on our time zone. I have to say our teams function very well without me, which allows me to easily work remotely most of the year. I just need to be extra available at the beginning of the sprint. The key here is allowing the team to do it's thinking, and I guess a little delegation helps also.

We also have other hybrid roles. Scrum Master / Dev Manager. As Scrum master they run all the meetings, help remove blocking issues, and make sure the burndown is heading downhill (positive direction). Not to mention as a manager ultimately responsible to making sure the product quality stays high, definitely not true Scrum, but I do believe if you ask the teams they feel like they run their own show, the manager is more of a support role, due to shortage of resources they happen to play the Scrum master also. This also allows the teams to says focused directly on their projects for the most part. One good thing is different geo, and different time zone makes it so the Scrum master does not need to do much blocking.

Using TFS. This is a long subject in itself but to keep it short and mention the highlights of what we use it for product backlog items, sprint tasks, bugs, backlog priority, sprint task priority, iterations, areas to name a few. We move unassigned backlogs into sprint backlog. We create developer and QA tasks linked to sprint backlog items. Sprints in TFS are basically just an iteration. BL items, tasks, and bugs are all just different workitems with different sets of clothing. You can also see articles on build automation and code reviews. (Soon).

Velocity. I have seen many posts on improving velocity. Because each team and company is so unique, and I think most of the time people have very large products they are delivering over many sprints, with semi-consistent teams. I don't feel most of what I have read is overly accurate to our situation or level of change, although scrum still excels for our projects. We do backlog (story point) estimation very quickly and early and I would not say it is particularly accurate, as we frequently change the scope before or within the planning meeting(s). We can have a pretty good idea of when things will be completed and that is good enough for us. We stick to assuming we will get 80% of the most important features completed each sprint. Trying to increase velocity might have some positive side affects, but currently assume we get more efficient as we go anyway.

The schedule - 4 week sprints
Day one Sprint Planning - Europe evening understand the backlog, includes PO
Day two Sprint Planning - Design meeting followed by task estimation and creation
About 10-12 days of developement (holidays...)
A stabilization day (just in case)
4 days UAT
Release every sprint

The meetings. Every 4 weeks we release a new sprint. Because we release each sprint we also need time for the customer to review, some teams are good at keeping the client reviewing all the time but frequently it is once a month. This means we need a time for user acceptance tests, although this is at the end of the sprint and they really don't have a choice at this time, our custom software teams give the client more choices. The only time we have for the sprint planning meeting is end of day Europe, beginning of day Seattle. We break the planning meeting into 2. Day one, go through the backlog and make sure we clarify any questions (3-4 hour meeting). The next day when they are fresh during, the morning the development team discusses in detail including tasks, and comes up with list of remaining quesitons, which can usually be handled by email. Developers and QA then go and create their tasks with personal hours estimates and the scrum master creates the burndown in TFS.

Sprint Review meeting, also a little non-traditional. Our product owners also play multiple roles which they end up being busy, so frequently they have not even reviewed all the changes before a Sprint Review. Our QA runs the sprint review. Goes through the Backlog shows what has been accomplished.

So there is an overview. Is it Scrum? Some might say no, I definitely say yes. Inspect and adapt gives leeway in the definition of Scrun. We do try to adhere to the Agile principals. I also agree there would be huge benefit in being collocated, at least some of the time, in many cases this would likely offset the cost of having developers in lower cost center locations. Don't get me wrong, I love this team, and they are extremely gifted, but as I said there is something very valuable in colocation. Good luck with your projects. ~alex