Software Development and Agile Thoughts from my mountain lair high above Denver, CO.

Wednesday, December 15, 2010

Fully distributed Scrum

(Or, "How we pitched the idea of letting everyone on our team work from home and got the thumbs up")
Back at the beginning of November I wrote about my recent experience as the scrum master on a highly distributed team.

For those that didn’t read (or don’t remember) that post, a key thing to know is that the team is comprised of several people who work from home. I ended that post (partly tongue in cheek I admit) saying how it would be interesting to take those team members that were still office based and have them work from home too. Well, starting early 2011 we’re going to give it a try!

The original suggestion was first seriously discussed in a team retrospective. On the premise that it’s easier to offer an apology than ask permission I sent the appropriate managers in our group an email indicating that the team had decided we were all going to work from home next sprint. That didn’t fly. Which isn’t surprising (although it was worth a try, or at least entertaining, no?) and a more considered proposal was requested.

Myself and the team duly worked on preparing a properly coherent argument, supporting data, benefits we expected, a concrete description of how we would run this little experiment and details on how we would measure the success (or otherwise).

I know there must be many other teams trying to reconcile the demands of their managers to “do agile” and also “leverage offshore resources” so I wanted to share details of the proposal that helped convince ours that trying the rather radical proposal of sending everyone in the office home might help.

What are we trying to do?
Before we go anywhere further, it’s worth properly answering this question. Lest there be any doubt, this isn’t about folks wanting to get up late, watch daytime TV and get their laundry on during teleconferences.

Therefore, if we have to live with this, we’re going to make it work as best we can.

At the heart of much agile advice is an emphasis on communication. The trouble is, with team members scattered across different timezones and locations, communication gets clumped into localized groups. People on the edges miss out. By putting everyone on an equal footing (working from home) everything becomes more equitable and information sharing is normalized allowing for a better functioning team. At least, that’s what we believe, and what we’re trying to do is prove that out.

Why did we want to try this idea of everybody on the team working from home?

A list of benefits, beyond simply the team working ‘better’ that we anticipated

A description of how we wanted to run the experiment

How we intended to evaluate the outcomes

The support we needed to get this going

I’ve already talked about the why, so let’s look at the others:

Anticipated benefits
Besides the hoped for improved communication, there are some other interesting and very tangible benefits we anticipate.

As I write this blog post the time in Colorado is 2.54pm. Meanwhile, in Hyderabad it’s 3.24am the next day. We have quite the time difference between some of our team members. Before Daylight Savings Time (DST) came to an end in the US this year it was just possible (if not entirely pleasant for everyone) to have a daily scrum via phone with all team members present. Now however, since Indian Standard Time doesn’t adjust, the earliest we can hold our daily scrums is just unreasonably late for our colleague there to attend every day. Although they do stay late to attend some of the sprint planning meetings and sprint reviews they’ve been missing a lot, including retrospectives.

One very worthwhile thing we can do operating as a team that works from home is create a more humane work/life balance for people. This will pay particular dividends for our colleagues in Hyderabad, allowing them to work the majority of their days at normal local business hours. They can they stop just early enough and save the remainder for meetings in the evening. Although nobody particularly wants to have to regularly work super early or super late hours, this is a much better arrangement than having to be still stuck in an office at 9pm at night.

In addition, there are another couple of benefits we see. One is immediately realizable, the other perhaps a longer term proposition. They are reduced environmental impact through less travel and reduced office space needs.

We may not be able to keep millions of these people off the road, but by allowing those that work in our team to do their jobs from home we can have a small but positive environmental impact. Who knows, maybe this innovative idea can spread.

As for the office space thing, if you can establish a team working at home, with perhaps continued but minimal office visits as needed then do you really need such large premises? With enough teams operating this way you could save on what you lease, on what you heat and so forth.

Running the experiment
Being a Scrum team convinced of the benefits of incremental and iterative development, we naturally intend to use the same approach to this experiment. Starting early 2011 we will try a sprint with everyone working from home.

At the end of that sprint, a large part of the retrospective will obviously explore how things worked. We’ll be asking ourselves questions like:

How well did that work?

What work well and what would we like to change?

Can we fix the things that didn’t work well?

If we think it was worthwhile and we can improve those aspects that didn’t go too well then we’ll repeat another sprint with any changes we need. With this approach we can pretty quickly home in on how to do this well, or equally quickly conclude that our original arrangement with two-thirds of the team staying office based was better.

Evaluating the outcomes
Many years ago I used to quite like the idea of capturing data you could analyze to objectively evaluate things. Peter Drucker is renowned for saying “What gets measured gets managed.”

I’ve since learned that if you measure the wrong things in the wrong ways then it’s more a case of “what gets measured gets gamed.” Regrettably I’m not renowned for saying that. Maybe one day.

However, we do need some way to determine how our experiment is going.

Agile thinking provides us with a few simple tools that we can employ: velocity, burn-up charts and cumulative flow spring most readily to mind. To some extent though there is the possibility that these could indeed be gamed, or unconsciously given treatment to provide the desired out come.

So besides those, we will also be looking at some other areas:

PO and stakeholder satisfaction. From their point of view are things better, worse or pretty much the same?

Team satisfaction. Do we feel that things are better, worse or pretty much the same?

If the experiment pans out well enough that we conduct a whole release with people working at home then we can utilize SLIM Metrics to observe productivity benefits.

Required support
Of course my team is not an island unto itself; we needed support to undertake this. First and foremost we needed the support of our management. Luckily the director of our group is open to innovative ideas and. After our presentation to him and a series of questions that the team was able to answer was willing to permit this experiment.

In more material terms we pretty much had all that we needed. People have broadband connectivity and telephones at home. They have quality spaces to work in. We do need to configure a few machines for remote access, and a few people needed new laptops. Other than that though, we’re ready to go.

In conclusion
The whole team is excited to try this. I think we’re onto something. I’m eager to see what our actual experience is like. Will things be better or just different? Next year, after we’ve run this experiment for a bit I’ll report back on how things have turned out.

@Ram -- is a good question. I would have thought that was possibly so too. But in fact we recently added a new guy in Colorado, so he was working from home from day 1...and he's been just awesome. No problems getting started.

Have been running remote (Home (kent), Work Bedfordshire & Bangalore) scrum working for past 3 months on a project for a large supermarket chain, it's worked really well (my first agile and remote working), but you can't beat regular face to face meetup every couple of weeks to help build team dynamic, beers after work don't work quite so well sitting around a skype session with a tin. My advice, if at all possibly (granted some times it isnt) make sure everyone knows each other face to face BEFORE the remote working starts, once they do communication works so much better and have a face face to every few weeks, preferably with a few beers afterwards.

interesting, but my experience shows it is impossible not to do the stuff like that - "...wanting to get up late, watch daytime TV and get their laundry on during teleconferences."May be I just still not seen a developer like that. :)

It was problematic almost every time (actually in 99,9%) to see developer online, when I was need his participation.

I don't like the idea "working from home", because it would be "half-work". As for me, I would better give him a one-two days vacation, so he will be ready to show his best at office :)

Again, it is probably because I still not seen "right" developer.

P.S. Jon, do not take it personally. Your attitude each time was on a very high level (I remember our work, and early (for you, obviously) meetings...)

@kass i think you need a new developer ;-) To be fair I agree it's not for everyone, I have worked with a few developers who you struggle to get to work efficiently (read at all) in the office, never mind letting them work from home. The right developers is crucial.