Manifesto for Agile Offshore Software Development


Why a manifesto for Agile Offshore Software Development???

Is it necessary?

I think it is necessary – to highlight the special challenge faced resulting from geographic distribution, from large and heterogeneous teams, from involvement of multiple organizations and from complexity involved in enterprise scale software development project.

For enterprise scale software development you will need to have a large size team. The number of team members would be large enough to make it impossible to organize them as a single team where all members interact with each other. It would be necessary to have sub-teams and in all likelihood the sub-teams will be distributed across the globe.

During the life of the project the team size and composition would definitely change.

It is also likely the some of the teams will belong to a separate organization. When multiple organizations are involved then not only would there be contractual obligations but the teams would also have to adhere to the governance needs of each organization.

In other words (1) team spread and size, (2) team volatility, (3) multi-organization involvement and (4) problem complexity is inevitable consequence of agile offshoring.

The Manifesto for Agile Offshore Software Development – Reminder of the Challenges Involved

(1) Long distance ubiquitous interaction among individuals required proper infra, tools and processes.

Sure, individual and interaction is more important compared to processes and tools but you need to have proper infra in place in form of right tools and equipment to make that interaction happen seamlessly. You also need to setup necessary protocol of how and when that interaction can happen and there should be a common understanding of that protocol.

(2) Getting new team members up to speed requires documentation.

The fact of live is that no large team is stationary. Team members leave. New team members join. New teams get formed. Software transitions to maintenance mode. Depending only on well commented code may not be sufficient to get new members on board smoothly. You will need sufficient documentation.

(3) When more than one organization is involved both should benefit from the association.

There is no doubt that collaboration is preferable to contract negotiation but in real life for any large scale commercial dealing a contract needs to be in place. Since agile requires trust, a contract which is win-win for both parties involved is a must. The contract should not leave either party dissatisfied – such dissatisfaction is sure recipe to kill collaboration.

(4) Ensure that implication of change is clearly understood by everybody.

Responding quickly to changing need is a good thing but the implication of making the change can frequently be missed and may lead to unforeseen and undesirable consequence. Therefore it is imperative that clear plan and processes are in place to take care of such change and such processes are clearly understood by all involved.

Agile Process – Assemble it or Tailor it?

Even with the revised manifesto you will still need to come up with an agile process.

Agile manifesto does not have a prescribed process. Neither does it tell you how to run your project nor does it tell you to how to engineer it.

Scrum does – it mostly tells you how to manage the project not how to engineer it.

XP does – it is more about engineering practice but it also has recommendations about management practices.

Similarly both TDD and Kanban have specific recommendations. TDD is more about engineering practices and Kanban is more about management practices.

So to design your agile process, the process which suits your unique need…

  1. You could adopt and tailor one of the agile methodologies like Scrum, XP, TDD etc. or
  2. You could assemble a unique process for your need by picking the right practices from different agile methodologies.

When you assemble your process you get more flexibility and you can adapt and evolve as you gain better understanding of your needs and your organization dynamics. However, it is more work.

On the other hand when you tailor a specific methodology it would be easier because when in doubt you can fall back on what theory say. However, you may not have hit upon the most optimum process.

I think it is more rewarding to assemble your own process because every organization is unique – and off course it is more fun.

Also, adapting your process as you go along is the agile way of doing thing.

Not all Offshoring are made equal

What process is right for you will also depend not only on the type of software development project, your organizational dynamics but also on how you are approaching the offshoring issue.

Suppose you are already into outsourcing using traditional development methodologies. The process that you would come up with when you want to adopt agile will be quite different from what you might adopt when you are outsourcing for the first time as you may be able to start from clean slate.

Similarly, you process would be different if are planning to build your own offshoring team vis-à-vis engaging a vendor.

Again, there will be a difference of process depending on the location. If the offshore team is at the other side of the globe you will need a process different from what you would need for a near-shore location. Language proficiency and cultural differences with the offshore team will also play a role.

The other side of the coin

Most people look at the offshoring challenge from the perspective of the customer. They forget that there is another angle to looking at the problem.

The vendor who is undertaking the work will have a different set of challenges to handle.

Normally, most vendors would be working with multiple customers. Each customer would be using an agile process unique to its needs. Therefore the vendor would have to simultaneously work with different variants of agile process and they would have no way of standardizing it. This will also be true for toolsets preferred by the customer.

