What do we mean when we say a project is “Agile”?

Does Agile have a place in a project where the end result is largely “known” from the start, and so stakeholders expect rigidity in terms of cost, timeline, and scope?

Is it possible, let alone desirable, to apply Agile-based practices in a purposefully non-Agile context?

The Agile Ideal

Of the Agile workshops, trainings, books, tweets, presentations, podcasts, etc. I have consumed, most take their basis in a specific type of software project: one in which the starting point is known ¹, and the next steps (not to mention the end point!) are up for negotiation, guided by a stated vision, set of OKRs, or simply chasing value. Projects like this make clear the benefit of Agile values and practices, of continuously delivering real value while holding onto the ability to respond constructively when new opportunities and risks present themselves.

This is the Agile idea, and to me it makes intuitive sense in the context of many software project types.

The White Whale: Enterprise Systems Integrations Projects

For professional reasons, I’m interested an entirely different sort of beast, so-called “Enterprise Systems Integration Projects”. A standard example of this is adding a SaaS or Customisable Off the Shelf (COTS) platform to another, usually legacy ² system, often built up of one or more enterprise COTS platforms. The effort involved in integrating the systems - the delta - is of course largely unknown, but this uncertainty is overridden by the certainty in the end goal, and the painful fact that the project gives little to no value until it is fully delivered. On a systems integration project, the question is rarely about discovering what to build, but rather how to build it. Scrum, the Agile framework of choice on these projects, is tuned towards answering the “what” case, and not the “how”.

In such a project one might encounter “Agile” practices in the project planning and delivery, but these projects are non-Agile by their very nature. The fixed, predictable nature of a project where the end result is known is in fact a primary selling point of enterprise integration projects.

Non-Agile by Design

Stakeholders will expect a rigid budget and timeline in a project where the scope is fixed. Any change will be equated with failure in planning or execution.

Whether you are working in sales, consulting, management, or development, enterprise integrations customers & stakeholders will force you to deliver on set terms - fixed costs, a rigid timeline, an expected set of features. Finger-wagging and lecturing about sky-high risk, a lack of “Agile” awareness, and organizational unpreparedness will quickly find you on the project off-ramp, replaced by someone more willing to instill the false confidence stakeholders demand.

These projects, and to a large extent the organizations that run them, resist Agility by design. So it must be asked, with so many obstacles and so much at stake, is there a set of practices that can dependably guide a standard enterprise integration project to its intended destination? What about partial application of some Agile values? Can an organization, having already embarked down this treacherous path, learn, grow, even derive real and immediate value from Agile practice?

I can hear an answer in my head (in the voice of Alistair Cockburn) → you can’t, don’t try, do something else instead. I have asked the wrong question on previous occasions, and I’m aware that could be the case now. Yet I am still drawn to the question, like Ahab vengefully chasing the white whale.

Industry Practice & Sources

I struggle to find trustworthy sources that discuss enterprise integration projects in depth, despite there being no shortage of “scaled” frameworks/strategies. Industry practice appears to be haphazard application of well-known Agile frameworks, from adoption of standard Scrum practices (“Scrum inside waterfall”) to full-on SAFe. What real benefit is actually derived by applying these practices in such a hostile context, aside from the (arguably misleading) confidence of practicing within a known framework?

In the following posts on this topic, I will piece through the sources that I have been able to find, and use them to attempt to tease out answers to these questions.