Agile is the watch word on every technology programme to the extent that often other methods are seen as “out of touch”, legacy or only advocated by those not willing to accept Agile and/or change. This is a dangerous path to follow and it is ironic that an approach predicated on adaptation and change can be evangelised by those not willing or able to accept counter points of view. One size does not fit all…
In many organisations, the agile agenda is quite correctly promoted and championed by evangelists. The risk to success comes when the evangelist becomes a fundamentalist and Agile becomes an ideology rather than a methodology. Considering the destination of the transformation programme and journey you need to undertake enables the programme design to consider key elements or delivery and the appropriate methodology / approach to adopt for success.
Some technologies and delivery programmes are simply not suitable or able to support a working software demonstration every 2 to 3 weeks as an end of sprint activity for instance. In national payment and settlement transformation programmes there is a significant degree of focus and attention required that is outside of software delivery activities – for example the coordination and management of industry-wide testing phases which can often continue for several months. When you consider that the Agile manifesto, which is now almost 20 years old, was primarily designed with software development in mind it is likely to be problematic when applying that same manifesto to all aspects broader technology enabled business transformation programmes in the guise of Agile Project Management.
Combining the toxic mix of Agile evangelists becoming fundamentalists with “1 size fit all” programme approaches is a problem. It stalls good programme design, creates delivery risk where none should be (self-inflicted) and fails to adopt one of the core benefits of Agile in the form of adaptation. The proliferation of certifications and training courses in agile is adding to this noise as it seems to arm those without the deep experience of what works and what doesn’t with a confidence to call “luddite” to anyone who doesn’t appear to agree them. Counter to this, are those without the training and certifications who don’t wish to appear to be behind the curve and so blindly agree.
Alternatively, taking the holistic view of the programme at mobilisation stage and taking the elements of what works for the people who are going to work on the programme (competence), the working culture and ability of the organisations involved (capability) and the nature of the transformation delivery (strategic intent) is more likely to derive a delivery governance and enablement approach applicable to that specific programme and so reduce delivery risk. Clearly, most software delivery programmes involve some form of Agile, but the key to success comes from knowingly embedding the right approach into your programme and doing so alongside other aspects and methods which suit the nature of the change/transformation. Particularly, the non-software elements and parts of the organisation for whom the word agile may mean something else entirely
“Agile or nothing” is a nonsensical position and ironically misses the point of Agile as an adaptive framework.