Agile project management: When it doesn't fit

We have all heard about the benefits of using agile project management: the reduced bureaucracy, faster delivery, higher productivity, increased control, improved customer satisfaction, and more. So, the obvious question seems to be: “Why am I not doing this?” 

Agile project management has seen a rapid rise in take-up across the IT industry, but can it truly be regarded as the way to approach IT project delivery in every situation?

The simple answer is no, but knowing when agile is or isn’t right is altogether more complex. There are many different factors that can influence our decisions on whether or not to adopt an agile methodology, and it is rarely clear cut.

[ Read also: Agile vs. DevOps: What’s the difference? ]

Here are some common examples where agile isn’t the obvious route to take.

Strict requirements? Agile may not be right

It is highly likely you will benefit from agile techniques if your primary business is developing commercial software products in close collaboration with your customers, or if you are undertaking a long-term digital transformation journey. However, if your business is delivering managed IT services with specific commercial deliverables and outcomes, then agile is less likely to be the most appropriate delivery methodology.

Projects with predetermined outcomes and timescales typically lend themselves more readily to traditional project methodologies.

Projects that need to deliver against very specific, often legal or regulatory, requirements aren’t agile-appropriate either. In these cases, the requirements and delivery timeframes are very explicit – typically with penalties associated for failing to meet them. A more traditional project approach would be more suitable here, though that does not mean that you shouldn’t consider taking an agile approach to other projects within your portfolio where the outcomes are less defined and require discovery and iteration over time.

Similarly, a data center migration project is less likely to be managed through an agile approach, due to the known requirements around networking, heating, ventilation, air-con, computing hardware and so on. Again, that doesn’t mean that you can’t run other parallel software development projects utilizing agile that you will ultimately serve from the data center.

[ What tools can help? Read also: Top 7 open source project management tools for agile teams. ]

Traditional mindset? Agile will be a challenge

Sometimes the project is ripe for agile but the organization simply isn’t ready to adopt the cultural shift required. A business that is attached to the traditional project mindsets of "when?" and "how much?" will struggle to make agile a success.

A big commitment and investment is needed to ensure that teams are equipped to work within an agile framework. It requires the right organizational set-up, clear roles and accountabilities, training and support, and the right environment where teams are given the empowerment and autonomy they need to be successful. If none of these things are in place, then agile isn’t the route to take.

Agile or not agile? You may not have to choose

While there are some scenarios where agile will, or won’t, appear to be the obvious choice, this won’t always be a binary decision. And it is wholly appropriate to consider running agile for some projects and traditional waterfall techniques for others in parallel.

More and more we are seeing cases where agile delivery needs to co-exist within a more traditional project management structure, where the two methodologies need to complement each other as part of an integrated (or end to end) project delivery. In such a situation, we may have less certainty around the specific function and features of the "product" or "application," while we may have more certainty around the scope and timeframes associated with the delivery of supporting requirements such as support models and tools, recruitment, marketing activity and training.

In cases such as these, an agile methodology and approach operate inside a more traditional project construct.

One size does not fit all

Based on my experience of delivery with clients, working out whether agile is or isn’t the right project management approach is not straightforward. It requires careful consideration of questions such as:

• What business do we operate in?
• What are the commercial arrangements around the project?
• Do we have high levels of customer support and engagement?
• What is our project mandate?
• What is the business objective that we are trying to support?
• What is our business, or customer expectation?
• What are our enterprise architectural principles in relation to software development? Are we "build" or are we "buy?"
• What is the level of maturity of our business operating model?

So, there’s no silver bullet, or a-one-size-fits-all approach. The first key step it to recognize where agile will help your organization achieve its objectives, if at all. After that, if you think agile can help, then ensure you are prepared to secure and drive the commitment needed across your business. But remember, you should always continue to ask yourself whether agile is the right approach as you initiate new projects or changes for you or your customers.

[ Culture change is the hardest part of transformation. Get the eBook: Teaching an elephant to dance. ]