Agile¹ has gone mainstream.

It is no longer the preserve of a self-selected group of devotees, but is now being discussed, and implemented, by CIOs and Change Directors in major organisations across a variety of industries where IT forms a major component of change programmes and projects.

There are copious sources of technical information about Agile available on the Internet, so we have little to add in terms of defining it – apart from issuing a health warning at the end of this article.
Agile is a sensible approach, mainly because it embodies some well-understood good practice.

There are several well-known endemic problems in the ‘traditional’ product development approach of developing solutions from a detailed set of requirements that have been defined and documented ‘up front’:

• Business priorities (and therefore requirements) change, and individuals change their minds as their understanding of the requirements evolves over time.
• Business representatives can’t easily visualise in detail what they need during abstract early discussions, so they tend to over-elaborate on requirements and ‘invent’ functionality – ‘just in case they might need it’. This leads to subsequent ‘bartering’ with the delivery team as the constraints of time, cost and quality bear down on the project.

At best, this approach results in some disappointment as the final product falls short of the initial (over-inflated) vision. At worst, the business has spent money on software that is neither relevant nor useful (see Figure 1).

In Agile approaches, the constant engagement of the business in shaping the requirements and the solution addresses these major problems head-on; however, this is not as radical an approach as some might argue. Back in 1983, Barry Boehm wrote a seminal report which offered sound advice for the conduct of IT projects, which foreshadows much of intent of the Agile Manifesto.

In other words, any approach that promotes engagement between the product developers and the business has got to be an improvement on the fossilised ‘separate tribes’ model that encourages bureaucracy, inefficient communication, delayed/poor decision-making and lack of ownership.

In short, Agile approaches have much to offer businesses trying to implement sustainable and beneficial changes. However, we conclude with a warning for those venturing into Agile…

Warning: Agile project management does not exist!

Agile is a philosophy and approach to the development of IT application systems, and this is not the same as the overall management of a project. To talk of ‘Agile project management’ is about as sensible as debating ‘hand-crafted strategy’.

This is not mere pedantry: it is critical to highlight that any IT application development approach needs to be embedded in a project management framework. Put simply: use of Agile does not remove the necessity to strategically manage and govern change.

This point is worth dwelling on for a moment because some more excessive ‘devotees’ of Agile argue that it radically changes the change management paradigm, and dispenses with the role of project manager along with much of the usual governance associated with ‘traditional’ projects.

This is a dangerous fallacy. Agile was never meant to ‘remove the shackles’ of governance, but simply to recognise that in modern business we cannot define all the requirements of change up front – in fact we usually start from a very vague understanding of what we really need – and therefore we should develop solutions in a way that gives us maximum flexibility to change our minds. We still need effective change governance to ensure that the impact of the change is understood, that it can be successfully integrated into business as usual, and that it will bring benefits.

In our next article we will discuss how we can identify where Agile can best benefit the business, and how to exert appropriate controls on projects employing Agile product development.

Subsequent article(s) will address the following questions:

• “Benefits: how can one gain best advantage from employing Agile methods in change projects?”
• “Governance: how do I ensure that the business maintains appropriate control over change in an Agile environment?”