Agile is an iterative, communication-intensive development process which traditionally is built around small, centrally-located teams.Conversely, the Global Delivery Model (GDM, a model for delivering software from offsite / offshore locations) is built on the premise that software be developed using a 24-hour workday, utilizing multiple time-zones.You can start to see where obvious issues might start to arise.

Though globally sourcing an Agile Development project may seem like a clash of ideologies, the strategy has proven to be very successful if properly conceived and executed.By properly utilizing the inherent advantages of each strategy, significant time and money can be saved.

Profile of an Agile Project

 

A little over a year ago, we had a chance to work on the prototypical Agile project.Our task was to build a website incorporating innovative new features and technologies for a large financial institution.A developer's dream!There was a catch however; we had six months to design, build and release-an incredibly short timetable.

Agile is built for situations like this, and there were a number of factors which lent to the project's eventual success.The first factor was culture.Our development team was composed of creative, flexible individuals.We were accustomed to working under stressful conditions, and each programmer had the ability to think on his or her feet.The client was very open (excited even) to using Agile, and was very accommodating.

Culture is crucial to the success of an Agile project.The lack of a waterfall-like structure can be very stressful to some development teams and clients.Though we met the six-month deadline, the project was filled with ups, downs and uncertainties.Comfort is key, and before any Agile project is undertaken both the project manager and the client should be 100% certain they are ready for the sometimes uncomfortable undulations that Agile inevitably presents.

The second factor in our favor was talent.We had what we termed the "silver bullet", a do-anything programmer who has unlimited design capabilities.Obviously not every team is lucky enough to have a star programmer, but there are ways to make sure your talent matches the requirements of the project.

As a general rule-of-thumb, the more engineering content a project presents the more challenging it will be to use Agile Development.Why?More engineering content means more complexity.Take our project, for example.A number of features we planned on incorporating in the website required the use of cutting-edge technologies which, for the most part, our team had little experience working with.Luckily for us, our "silver bullet" was able to quickly develop an understanding of the new technology, experiment with code, and develop an ideal process which the rest of the team could emulate.Sans his abilities our team would have been over its head, unable to make the quick decisions that Agile Development encourages.We have witnessed the death of many projects because of an overabundance of engineering content.In these situations, if you don't have experienced architects, then don't use Agile!

An Agile-conducive culture and a talented team are two tell-tale signs of a successful Agile Development project.Our project, saddled with a six month deadline, needed speed.The extended workday provided by the Global Delivery Model gave our team the extra "oomph" needed to beat the deadline.Mixing the GDM with Agile is always a challenge, but the results are usually impressive.

 

 

Global Delivery Model and Agile

 

Though there is no getting around the 9000-odd miles that separate the typical onsite-offshore locations, the right mix of modern technology and strategy can help an Agile team work around these geographical challenges.

It all starts with personnel.One powerful advantage the Global Delivery Model provides is the access to necessary talent at onsite and offshore.Large vendors employ thousands of programmers, and it is very likely that you will be able to staff an Agile project with experienced people.Most successful Agile GDM projects have a strong mix of architects, client representatives and programmers both onsite and offshore.Offshore client representation is crucial to ensuring that any requirements uncertainties are cleared up on the fly. Resources who have worked on the client's onsite locations for a considerable time and have a good understanding of the client's environment can relocate and act as client proxies at the offshore locations.

By developing onsite and offshore, an Agile team is able to realize incredible productivity.The onsite team codes all day, updates the offshore team and then goes home.While the onsite team is asleep, the offshore team is programming.You can start to see how the GDM provides a little extra horsepower to a project.Though productive, this simultaneous coding demands a heavily automated development environment for configuration management, code merge, automated unit testing, builds and delivery. Automation eases and speeds up the development, and is a critical component of a GDM Agile project. In one large project, there was code released into production every 2 weeks. Once coding was complete, automated scripts built code, deployed code, and ran regression tests in order to have minimum human intervention before releasing the code into production. This process was repeated every fortnight without issues. In one of the other projects with lesser automation, code was manually checked into configuration management, manually checked, deployed and tested. Out of the 2 week sprints, these manual tasks took considerably more time-reducing the throughput of the functionality delivered in a sprint.

Creativity in communication is another defining feature of well-run GDM Agile projects.Traditional Agile development is built around an "Agile" room-a central programming location where all developers, client representatives, architects and testers reside.A GDM project will have two Agile rooms, one offshore and one onsite.To ensure that both Agile teams are on the same page, constant and painless communication becomes imperative.We often used instant messaging as a means of inter and intra-scrum communication; IM is easy, free, and quick.Wikis are another great tool, as are web conferencing and videoconferencing.These remote tools help ensure the diffusion of information between team members separated by multiple time zones.

A more traditional tool, teleconferencing, came in handy on a number of occasions.In our effort to beat the 6-month deadline, we decided to speed up the development process.Eschewing the normal two-week release cycle, we elected to release a new piece of code every week, utilizing the onshore and offshore teams to the full advantage. With both teams working, coding progressed nearly 24X7 pushing the envelope for the number of functions delivered in a week. As one can imagine, a number of quality defects found their way into the code. We combated these defects by conducting teleconferenced team-testing, an effective though exhausting technique.In teleconferenced team testing, team members dial into a tele bridge with live meeting and test the software during the session, each member focuses on a particular function and shares results as the project progresses. In one of the projects where we used this technique, higher defect detection rate was achieved with many defects found in only an hour of conferencing.

"So...I've got a project..."

 

Software development is a constantly evolving and self-improving process.New processes and approaches to development can prove to work exceptionally well in certain circumstances.That is important to understand-one size does not fit all.Every project is unique, and in order to be successful every project needs the right mix of intelligent developers, dedicated clients, and proper planning.

Agile is no exception, and when properly utilized it can reap terrific rewards.Coupled with the Global Development Model, Agile can be an incredibly efficient, quick and powerful tool.It may not be the perfect fit for every project, but for those who find themselves with a time constraint, a flexible client, and a team of architects and developers who can handle the programming it is almost unmatched in its performance.

---

About the Authors

Kumarasivan Veeramuthumoni is a Principal Architect with the Banking amp; Capital Markets Practice at Infosys Technologies Ltd. He has over 18 years of IT experience. He is a practitioner of various flavors of Agile methodologies with GDM for many years. He consults for leading companies on how to create the right recipe for success using Agile.

Ajay Bhandari is a Group Engagement Manager with the Banking amp; Capital Markets Practice at Infosys Technologies Ltd. He has played a variety of roles in a client facing capacity -Engagement Management, Consulting, Program Management. He has spent 14 years in the professional services industry and currently manages a portfolio of clients in North America.