When to Avoid Agile Project Management

July 15, 2009 | Author: PM Hut | Filed under: Agile Project Management

When to Avoid Agile Project Management
By Kelly Waters

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 project management 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.

Kelly Waters is Head of Web Solutions for Reed Business Information (UK), the world’s largest business-to-business publisher. By implementing agile development, he has transformed his department of more than 90 people. Prior to joining Reed Business, Kelly was CTO for Glass’s Information Services, Europe’s leading provider of information to the automotive industry, most famous for Glass’s Guide, the UK’s bible for used car prices. Kelly has been in software development for more than 20 years. He is well known as a narrator of agile development principles and practices, as a result of his popular blog ‘All About Agile’ (www.allaboutagile.com). He is also a voluntary business advisor for Young Enterprise, an organisation that helps young people gain valuable business experience through practical projects.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

2 people have left comments

I work in Corporatocracy of several Fortune 500 Agile will always turn into Waterfall because of Politics and Organization.

By the way, people are just rediscovering only partially the spirit of Deming (not SixSigma which is like Waterfall)
http://statistical-process-control.org/dr-demings-revolution/

reboltutorial wrote on July 19, 2009 - 7:07 am | Visit Link

Kelly:

Interesting post. What you say about agile being useful in all circumstances may be true for the host PC or web development world. But for the Embedded software/firmware development world, I think you have to pick and choose which agile best practices translate well to an embedded context.

I think the following article by Doug Dahlby is useful in this regard.
http://embuild.org/dahlby/agileEm/agileEm.htm
I particularly like the supporting argument on p. 10 for the point “Embedded systems frequently have monolithic functionality”.

That being said, I think the embedded world need to continue to listen to trends in Agile. For instance, I think there is great merit to at least considering the OpenUP lightweight methods and the Eclipse Process Framework for certain types of embedded projects.

Gord

Gord Finlay wrote on July 28, 2009 - 4:27 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories