Some people argue that if a project has a clear, fixed scope and solution then there’s no need to use Agile. I disagree. If the project scope and solution are fixed throughout the project then an agile project can substantially increase your return on investment by delivering incremental benefits early as shown in the diagram below.
But project scope and requirements are never fixed throughout a project no matter how hard you try. That’s because software development isn’t like making widgets in a factory as many people think; it’s like designing a new car and the factory you need to build it in. In every software project we learn what the real requirements and solution are as we go and it’s not until the end that we understand them fully. Agile understands the need to learn along the way and helps you implement what you learn quickly and effectively.
The only time you shouldn’t do Agile is when you don’t have the capability to do it or the will to resolve the organizational blockers that Agile reveals.
For example, if your software project needs a new environment and it usually takes your organization six to twelve months to get one then your Agile project will be blocked in a few weeks. If your senior management are unable or unwilling to provide an alternative environment straight away then the project will stop. As a result any project that depends on a new environment would not be a good candidate for Agile.
Or, let’s say that your organization has a strict waterfall methodology and little experience with Agile. If you start your Agile journey on a multi-billion dollar program of work then you will probably fail because your organization's structure, beliefs, processes and policies will block your Agile program at every point. Agile can be done successfully on large projects using the Scaled Agile Framework
or Disciplined Agile Delivery but this requires a high level of Agile capability that you won’t have to begin with. If you haven't done Agile before you need to start on small projects and remove organizational barriers to progress before you move onto big projects.
Some critics have claimed that Agile is an evangelical fad
that won’t work on large, complex, mission critical projects. These people claim that Agile is an open ended, time and materials approach with no clearly defined roles or requirements and no guarantee of a specified outcome for a specific price. The underlying assumption seems to be that Agile = Scrum = Adhoc.
These critics are wrong. The 2011 IT Project Success Survey
shows that Agile projects are much more likely than traditional projects to deliver a quality system, meet stakeholders real needs, provide a return on investment and deliver on time and schedule.
Rather than being adhoc, Agile is a highly disciplined approach with clearly defined roles and requirements that can be tailored to your needs as you can see at NetObjectives Lean-Agile Pocket Guide to Scrum teams.
And rather than being open ended, Agile projects can deliver a guaranteed outcome for a specific price if required. In fact Agile projects are better at doing this than fixed price projects because Agile is faster, higher quality and more efficient than Waterfall.
When we do fixed price Agile projects at Kiandra IT
we work closely with the client to understand the features (or epics) they want; we get the development team to size each feature (or epic) based on previous examples (with a contingency for risk); and then we work closely with the client to develop a roadmap to deliver the features in order of priority within the client’s time and budget. This roadmap includes a plan to release features every few weeks so that the client can get a return on their investment as soon as possible. If requirements change then we can substitute features of similar point value for the same cost.
In my experience, if you have the capability to do Agile and the will to solve the problems it reveals then you can benefit from using Agile on all your projects.