The impact of the remote worker on Agile approaches

What I am after here is folks thoughts on the impact of remote workers on Agile approaches such as Scrum, XP etc. Do you think all the team need be in the same place or can some be remote and some be with the client in the war-room?

22 Comments

  • Thomas can you expand on what you mean, what impact and why does remote work not work?

  • One point you have with people in one room is the informal information exchange. Overhearing conversations, meeting for a coffee. That simply gets eliminated. Tools like VNC do not work properly on a multi monitor setup - you can share basically one. Plus chat is a lot slower than audio, and struggling for keyboard control for virtual pair programming is a pain - you miss all the feedback of the otherguy just taking the keyboard.

    In my experience is just does not work. We are eliminating remote work for most positions as a result. Agile methods work best if you have - well - a TEAM that has all these informal communication channels open.

  • Let me add that for the last 3 years I have been running projects that involved people on up to 4 locations, distributed over multipel countries (in the same timezone)

    We are now consolidating teams two locations and eliminate the majority of remote work.

  • Thomas, you stated that in your opinion, "it just doesn't work"

    In your opinion, what do you believe to be the source of the failures. Your statements point toward technology and its shortcomings are resposible for the failure, but in all honesty, I don't believe that technology could be held accountable here. It sounds like in the experience you have had is a simple communication breakdown. I couldn't agree with you more on the "coffe talk" that is missed, but if a team has solid communication, those things don't slip through the cracks.

    I have been working in agile virtual teams for almost six years now in one capacity or another (on both sides as well), it works IMO, but must admitt it can be painful if communication is not held on a pedistal and aggressively pursued.

    Remoters are to easily held as scapegoats for failures, which is one of my biggest peeves in virtual teams and see it in almost every project. It is a TEAM. If I have the choice, when building out a team, I steer clear of virtual teams at almost all costs. But, the fact of the matter is, sometimes they are unavoidable.

  • ::I couldn't agree with you more on the "coffe talk"
    ::that is missed, but if a team has solid
    ::communication, those things don't slip through the
    ::cracks.

    The problem, though, is that this COSTS MONEY again. It costs lots of time, lots of effort. And eliminates most of the gains you had in the first place.

    It works very well on the non-programmer level (i.e. separating project management from the team), and it works if you can cut down tasks. It may also work for stuff like graphics, web design. In fact ,we do use it here (note: web DESIGN, not programming).

    But when you ask about real programming, the loss is just not worth it, imho.

  • hey andrew,

    Ben Hogan of ThoughtWorks recently did a talk at Agile 2006 on running a distrubuted Agile project.

    The project was a success although not without its difficulties according to Ben.

    The question that needs answering is why would one opt for a distributed project?

    He offers some great tips for easing the troubles associated wth the approach.

  • You have to make sure you think of yourself as one team, not as two teams. If you think of yourself as two teams, you will blame the other for any problems.

    It helps if you make sure you always think of the "other team" as a group of people with similar strengths and weaknesses and competing priorities to yourself and have regular communications with them to reinforce this.

  • Thanks for the comments guys, interesting debate opening up here and it's good to see two sides of an arguement developing.

    I really should add that one of the reasons I ponder this is because OSS projects tend to spawn large development teams that spawn mutiple locations across the globe. Now if Agile does not work for remotely then will it ever see adoption in OSS projects or should a more micro-team per feature approach be taken to make a remote appoach work better.

    My take on the costs of remote working is such that sometimes you cannot always ship the talent your need to the places you need and the cheaper option is to work remotely with this folks. Relocation costs are far more than some decent hardware/software for remote working. While coffee talk is missing here, I disagree that during daily meeting and pre-start informal IM chats that you cannot have this. Nor does the phone have to be ignored ;-)

    Your thoughts as ever are very welcome.

  • I think distributed agile can work, but would guess-timate it at 2x to 5x less effective than a co-located (warroom) team. I lead a colocated team that occassionally have team members work from home. We compensate those days by doing more structured work planning in our morning stand-up and by using a Skype room (easy to chat and hop in out of voice) that the whole team, including ScrumMaster, is in all day.

    It's not ideal but, if there's a good reason to take the effectiveness hit, you can still be successful (by which I mean build working software in a predictable way). If you have a growing product line, however, I would look at the possiblity of creating multiple co-located teams instead having a strategy of distributed teams.

    I also agree that "coffee talk" can very much happen in a team chat room over the course of the day.

  • Distributed agile does work. I have been the project manager for agile projects for the past two years. Yes, the communication with the remote team is a challenge, but not a show stopper.

    Remember the original question of this post, "Do you think all the team need be in the same place or can some be remote and some be with the client in the war-room?" Well, what do you want the role of the remote team to be? That will drive the answer to the original question.

  • Remote workers do have an impact on any team and management structure. Some of this impact is positive while other is not. Just like having active and passive personalities, rigth-brain and left-brain types, boys and girls, different backgrounds, et cetera.

    In general it's harder to communicate with remote workers. If the remote people have strong "remote" communication skills this is probably a non non-issue. Not everybody is suited to work remote which I guess goes both ways: not everybody knows how to work with remote co-workers (this second part might be easier to address, though.)

    It's also a matter of the percentage of people that will be remote and the reason for it.

    On the upside you can hire the best of the best when you don't have a geographical location restriction. Even if your office it's in the middle of nowhere you can hire the best C# developer for high performant systems that lives near the beach and won't move to the middle of nowhere (again, certain conditions need to be met first but it's an option that you might not have otherwise.)

    In SCRUM, and agile in general, the need for frequent communication is a key ingredient. If you can get the level of communication that you need from the remote workers and/or the rest of the team that will work with the remote coworkers then go for it.








  • We've done agile in a variety of remote locations for a variety of projects. It works but it isnt without its difficulties. We use the phone for daily scrum with remote team members. Each team member has one remote day each week. We have one full time remote team member. To date we havent had issues with being less agile but rather issues with things like reception on the phone being poor, people not being a assigned phone numbers, or online for chats, etc.

    We've also done agile with a hearing impaired staff member via IM for daily meetings. Again, with proper, aggressive moderation this is completely viable.

    Its not without its challenges but its completely do-able. Personally, I look for growth in the collaboration space with things like Skype, Groove, etc being more heavily used in the future.

  • ( gluks in here....(

  • ( gluks in here....(

  • It is possible to delete all this slip?

  • Thanks man, i agree

  • Not bad, it really can occur

  • You have so much gluks in here....in here.. (

  • So much gluks in here....(

  • gluks in here....really sucks( delete it

  • I'm a freelance software engineer. I do most of my work remote. I work both solo and in virtual teams.

    I know what I personally get out of working virtual. I have the best, quietest, best equipped office of my career. I've got all the tools and reference resources in one place. I control the environment. I have flexibility to work when I'm most productive - and do things that improve my quality of life. I feel this helps me deliver higher quality to my clients than if I were in a cube farm. They are happy with my work - and keep paying me to do more for them.

    However, I'm not as clear how being a virtual team benefits the client or the team. My question to the group is - what are the benefits to team and customer for being virtual and do these benefits outweigh the costs?

    Jim

  • I have run scrum for distributed teams and it is harder but works if everyone has enough hours of overlap. The project that was the most difficult was where the team was in San Francisco and Kuala Lumpur and neither wanted to shift work hours to get good overlap.

Comments have been disabled for this content.