When Agile can’t be used on projects
Purpose of this Post
There are some proposing that Agile could be used on virtually 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 flexibility are always going to be limited to certain projects and circumstances. Let me use a real example 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 summary level) in the diagram below. There are also physical constraints and factors that have major influences over the construction sequence and build strategy.
(click to enlarge)
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 normally be the case. 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 on 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 on construction projects due to the impact it will have.
Specifically in relation to this project:
- Agile is fundamentally about flexibility and states: “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.
- There are major logical dependencies between Design, Procurement and then Build. This dictates a logical flow of effort and activity for the whole project.
- 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.
- 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 order (or even longer in some industries).
- 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.
- On many Agile projects, the whole development team work exclusively on the iteration that is live at any time until it is complete. You could not do this on the Hospital project.
- 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 little use. On some projects, you have to baseline the scope of work and deliverable, at the earliest feasible time.
- 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”). I am a lot less sure of that.
Pros and Cons 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 there can be serious considerations or drawbacks to mixing Agile with certain other PM methods.
Summary and Conclusion:
Agile is not as simple as some state but contains many good ideas and practices. Aspects like Lean and Kanban are ‘tool’s that are often used in Agile environments and equivalent concepts are also used on some Construction projects. However, the physical relationship shown in the above diagram dictates that on our example Hospital project, incremental development or deferring of decisions, especially around requirements is not just undesirable, it is totally impractical.
Contact Us Now
Email us today to find out more on how we can help you.