When Agile can’t be used on projects

Purpose of this Post

Some people say that Agile could be used on any kind of project.  Agile contains some great ideas and some of the practices of Agile can be used on almost any project.  However, the heart of Agile, being incremental product development and deployment are always going to be limited to certain projects and circumstances. Let me use the following example project to share why.

State of the art Hospital Project

A contractor has a design and build contract for a major new hospital using a brand-new design.  Like any major physical project (such as construction), there is an inherent logical sequence that the project must follow and respect, as shown (at the summary level) in the diagram below. There are also physical constraints and factors that have major influences on the construction sequence and build strategy.

In any large-scale physical project, there are always major dependencies, long lead-time items and multiple points of commitment within the above life cycle.  If you follow the principles of Agile you will often leave many things later than would otherwise be the case.  Also, Agile seeks to retain as much flexibility as possible in the final solution well into the project cycle. On software projects, this might be fine.  On major physical projects, this would cause chaos.

The next major point relates to Requirements:

In the above diagram, Requirements are the key input to everything.  Changing requirements downstream will have major implications for this type of project.  In simple terms, if requirements change the design will likely need to change and maybe procurement.  While this can happen, it is very undesirable in construction projects due to the scale of impact it can have.  In Agile, requirements emerge in parallel with the actual product development effort.  This is simply not possible in construction projects.

Specifically in relation to this project:

1. Agile is fundamentally about flexibility stating: “Welcome changing requirements, even late in development”. On the hospital project, late changes to requirements or Design can have major impacts on the project schedule and cost.  The goal of this type of project must be to manage the project well to minimise the incidence of change, especially later in the life cycle. That is fundamentally different from being able to use Agile.
2. There are major logical dependencies between Design, Procurement and then Build.  This dictates a logical flow of effort and activity for the whole project based totally on this logic – not a flow of activities based on a manufacturing “push/pull” type process (e.g. Kanban).
3. The design must also mature and evolve in a structured and disciplined manner driven by aspects like interfaces between structural design, process and systems (i.e. heat/light/power/water etc.) and functionality (i.e. user operations and needs). Lack of recognising these interfaces and dealing with them together (not sequentially, as in iterations) would be a major source of issues.
4. Design is a major and discrete phase of the project – you cannot use emergent design as you might be able to do on some Agile projects.
5. There will be long lead times for some of the larger specialist and often very expensive equipment.  This places further emphasis on the logic between Design and Procurement and the need to do some activity early, not late. Lead times for some equipment could easily be 12 months following placement of the order (or even longer in some industries).
6. For the build phase, there is a construction sequence that is driven by the most basic laws of physics. At its most simple for example, you have to have a structure in place before you can install the roof. There will be a build strategy and plan – which have to observe the laws of physics and just because floor 23 is built after you have floor 22 to physically support it, it does not mean you are using Agile. Neither does it mean you are using Agile if you are delivering 25 units, one at a time.
7. On many Agile projects, the whole development team work exclusively on the current iteration until it is complete.  You could not (and would never want to) do this on the Hospital project.
8. Agile encourages scope to be the biggest variable in the project via constant prioritisation.  A hospital without surgery units or a reception area would be of little use. On some projects, you have to baseline the scope of work and deliverables, at the earliest feasible time.
9. Acceptance: the client should be actively involved in all phases but would be very unlikely to accept the project formally until the end.  For those who might propose an incremental acceptance consider this.  Would you formally accept something that may easily then get damaged or even destroyed by the fact that construction activities are still ongoing? Probably not.

Exceptions to this statement:

There are exceptions to this statement.  Agile promotes things like developers and end-users working more closely together (collaboration and transparency).  It promotes face-to-face communication wherever possible and always on important matters.  These are excellent practices that should be used on any project when we can. You may be able to cherry-pick some of these things from Agile and use them in your project.  Does that mean we can then claim we are using Agile (e.g. “we welcome change, even late in the project”)?  Absolutely not -in the case of the Hospital project and any other similar project.

Why is this discussion even important?

Many people are saying either they should be or in fact are using Agile in Construction and other physical projects. This is either misleading or even worse very misguided or driven by a limited understanding of Agile. Within PM communities, understanding where Agile can be applied, and why other approaches are used on other projects for good reason, is an important debate and distinction and must not be driven by selling/gaining certifications of any kind.

Even more important, stating you are using Agile, on this type of project will cause confusion and disagreement. That will always lead to issues. Quite possibly, issues that are not recoverable.

Can you use a hybrid of  Waterfall and Agile?

Both have pros and cons.  There are times when one or the other is better suited and some very experienced people have real reservations against mixing the two: “you can’t be half Agile“. We also believe that if you have a genuine opportunity to use Agile, there can be serious considerations or drawbacks to mixing Agile with certain other PM methods.

Summary and Conclusion:

Agile is not as simple as many people state but contains many good ideas and practices. Aspects like Lean and Kanban are ‘tools’ that are often used in Agile environments and different concepts are used on Construction projects. However, the physical relationship shown in the above diagram dictates that in our example Hospital project, incremental development or doing things like deferring decisions, especially around requirements is not just undesirable, it is totally impractical and will lead to major issues.