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.
This is an authentic endeavor to make our team work better. You can argue till you’re blue in the face about the benefits of team co-location, or the silliness of splitting teams into onshore and offshore components when you’re trying to simultaneously implement Scrum, but the fact remains that many, many organizations are still going to insist you can’t move the furniture and you have to structure teams this way.
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.
“Craft a philosophy and live it.” – Umair Haque, bubblegeneration.com
How did we approach this?
Our presentation covered five key areas:
- 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
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.
An article in Forbes magazine in 2008 indicates there were as many as 17 million software developers in the world at that time.
More than 2 million of them are in India and the US is approaching 3 million.
Most if not all of these people spend time in cars or other transport every day commuting to and from work.
Indian emissions standards for motor vehicles lag about 5 years behind Europe, and in the US of course the majority of us love our gas-guzzling SUVs.
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?
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.
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.
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.