For a vendor not all customers would have adopted agile. Hence, some projects would be using traditional waterfall development model where other would be using agile methodologies. Managing such diversity within the same environment cannot be wished away.

There is the additional complexity of adapting the agile methodologies to adhere to the compliance requirement dictated by the need to maintain the certifications like CMMi Level 5 and ISO.

In short this can be summed up as the need to manage diversity.

Agile and Offshoring Handbook

  1. Is Offshoring A Special Case Of Agile Scaling?
  2. Manifesto for Agile Offshore Software Development
  3. The Myth of No Upfront Design in Agile
Comments
16 Responses to “Manifesto for Agile Offshore Software Development”
  1. Hello.

    Here is my view on the problem of outsourcing: http://www.scrumshoring.com/

    So instead of
    (1) Long distance ubiquitous interaction among individuals required proper infra, tools and processes.
    => avoid long distance issues at all by staying nearshore

    (2) Getting new team members up to speed requires documentation.
    => We all know that face-to-face communication is much more efficient than any means of documentation. So start onshore, allocate travel budget and invest continuously invest in exchange programs

    The other values (3) and (4) – I totally agree with.

    Thanks!
    Alexey Krivitsky
    SCRUMSHORING.COM

  2. Yes, for enterprise range software development you will need to have a huge size team. Having a small team will make it difficult to manage whereas a large team can handle well by having well interaction with each other.

  3. Ryan Norton says:

    If the offshore team is at the other side of the globe you will need a process different from what you would need for a near-shore location.

  4. Agile software development methodologies increase business uptime. That’s why, offshore clients prefer this development framework. They pay less money and get quality work delivered.

  5. For enterprise scale software development you will need to have a large size team. The number of team members would be large enough to make it impossible to organize them as a single team where all members interact with each other.

  6. Well written blog. Agile software development methodologies are indeed instrumental in enterprise scale software development projects.

  7. Hi Aditya,

    It’s not because you don’t know any instances that it’s not true.
    I know a few companies that do offshore without contracts. And yes some of them are rather big.
    (Long: depends on your defintion of long: what about 7 years?)

    It’s all about trust:
    Without trust, no contract will help you.
    With trust, no contract is needed.

    You might think it’s foolish (like most people think) but it works for them.

    Yves

    • Udayan Banerjee says:

      I agree that trust is required. But when two parties are involved there has to be a mechanism by which the customer monetarily compensates the supplier. In case of software projects it can be one of the following:
      – based on time and effort spend
      – based of quantum of work delivered
      – based on outcome
      For all of them you need an understanding between the two parties. It has to be clear and unambiguous. That is nothing but a contract.

      • I agree with that too. It’s true I was talking about a paper contract.
        (which is what people usually call a contract.)

        There is always a non-paper contract between two people (companies)
        even if you meet someone on the street and you talk, you have a contract to talk to eachother… (But you might not have an idea what the other person expects from this contract)

        I don’t agree with:
        > the customer monetarily compensates the supplier
        I do agree with
        > the customer compensates the supplier

        As compensation can happen in many ways (although typically done with money)

        yves

  8. Aditya Srivastava says:

    Yves, Don’t understand what you mean when you say some are not even true for offshore? If you mean having a contract in place is not necessary, for example, such examples are not true for large scale projects anyway. Even if they are large projects, such an arrangement cannot last for long.

  9. I disagree with the need for a seperate manifesto for distributed. All the remarks you make, are very similar for non offshore teams. The remarks might be bigger for offshore, but not always. And sometimes not even true for offshore. (Most extreme case: I know companies that do offshore without a contract )

Trackbacks
Check out what others are saying...
  1. […] His post goes into these points a little more deeply, so it’s worth the 3 minute read. Link: https://setandbma.wordpress.com/2012/07/09/agile-offshoring-2/ […]

  2. […] His post goes into these points a little more deeply, so it’s worth the 3 minute read. Link: https://setandbma.wordpress.com/2012/07/09/agile-offshoring-2/ […]

  3. […] Filed under Agile · Tagged with Agile Offshoring, Agile Outsourcing, Agile software development, Offshoring ← Why was everybody sooooo off the mark about iPad success? Manifesto for Agile Offshore Software Development → […]

  4. […] Manifesto for Agile Offshore Software Development […]



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: