Why isn't Agile working for my IT project?

I spend a lot of time discussing innovation, Agile, and new ways of working with CIOs, CDOs, and CTOs. Although each topic is significant on its own, my experience has shown that they are deeply interconnected. For IT executives and decision-makers, understanding this relationship is increasingly crucial.

Agile often comes up in my conversations. I hear concerns like, "We are doing Agile. But we’re not seeing any material changes in delivery outcomes, so what’s the point?" Let’s delve into where Agile originated and why.

Agile, as a formal methodology, is relatively young. It emerged in 2001 when seventeen software developers got together and drafted the Agile Manifesto, aiming to address inefficiencies in the prevailing software development lifecycle (SDLC). Influenced by design thinking and the rising popularity of commercial Software as a Service (SaaS) products at that time, they proposed a shift from traditional, linear development methods to more adaptive practices focused on user needs.

This sounds like the perfect adaptation to our dating methods. So then why isn’t Agile delivering expected results in traditional IT project settings? The answer lies in the differences between product organisations and IT departments. Product-focused companies have been honing their approach since as early as the 1930s, initially with physical goods and later with software products. Their structures support ongoing product design, development, and innovation, aligning strategic goals with product growth. Teams in these settings typically start with market needs, form hypotheses, and engage in research and rapid prototyping. The insights gained from these activities inform iterative product development or potential pivots.

Contrast this with IT departments tasked mainly with delivering software solutions to support business functions. Here, software is often procured off-the-shelf and integrated into existing business ecosystems. Such projects are rarely seen as experimental or adjustable post-implementation, especially once contracts are signed. This approach usually mandates that the business adapts to the software, often disregarding user feedback.

This misalignment is where disillusionment with Agile can arise within IT teams. Agile's promise is to create solutions that users love, adapting to change and delivering efficiently. However, the reality for many IT projects involves implementing a predetermined solution, leaving little room for flexibility or user-driven modifications.

Does this mean Agile has no value in IT project delivery? Absolutely not. But we must be realistic about where and how it can be applied, considering the organisation’s goals and the nature of the project—be it product development or product integration.

As someone who advocates strongly for Agile, I believe it can be successfully applied to IT projects, provided it is properly contextualised. This involves having a clear strategic objective for adopting Agile and understanding its applicability on a project-by-project basis.

Decisions on when to replace traditional methods with Agile should consider factors like delivery structures, funding models, and performance metrics. This is particularly relevant when integrating Agile with concepts like Value Streams or Product Thinking, which facilitate continuous discovery and improvement.

If you're questioning Agile’s value or how it fits into your organisation’s various projects and capabilities, get in touch. I’d love to discuss the nuances of Agile and explore paths for a successful transformation.