On Agile And Offshore

One of my posts yesterday drew a question and a response on the relationship between these two, so I thought I’d give the topic some airtime.

For anyone interested in the subject, a good place to start is Martin Fowler’s seminal article on the subject.

Read it for yourself, for sure it’s worth it. When I read it the first time around, I remember two things really stood out for me:

  • One, that the way to break teams up when seeking to do agile-with-offshore is “high cohesion and loose coupling”; you have to move entire cohesive units over, not what you would plan for in a waterfall or cascade approach. This is really important, since everything agile relies on good quality communication and team facetime.
  • Two, if you don’t do this, then you get a variation of Conway’s Law in operation. The system you build is a reflection of the team structure. So when you don’t have high cohesion loose coupling in the way you’ve structured the team, don’t expect to see it in your code.

There’s lots of good stuff in Martin’s article, and in the Thoughtworks Bangalore experiences he shares. Agile and Offshore can and do go together.

Incidentally, with all this talk about Agile. I thought it was worth linking to the Agile Manifesto, just in case one or two of you were interested in the subject and hadn’t actually seen it before. Rummaging around Martin’s articles, I came across it again, and felt it was worth sharing.

So here it is: The Manifesto for Agile Software Development.

I can’t resist copying it here, just for those who don’t bother to follow the link:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

[Signed everyone who is anyone in Agile]


6 thoughts on “On Agile And Offshore”

  1. You might want to check out my friend’s book, Agile Management for Software Engineering (http://www.agilemanagement.net/Articles/Weblog/blog.html) by David Anderson. It’s the first time Agile was put into a formal framework, using the ideas from lean manufacturing and throughput accounting (Goldratt). David’s ideas have moved on in parts since, and you’d now get the message over in half the pages (since much has become received wisdom since, or at least less heretical).

    You’d have a great conversation with David, who has just moved on from Microsoft to Corbis. Would be happy to make an intro. BT would learn a lot from his ideas.

  2. Agile and Offshore can and do go together.

    Maybe; maybe not. I don’t think you can make that statement based on Martin’s article though. To quote from his conclusion:

    As I write this, offshore development is very fashionable, but it’s still too early to really understand its true strengths and pitfalls.

    …

    We may never really understand the pros and cons offshore development. Software development is an activity who’s output is impossible to measure. As such we’ll never have hard numbers to prove one approach better than another. What we will see is growing qualitative feedback on the benefits of agility and offshore development – these qualitative assessments will determine if either, or both, will survive.

    I can only speak from my personal experience and gut feeling, and that tells me that genuine agility with an outsourced/offshore model appears to be very difficult to achieve – the best you can hope for is probably compromised agility. That said, it’s extremely difficult to be genuinely agile in a large enterprise too, and even compromised agility is far better than waterfall.

  3. This is something that has been occupying much of my time recently;

    http://jbrister.blogspot.com/2006/12/offshoring-agile-development.html

    I agree with the above observation that the purist definition may be difficult or impossible to realize with an off shore model. However, there are degrees of Agility and my experiences tell me that there are a number of off shore and near shore organizations that are much better at delivering Agile remotely than many on shore organizations are able to execute.

    It was interesting to note when I was involved with ThoughtWorks that they have a very rigid Agile process and my experiences lead me to believe that you can become so fixated on the ‘Agile Process’ that your delivery ends up losing the degree of flexibility implied by the term Agile.

  4. Martin, I’d love to meet David. We’ve conversed/sparred before, in the blogosphere. I read his stuff.

    Kerry, I wasn’t drawing the conclusion just from reading Martin Fowler’s article. In some form or shape, I’ve seen “offshore” models in use since 1981, when I was at Burroughs Corporation.

    Madras is not that different from Manchester, or for that matter the room next door; once you bring distance into the equation, you lose something until and unless you find better ways to solve the communications and coordination challenges.

    And Justin, I agree with you, the more rigid one makes an Agile process, the less Agile it is.
    more on all this later.

  5. JP,

    I was hoping to have had the chance to meet you last week at the Intellect Dinner in London.

    Oddly enough Thoughtworks are our development partners. One of the discussions we have been having with them is over the fact that whilst their methodology is agile their processes are not as agile as they could be in terms of the speed in which new programs could be compiled because there appear to be a number of meta tools that we have designs for that have not yet built. For instance, their process modelling which is conventional is 10 times slower that our design. I come from the process world and IT still has stuff to learn from the physical world as we learn more about behaviour and integrate this into the electronic society.

    Agile is first a state of process mind and good IT design and code comes from that. You ignore process at great cost and enormous inefficency because one good meta process tool can replace thousands of man hours; and the best of us do “agile process” and look for all the short cuts. Like all things there is a balance to be achieved between expediency and great design.

    One of the reasons, I wanted to catch up with you is to touch base on
    an interoperability collaboration business intelligence engine that Jeremy Griggs, Ruth Rowan and some other of your other colleagues in BT Global Services are considering from us. It has a fantastic value proposition and a great user experince, so if BT has not good you running from pillar to post it would be good to be able to connect and put you in the picture.

    Brian Leapman
    CEO Business Process Architect
    GBN1

Let me know what you think

This site uses Akismet to reduce spam. Learn how your comment data is processed.