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…
- You could adopt and tailor one of the agile methodologies like Scrum, XP, TDD etc. or
- 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
- Is Offshoring A Special Case Of Agile Scaling?
- Manifesto for Agile Offshore Software Development
- The Myth of No Upfront Design in Agile