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 products (i.e. project deliverables) sequentially and incrementally.  If this is not possible, it may be that incremental development (and hence the core of Agile) might not be feasible.

A common aspect of Agile is that scope is often considered flexible. If the scope is not realistically flexible on your project, one of the main benefits of Agile will be lost.

Another major consideration is that if late changes to product design would have major impacts on the project, this may make elements of Agile unsuitable or not even possible.

Incremental development can bring real advantages (and be very successful) to some types of projects, not just software development.  It is also a great way to manage the risk that can be present in a more ‘big-bang’ development process.

For example, if a New Product Development project would benefit from this and it is 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, there are real reasons why much of Agile won’t work as we have to follow the type of development cycle that is common in the built world. Agile tries to embrace a flexible incremental development process; we cannot develop a bridge in a flexible way. There are obvious logical constraints and relationships that we cannot ignore.

In addition, other aspects must be considered:

1. As planning happens throughout the development process (as opposed to at the start of the project), Agile requires high levels of 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 across the wider team (e.g. Suppliers/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 that includes multiple variants of the core product.
3. If 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 the product that are ready to release and deploy.  If we cannot achieve that, we may not be using Agile at all.
4. When changes to business processes (related to the product) can also be deployed in parallel with the incremental product release plan.
5. 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 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.  The benefits and success of using the approach do not come easily.

Are there Agile Practices that all projects could benefit from?

There are certainly other practices that Agile (did not invent but) has adopted, that any project could benefit from.  For example:

1. Bringing developers and users closer together and interacting more frequently during the whole 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. One where all parties focus on the way ahead when there are issues, as opposed to sinking back into their respective contractual 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.