Chat with us, powered by LiveChat
';

Marrying Agile with programme management

How can organisations and their programme managers ensure Agile-based approaches and programme management work well together?

The rapidly evolving technology landscape lends itself to Agile techniques, and the pressure is on organizations to change more quickly. If you could use Agile effectively for some projects within a programme, the prize is tempting.

Programmes are Agile-adapted in some ways. The concept of tranches, which lies at the heart of programme structuring has much in common with Agile’s sprints. They are both ways of disaggregating blocks of activity. They are both ways of forcing attention on the delivery of value rather than on outputs. And they both use time as a way of constraining the effort expended, triggering in some cases innovative solution.

But there are dissimilarities too. Perhaps the most apparent is in the governance approaches taken. Agile is well known for its ‘light touch’ in this area, with conversation and close interaction between stakeholders and developers trumping the more heavyweight approach taken by programmes, especially those managed under MSP guidance.

Fusing the technical structures of the two would be straightforward. Fusing the different governance imperatives is more of a challenge, but by no means insurmountable. Companies are disappointed when they can’t get Agile to work, and often abandon the experiment before they realize that it might be that their legacy practices are unwittingly blocking them from success.

Indeed, many Agile practitioners are dissatisfied with the way the approach is implemented currently. They are also often to blame with their intemperate demands for a scorched earth / cleared decks approach, as the only way to get Agile to work.

Let’s look at the circumstances where it works.

How can Agile and programme management techniques co-exist?

Condition 1: Governance in the environment

Create acceptance of Agile, even within highly structured hierarchical environments, by resetting the RACI (responsibility, accountability, consulted and informed) allocated to sponsor, stakeholder and product owner roles. Not all decisions need to be made by the accountable individual; many can be cascaded down the seniority change, provided the RACIs are definitive.

Condition 2: The speed of agile within a programme

The fast-paced nature of Agile involves short, iterative delivery ‘sprints’. These are structured to sit within programme ‘tranches’. Projects in tranches are identified as either ‘research’, ‘enablers’, or ‘delivery’ depending on the type of outputs produced, and this fits easily with the different output from sprints. The focus of a tranche as an ‘island of benefit’ is a natural home for the value focus of Agile.

Condition 3: Attitude to Agile in the organisation – asking key questions

Executives and senior management should recognize that Agile only solves some types of problem well. The value of containing projects in a programme envelope is that allows for varied local governance approaches without exposing the organization to unnecessary risk. The risk is a common consequence of applying one type of governance irrespective of the project entity, or, indeed, of running several competing governance structures at the same level in a company.

Condition 4: Winning over project and programme minds with agile

Conversely, Agile is not a disease. Professional project and programme managers may be offended by the overselling of Agile’s virtues. The need, however, to recognize that there are circumstances where the strengths of Agile are of considerable value, and these may occur more often in programmes than in free-standing software developments. One undoubted impact of the Agile approach is that it brings business and developers into a close-knit relationship. This can only be a bonus to a programme, which is, par excellence, a stakeholder-led enterprise.