Andrew Stopford's Weblog

There is no impact.

There is an impact on the agile approach to the remote worker. Remote work just does not work.

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

Andrew raises the question: What is the impact of the remote worker on Agile approaches?A couple of months

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.

I really think it depends on the size of the dev team, and the level of communication with the remoters. I have had a lot of experience with this and it has seemed that it is all too esy to forget the remote folks. In agile, change is a constant as we all know.

I think the remoter takes the brunt of work fallout when communication is "sub par", yet the team feels it in the end. What I mean by this is that without solid communication a certain amount of retooling could occur on the dev side for the remoters if the had missed something through the products evolution. This is all to easy to do. In the long run, the entire team could take a hit due to this incurred cost of retooling in lost time.

It really depends on how good of a project manager, if there is one, is at the reins. They typiclly are the one that needs to be flying at full bore to assure that everyone is on the same page.

I have witnessed it work in many cases, but have seen and felt a lot of frustration with virtual teams as well. It definitely requires a lot more of a team than if you are sitting right next to everyone else. It is all to easy for something to get "lost in translation" when you are not face to face.

I regards to the impact of time, you really can't gauge it without project scope clearly identified. In a perfect scenario, it has no impact, but more likely than not, the timeline will be longer without a doubt due to the additional energy that needs to go into communicating.

Some rules of thumb that I have found that helps:

1) don't forget the remoters (obviously)

2) for agressive projects, daily status meetings are critical.

3) Instant Messanger... nuff said...

4) GoToMeeting, or the like (they are money well spent). Far more people are visual not conceptual.

5) To address Thomas Tomiczek comment, implement a Time Tracking application. I like using one purely for a CYA purpose.

Here is a good read,

<a href='http://72.14.203.104/search?q=cache:6kO0qt50-wYJ:www.agiledevelopmentconference.com/2003/files/R12Paper.pdf+development+agile+virtual+teams+remote&hl=en&gl=us&ct=clnk&cd=1'>Agile Development and Remote Teams: Learning to Love the Phone</a>

If you do a search for 'development agile virtual teams remote' you will find that many have pondered this subject before. I think all it comes down to is streamlined and constant communication (which is a requirement of agile anyway but remote scenarios IMO require more).

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.

Awesome, man

( 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

Hello.

I would like to comment here about the fact that Agile development has so far steered away from the inevitable extension of a good idea - remote work. I don't believe that remote work in itself is incompatible with the central mission of a development initiative. Remote work, and remote team members, often seem to be scapegoated in projects where the real causes might be the quality of the tools used, or even the preconceptions of other team members and their reluctance to cooperate with their remote counterparts, thereby sabotaging the potential that remote members offer.

I have seen no study that objectively asks the question: Are remote team members more or less effective than collocated ones?

It frustrates me that so many people want to hold an opinion that is based on nothing but their opinion, so this is my opinion: Remote team members are equally as effective as their collocated counterparts.

My opinion isn't going to change untill I find some objective evidence showing me otherwise.

 Owen.

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.