What types of projects can Agile be applied to?

Types of projects that may suit Agile?

Many people are understandably asking this question – “what kinds of projects can Agile be applied to”?  The single biggest difference between being able to use Agile or a more Waterfall approach is the ability to be able to define, develop and formally release end product incrementally.  Another consideration is if late changes to design (where design is a critical activity) would have major impacts on the project, this may make elements of Agile unsuitable or not even possible.  Should this be the case, it may be that incremental development may not be feasible.

Agile Project Management Method
Incremental development can be suitable (and even be more successful) on some projects, not just software development.  It is also a major way to manage the risk that can be present in a more ‘big-bang’ type of development process.  For example, if a New Product Development project would benefit from this and it is entirely feasible from a commercial and technical perspective, then Agile could work very well.  Clearly though, if we have a project such as building a new bridge for example, there are real reasons why Agile won’t work.

In addition, there are other aspects that need to be considered:

  1. Agile requires constant day-to-day communication between development teams and business owners and users – if this is not possible Agile approaches may well struggle.
  2. Where there are key interfaces (e.g. Supplier/ partners etc) ways of working must be compatible and development teams must respect the needs of all stakeholders.  We are witnessing many project teams ignoring this, with very significant consequences on their project.

Examples of projects where Agile is suitable or may be possible:

  1. Small to medium-sized software developments.
  2. Product development where multiple variants are required or desirable.
  3. Where the main deliverable can be broken down and produced (and even potentially released or at least accepted by the end customer) in incremental discrete increments. There is one major consideration here though; the requirements and functions developed during each iteration must be stand-alone and not have major dependencies with other requirements and functions outside of the current iteration. At the end of the iteration, we should have elements of product that are ready to release and deploy.  If we cannot achieve that, we may not be using Agile at all.
  4. Where changes to business processes that the product is used for can also be deployed in parallel in this way.

Also, anywhere you find very dynamic requirements, which are able or likely to evolve per iteration, could take advantage of a more Agile approach.

Agile can result in a more fit-for-purpose end product faster than may be possible using traditional approaches. This is because of the heavy emphasis on collaboration and communication, early release, review and feedback on products may result in far less re-work than might otherwise be the case.  It can also produce a far more controlled process. However, Agile is easy to understand in principle but much harder to do in practice.  These benefits do not come easily.

Are there Agile Practices that all projects could benefit from?

For all projects though, there are certainly other practices that Agile (did not invent but) has adopted and widely promotes, that any project of any type and size could benefit from.  For example:

  1. Bringing developers and users closer together and interacting more frequently during the whole of the definition and development phases.
  2. Making reviews (of progress) shorter and more frequent.
  3. Communication – using two-way communication methods for all key communication on the project. This should always be face-to-face where possible, and where not, should involve two-way forms of communication at least.
  4. Developing a collaborative development environment, where all parties focus on the way-ahead when there are issues, as opposed to sinking back into their respective contractually bound corners.

Very few projects in the world would not benefit from such practices, if they do not already exist, in a manner that is both successful and productive.

Share this:


  1. HTSQ on November 29, 2020 at 12:36 am

    Dear Mr Kevin
    I would like to ask you if the agile can be used in an organization specialized in deign, develop and manafacture vehicles (Internal security vehicles -armired vehicles-)

    • Kevin Lonergan on December 1, 2020 at 8:18 pm

      Hi – and thanks for your comment / question. Some of Agile might be able to be used, but there are some projects where the full extent of Agile is simply not going to be possible. Your projects will always have to go through a design, development, and manufacturing process. Agile is designed to retain as much flexibility as you can (in the final solution) very late into the whole development process. When designing armoured vehicles this is simply not feasible and would be a major issue, if tried. Some Agile practices can be adopted on almost any project, but that alone does not mean you can or you are using the full principles of Agile. The following articles provides more explanation here: https://www.pmis-consulting.com/when-agile-cant-be-used-on-projects/

Leave a Comment

Contact Us Now

EMAIL us today.

Or call ++44 (0)1865 784040

Subscribe to Blog via Email

Enter your email to subscribe to our blog and get notifications of new posts by email. (We don't SPAM - ever.)