One of my colleagues Anthony Langsworth has recently documented his experiences and opinions on [Working Remoely and Successfully](http://randomactsofarchitecture.com/2011/12/23/working-remotely-and-successfully/ . He deals with it specifically from the perspective of an architect, an individual contributor, and I would agree with all the points he brings up.

Before I get to the purpose of this post I want to add that his point about video conferencing really resonated with me. A good setup, like the halo suite we had, can certainly substitute for many face to face meetings and could easily be used for a lot of scrum meetings. Unfortunately that kind of suite becomes a victim of it’s own success. Once our sales organisation became aware of how good the halo suite was, it was booked solid in that crucial two hour overlap that we had with the US office.

As Anthony says, try it yourself. I would add that if you can get a setup dedicated for your engineering department’s use, then by all means build processes around it, but don’t rely on it if you have to share.

But my purpose in this post is not to rail on about video conferencing. However it does introduce the idea of how, and in fact why you should incorporate remote workers into a scrum/agile team.

So why even bother?

There are several reasons why you should endeavour to include the facility for remote work in a scrum/agile team, or for that matter in any software development team.

The first reason to consider remote workers is that in enterprise scale organisations distributed teams are a fact of life. To get to the size they are most enterprise scale organisations grew with some level of merger/acquisition. That inevitably results in teams that are spread out over the country and indeed over the globe. In large organizations, outsourcing is a fact of life. So as an engineering director you will either inherit, or be required to develop, capability in India, China, Russia, or wherever else skilled labour can be had at a reasonable fraction of a US salary.

Even if you have all your engineers co-located, it’s inevitable that you yourself will probably report to someone on a different continent, or at least in a different timezone. You will also have shared engineering services like localisation, and architecture that you need to include in your processes. And let’s not forget technical technical support who will probably have some presence in at least three timezones.

So, if your development processes only support co-located contributors because they consist of sticky notes stuck to a meeting room wall, you are reducing your options for staffing, and excluding key contributors that make your product better.

The second reason to consider remote workers is that it gives you an edge in a competitive labour market. Unless you’re a merchant bank with deep pockets you can’t just buy the best developers. And if you want to keep your best people from being poached by organisations with more budget that you have, you have to change the game.

Usually in engineering organisations this is done by encouraging casual dress, having break rooms with X-Boxes etc. But working from home for one day a week is a privilege that is a lot more sticky. Not only can you equate it more easily to money, but once your staff have structured their family lives around it, they will think twice before taking a higher paid position at a much more conservative organisation like a bank. And sometimes that all you need to keep them.

I’m not suggesting that you should neglect your developer’s remuneration, but the harsh reality is that the only time in my career as a manager that I didn’t have to worry about competing with financial institutions for staff was during the first two years of the GFC.

The third reason to consider remote workers is because of a side effect that supporting them generates. Engineering is not only about engineers. You have to provide status up the management chain, and you need input from architecture, sales, support and product management. As I mentioned earlier in large enterprises you are unlikely to have all these on site. The more of your processes you can expose externally, the better your chances of getting the key people involved early. I’m not saying that everyone should see everything, what you expose is up to you. But if your processes are sticky notes on walls and you decide to email a daily scrum burn-down. Generating that e-mail will be a horrible, unreliable, manual process that will either send your scrum masters mad, postal, or more likely somewhere else.

What is the key enabler for remote workers?

Right, so you’ve seen the light and don’t want to rule out remote workers. You might have gleaned by now that I’m not a fan of post it notes on walls. As a way of introducing scrum, for small projects, and possibly in planning meetings, they are a fluid, tactile tool that encourages discussion. But for big ongoing projects you should use some kind of planning system like Version One, or X-Planner.

Your needs will vary, but as a bare minimum you should ensure that the system has the following features;

1.Some kind of backlog for user stories and a way to break epic’s down into items that are consumable by your team/teams.

1. Sprint task list management.
2. A back end database, or accessible API’s
3. (Optional) Automatic generation of basic status information like burn down and sprint summaries are useful both for yourself and your stakeholders.

The reality is that almost any system will hit this minimum list and in fact you will get a veritable plethora of additional stats and graphs and sprint planning, bug tracking etc. Before you start implementation ensure that it has sufficient API’s and hooks to integrate it with systems you have already in place that you don’t want, or can’t replace (e.g. bug tracking, or release planning).

The beauty of using an online system over sticky notes is that when a dev has competed their current task early (probably because they’re at home in a distraction free environment) they can log on and pick up another. Also, they can dial into the daily stand ups, and still get a sense of who is working on what. I have seen a junior dev pick up a task in a standup, only to have one of my principals chime in from the phone with an idea, or a request to review the code because they’re familiar with that particular area. They can do this when they have the task details in front of them.

Like bug tracking systems, and source code control systems, I consider an online backlog/sprint management system essential to the working of a well run software development team. And as long as it’s web accessible then your engineers and managers, who will be using it every day, can do so whether they’re at the office, at home, or on the road.

You’ll unshackle your developers from their desk’s, and you’ll get a number of other benefits as well, which I’ll go into in a later post.