Thursday, December 15, 2011

Is agile suitable for all projects?

At some point in your agile journey you begin to ask and/or hear this question: "Is agile suitable for all projects?"

Here are some of the responses I've heard from both those who are still learning about agile and those who have a lot of agile experience:
  • Agile isn't necessary when you have a known problem and a known solution.
  • Agile doesn't work in regulated environments.
  • Agile doesn't work in government.
  • Agile can't work in a large enterprise.
  • etc.

In my opinion and experience all of these answers are borne out of legitimate concerns but none of these responses are valid. Let me explain why.

One of the significant differences between traditional projects and agile projects are the short feedback loops. These short feedback loops allow teams to validate assumptions sooner, identify and deal with risks and issues sooner, find and correct defects sooner, and deliver a solution sooner. Agile will be implemented differently based on the project types identified in the responses above, but I believe that all projects will benefit from agile's short feedback loops. To say otherwise assumes that we always get it right the first time - even in the uncommon situation where the solution is 100% known, we get everything right the first time about 0% of the time. Agile helps us discover that sooner so that we can correct our mistakes.

Additionally, any project can benefit from increased trust amongst team members, increased trust between teams and customers, increased trust between teams and management, and increased trust of project status.

In my opinion and experience, the only question you need to ask has nothing to do with the type of project, the type of problem, or the type of solution. Instead, here is the key question:
Does the team want to use agile and have the support to do it?
If the answer is yes, then it can work. If the answer is no, it is not likely to work.

P.S. Here are some examples of agile being used in projects and organizations where "agile won't work":

Agile in a regulated environment.
Abbot Labs experience report - Development of a nucleic acid purification platform and companion real-time analyzer
Agile in a Regulated Environment - Linkedin Group

Agile in government.
Public sector case study - Social Security domain, software to support change in legislation.
Manitoba Parks Reservation Service - Agile case study as told by Terry Bunio.

Agile in a large enterprise
The agile experience at John Deere's Intelligent Solutions Group.- presentation by Chad Holdorf at Much Ado About Agile VI - Vancouver 2011.
Plus an article talking about the John Deere agile experience. "I figure if John Deere can test working software every two weeks on a tractor in a field, then Agile will work anywhere."

Agile with a known solution and a known problem
I recently completed a project with a known solution and a known problem - converting a VB6 application to dotnet "as is". We used agile and the project was very successful.

Agile outside of software
Wikispeed - Joe Justice and his volunteer team designed a 100+ MPG car using agile techniques."We can swap out an engine in the time it takes to change tires".

Want to receive future blog posts in your inbox? Enter your email address here.


  1. "Agile with a known solution and a known problem

    Would you reckon that using agile (I'm really curious how you filled the PBI!) is better than a waterfall approach?

  2. Yes - because in the case of the known solution w/ known problem we developed and delivered one piece of the application at a time. This enabled us to find a few errors early that were not repeated in later parts of the system. With waterfall's 'test at the end' this would have caused us more re-work. Also, agile gave us real information regarding the project progress.

    Does PBI stand for Product Backlog Items?.

  3. Hi Steve,

    This topis is probably has been discussed a hundred times already.

    Bottom line is, Agile still hasn't proven itself outside the software development realm.

  4. Hi PM Hut, thanks for the comment.

    I hear your frustration, but I don't agree with your bottom line statement. I regularly meet people who resonate with the agile concepts and say "hey we do something similar in our industry."

    This week I had a short conversation with someone who is applying the same principles at a hospital. I met with another person who said their manufacturing process was agile even if their software development group was not. I attended a lean office forum and the language we use in agile was very similar to the language they used for making their order entry process better. Whenever I teach agile workshops inevitably someone in the audience has a manufacturing background and 'gets' the agile mindset right away. The company I work for ( helps organizations apply these concepts to immigration, manufacturing, etc without focusing on software changes.

    It is true to say that a lot of people don't understand agile or lean. It is also true that our systems of management and schools tend to promote other ways that are archaic and troubling. It is also true many projects that have been executed under the banner of agile have broken the trust of those we are trying to help. These realities don't help us, but that isn't the same as saying that agile/lean still hasn't proven itself outside the software development realm is it?

    Finally, yes it probably has been discussed a hundred times. And I'm sure most of the readers here are agile advocates and don't need to be convinced. But hopefully they received some additional ammo. Also, I hope some of the agilists out their who have had frustrating experiences will stop saying "agile doesn't work for project types of [X]".