When Agile Development Methods May Not Work Well

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles Agile Outsourcing: Where Agile Methods and Outsourcing Intersect Agile Outsourcing: How Agile Methodologies Help Software Development Outsourcing Agile Outsourcing: Requirements Gathering and Agile Methodologies
	Discussion Forum "We're curious about whether Nari is painting too rosy of a picture regarding how outsourcing work actually gets done and whether the methods of agile development need to be better understood in client organizations before it can become a reality in other parts of an organization -- such as its sourcing office." Contribute to this Discussion

By Nipun Sehgal

There have been a multitude of articles on how and why agile programming methods can accelerate software development, and lead to better quality applications or products.

We have been using agile methods to develop our company's outsourcing governance solutions for the last few years -- and they have worked well (and over time we have adapted these to match our processes for multi-site development).

This article is really about some of the scenarios where agile methods are likely to not be well suited. This is not to say that agile methods will fail. It's just that they may not yield the benefits you'd typically expect.

Agile Methods: A Quick Recap

Let's do a quick recap of some of the key principles of agile software development:

• Develop iteratively, with incremental extensions.
• Don't over-engineer; keep it simple, with just in time functionality extensions.
• Have a "customer" always available to the development team.
• Make unit test development a key component of software development.
• Use frequent integration points.
• Test often, and where needed, improve existing tests.
• Run well-defined acceptance tests frequently.
• Maintain frequent communication, identification and resolution of problems.

Where Agile Methods Won't Work (As Well)

Here are some of the types of projects or scenarios that may not benefit as well from agile methods.

Fixed Price, Well-defined Scope, Well-defined Acceptance

If the scope is well defined, the use cases are well documented, and the project is fixed-price, the provider won't want to invest in a lot of unit test development, or "pair programming." It simply doesn't make economic sense, nor is it really needed by the client.

Also, the client may not want to make available a resource that represents "the customer," as the functionality is well defined, and the acceptance criteria is well understood.

In the above scenario, there may already be an acceptance test suite (automated or otherwise) that exists or is being developed in parallel by business analysts.

An example is the extension of a database-migration tool to support IBM DB2, when it already supports Oracle and MS SQL Server DBMSs.

Impedance Mismatch between Development and Testing or Maintenance Paradigms

It's possible (and often likely in an enterprise) that the service provider responsible for ongoing quality assurance, maintenance and support is different (and at times in a different location) than the service provider responsible for software development (such as the rollout of new modules of an ERP package).

Should the development be done using agile methods, a challenge would be communication of the functionality and changes to the quality assurance, support and maintenance teams. The agility is immediately affected if the thorough and detailed documentation is to be provided of the functionality, design, and software code, and changes to the same.

Large Scope and Significant Possibility for Change or Attrition

If the anticipated duration of development is large, and there's a high possibility of being hit by attrition in key personnel, agile methods may make it more difficult to change providers.

This happened to a CEO of a "startup" I met recently. The company had outsourced the development of its software, and he and his product-manager were the "customer" providing daily requirements/feedback as the product was developed. Mid-way through the development, as the senior engineers (in the offshore company) quit, the remaining engineers were simply not able to deliver or even provide realistic estimates for completion. Turning over the entire development to another company was also difficult as the current product wasn't documented well enough from a design and code structure standpoint. The use-cases were, however, and that is what they eventually leveraged to restart the effort with another provider.

Large Effort, Large Teams in Multiple Geographies

When dealing with large teams (50-plus people) and large scope, there's an inherent need to think top-down. How should the teams be structured? How can the project be split into phases or modules? What are the major integration points?

It's entirely plausible that certain modules of the overall project may need to use agile methods; this may be accomplished by smaller teams.

Given the scope and size of engagement, it's likely the client would have done a fair amount of requirements gathering and functional specification even prior to getting started with an external services provider. The need to allocate ballpark budgets upfront, to get business buy-in and to allocate resources for significant extent of time are all reasons that would make it more likely for the project to be handled in a more structured top-down way.

Also, it's very likely the provider may have done similar projects for other clients and would bring its experience in sizing, planning and delivery to bear, reducing the need to go "agile" to a large extent.

Useful Links

Enlighta
http://www.enlighta.com

For more on agile methods, refer to:
http://www.martinfowler.com/articles/newMethodology.html

About the Author: