If you find this site useful, you should try my 55-page eBook here

Agile Colocation

by Kelly Waters

Email This Post Print This Post Save As PDF
Agile ColocationI was very interested to read this post about agile colocation on Artem Marchenko's Agile Software Development blog. The comments are also very interesting.

As always, I don't think the colocation debate is black and white...

I've read plenty of articles and blog posts about the merits of colocation. I've also read lots about how colocation is an essential ingredient of agile development. And I've read some very good counter-arguments explaining how agile can work - and is working - with teams that are not located together and even working across borders.

I think the debate, as with most things depends on your circumstances.

In our case we have business teams in multiple locations. So is it best to locate the associated development teams in the same building as the business units, or in a central development group colocated with their technical peers and other people of a like mind?

There is certainly a case for colocation with either group, but they can't be in two places at once so we have to choose!

In situations like this, I think it comes down to which group of people is most valuable to collaborate with most frequently.

If you have an established product or business in a BAU (Business-As-Usual) situation, but a development team whose development practices are not well established, I would suggest that ongoing product development is best placed near other, more established development teams, where good development practices and experience can be shared amongst peers.

If, on the other hand, you have an established development team with good development practices, performing well and delivering what's expected, but a product or business unit that is not in a stable situation (e.g. new product development, competitive threat, major problems, etc), I would suggest that colocation with the Product Owners is much more important. In this case, active user involvement is imperative, in order to provide extra visibility, get very regular feedback and customer insight, and be able to respond in Sprints accordingly.

In any event, I do think distance adds to the compromise, wherever you are permanently located. I've made comments before about this in relation to Agile India. If the opportunity for face-to-face communication is virtually nil, then I think the compromise is a really big one.

Kelly.

P.S. Click one of the icons below to join the growing community of people reading this blog by RSS or by email...
subscribe by rss feedsubscribe by email

  • Digg
  • del.icio.us
  • StumbleUpon
  • Yahoo! Buzz
  • Technorati
  • Facebook
  • TwitThis
  • MySpace
  • LinkedIn
  • Live
  • Google
  • Reddit
  • Sphinn
  • Propeller
  • Slashdot
  • Netvibes

1 comments:

  1. Artem Marchenko said...

    IMHO, most of the time the most efficient way to develop software is to colocate a small cross-functional team together with the customer. The problems start arising when you have to compromise. E.g. if you just have to work with the offshore team or if the project is clearly too big for 5-10 people. And if you have to compromise, well.. then you have to compromise :)

10 Key Principles of Agile Development

How To Implement Scrum in 10 Easy Steps

User Stories - Agile Requirements

Agile Project Management

10 Key Principles of Agile

How To Implement Scrum

Most Read

Agile Leadership

Agile Requirements - User Stories

Agile Estimating

Agile Testing

Agile Project Management

Lean Software Development

Agile Teams