Agile and the Remote Worker

I was delivering Agile Project Management training a couple of weeks ago and was hit with a question that represents the current times.  The time of the Remote Worker.

The client Project Managers were concerned with the constant talk of co-location and face-to-face communication.

They were concerned because they had recently received what they considered a really nice benefit – to work remotely (from home) a couple of times a week.  The benefit of working remotely allows folks to eliminate hours of commuting time per day, resulting in increased quality of life.  I’m not exaggerating.

They asked “How can we keep this benefit and still ‘do agile’?”  And “I thought TW was successful at distributed agile?”.  I replied, there are different levels of ‘agile practices’ and different levels of benefits you receive from adopting those practices.   And what we are talking about here is not distributed agile.  It’s one-off workers at home.  Not the same thing.

I am a trainer for TW Studios.  My 5 teammates are spread across the world – Chicago, St. Louis, San Francisco, London and Bangalore.  We get together as a whole team, hardly ever.  We do have smaller local get-togethers. 

As a trainer, I’m on the road a lot.  When I’m not training, I am a remote worker.  I love the 3 hours per day that I save by not going into the office.  My quality of life is definitely improved. I am a very effective Remote Worker as well. 

Having said that, I also realize the benefits of working face-to-face when we do have a chance to get the team together and I see what we could produce if we were all together more of the time.

What do I recommend for you folks out there trying to save your Remote Worker benefits and also see benefits from agile practices?  Here goes.

Do visioning, and release planning, TW calls it Inception, face-to-face.

Planning for a new product or largish feature set is best done as a group in person.  TW uses many workshops and interactive sessions, producing models that help represent the direction, scope, process and success criteria, etc. of the Release.  These activities are almost impossible to do distributedly.

Get to a ‘norming’ state as a team before folks start working remotely

Taken from the stages of group development first proposed by Bruce Tuckman in 1965 - Forming, Storming, Norming, Performing.  The team needs to be in a good place regarding core processes, including iteration planning, design sessions, testing, signoff and reflection.  This takes time.  Make sure your team functions well together before you begin Remote Worker benefits.

Agree on face-to-face team days

If your organization allows folks to work at home 2 – 3 days / week, then determine what days those will be as a group and define the days you will all be face-to-face. 

Adjust velocity

If you are a ‘norming’ team and you are just starting the Remote Worker approach, then your team velocity will go down.  You don’t know how much, but set expectations and watch this closely until you get a good idea.

Invest in good communication tools

Invest in good corporate communication tools like conference phones, video conferencing, document sharing, headsets.  This goes for the home office of the Remote Workers too.  There is nothing more frustrating than dropped calls or bad audio.

Be smart about the work folks are doing remotely

There are tools out there for pair programming, but every developer that I talk to at TW agrees that pairing is best done face-to-face.  Do tasks like complex programming, onboarding and design face-to-face, and save simpler tasks for individual work.

Card signoff, Showcases, Iteration Planning, Retrospectives can be done remotely with good tools.

Bottom line is that face-to-face communication is best.  When you can’t have face-to-face communication, then make sure everyone understands the process, tools and impact on the team.