Agile Zone is brought to you in partnership with:

Kelly Waters is Web Technology Director for IPC Media, one of the UK's largest publishers of consumer magazines and web sites. Kelly has been in software development for about 25 years and is a well-known narrator of agile development principles and practices, as a result of his popular blog 'Agile Software Development Made Easy!' (www.agile-software-development.com). Kelly is a DZone MVB and is not an employee of DZone and has posted 40 posts at DZone. You can read more from them at their website. View Full User Profile

3 Reasons Why I Wouldn't Do Agile Software Development

03.25.2009
| 1793 views |
  • submit to reddit
Agile software development has been a revelation for me. It has brought me and my teams much success, and a very rewarding working environment.

Sometimes I hear people say that agile development isn't appropriate in all circumstances.

In fact, I used to say that myself; however now I'm not so sure.

There are some circumstances where an organisation's culture is possibly too different to successfully adopt agile. At the moment I can think of only 3 reasons why I wouldn't do agile software development:

1. If I was working for an organisation that believed it needed complete clarity about a solution before it could start a project. I believe this is a false positive, and it would be very hard to adopt agile in an environment where key stakeholders insist on this.

2. If I was working for an organisation where the relevant product owners couldn't - or wouldn't - commit to being actively involved throughout the project. I really do believe that active user involvement is the first principle of agile, and imperative for a project to succeed.

3. If I was working with a team that I didn't believe could cope with ambiguity, or didn't have sufficient communication skills to collaborate effectively with business colleagues or customers.

In these circumstances (particularly if combined), adopting agile could be very difficult indeed, because in my experience these 3 agile principles are critical success factors!

When writing this list, I did also wonder whether to add fixed price projects to my list? Working from a feature list, having no more detail about the features up-front, and allowing change throughout the project, could potentially be a complete disaster with some clients on a fixed price contract.

I think I would do agile on a fixed price, but I would be very careful to:
  • Understand the client's attitude towards scope up-front, and be very clear about the fact it's fixed price, not fixed price and fixed scope. In other words, they can add or change features throughout development, giving them the benefits of flexibility, but will need to remove other features to do so.
  • Build in sufficient contingency and allow for a reasonable number of changes to happen without too much debate. You are taking the risk on a fixed price project. The client needs to pay a premium to offload that risk to you.
I would evaluate the above two issues - along with any other risks - very carefully before committing to a fixed price agile development project. Otherwise, whether accidentally or deliberately, you could quite easily get mugged :-(

On the other hand, I'd probably try to persuade the customer that T&M (Time & Materials) is not a problem with agile software development, because of the level of collaboration, visibility and transparency, and the frequent delivery of working software.

I'd love to know your thoughts on this: When wouldn't you do agile software development?
References
Published at DZone with permission of Kelly Waters, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)