Where to start with Agile Programme Management?

Why move to Agile Programme Management?

Many organisations are adopting agile methods to deliver products and projects using frameworks such as Scrum and Kanban. However, it is often the case that these are only used in the software delivery parts of the programme with the rest of the programme following a traditional model.

The phases of a traditional programme are:

• Programme Identification.
• Programme Definition.
• Programme Execution.
• Benefits Realisation. [i]

In the traditional model the benefits realisation phase is the last phase, after all the work is done. But what happens if the benefits can’t be realised in the way that was originally envisaged? What happens if the business environment changes before the programme completes its execution?

While in traditional Programme Management there are some mechanisms in place for periodic review and course correction, this is more about making sure that the programme is still on track to (eventually) deliver benefits rather than delivering benefits as fast as possible.

So where to start if you want to take a more Agile approach?

1. Start with the Vision Statement

Most agile products or projects start with a vision statement to gain a simple, common understanding of the purpose of that product or project. If a programme only has a name and does not have a clear, documented vision it can become all things to all people and, once underway, becomes the vehicle that will supposedly solve all of the organisation’s problems. On the other hand, an extensive and detailed scoping document might take time to produce and may later limit the ability of the organisation to adapt to change.

A well thought out vision statement should provide enough information to set the context without excessive documentation. For example, many organisations are making updates to their systems ahead of the General Data Protection Regulation (GDPR) and a vision statement for a programme associated with this might read:

For customer relationship management and marketing teams the ‘GDPR Update Programme’ is a set of technical changes to our existing systems, and a set of communications with our existing customers so that:

• The company as a whole is compliant with GDPR ahead of GDPR coming into force.
• We obtain GDPR compliant marketing preferences from our existing customer base so that we can continue to provide them with information about our products and services.
• Our customers can more accurately describe to us the goods and services to which they are interested.
• Our marketing teams can better target communications to our existing customers.

Note that in this example of a vision statement, it specifically refers to existing systems and existing customers. It is written that way to prevent it from being used as a justification for a major systems replacement, or for a large customer acquisition campaign.

2. Then add clear, prioritised objectives

The next step is to document the objectives of the programme. These should be ‘SMART’ objectives (Specific, Measurable, Achievable, Relevant and Time-bound )[ii] so that we can recognise when the objectives have been met.

Just like stories on a Product Backlog in Scrum, the objectives should be prioritised. Traditionally, the Programme Director is responsible for achieving the objectives and realisation of the benefits. For agile programmes, it is also necessary for the person taking the Programme Director role to prioritise the objectives, taking into account both urgency and importance.

In the ‘GDPR Update Programme’ example above, the objectives could include:

1.    Implement changes to customer facing systems so that any customer can express a GDPR compliant marketing preference by 1st May.

2.    Implement changes to customer facing systems so that any customer who has not expressed a GDPR compliant marketing preference is asked to do so before they can log in. To be in place by 11th May 2018.

3.    Update all relevant current company systems that handle customer data so that they comply with GDPR before 25th May 2018. Compliance will be measured by listing all of the existing company systems, validating if they require changes and then, once the changes have been implemented, verifying compliance of each system with the legal department.

In this example, objective 3 may well be considered the top priority by the Programme Director as being in breach of the GDPR could result in significant fines as well as reputational damage.

3. Focus on the top priority objective

How quickly can you achieve your first objective? What products need to be developed or updated in order to achieve this? For existing products, how quickly can these get on to the backlog and into the roadmap? For new products, how quickly can we get a team in place and progressing towards this first objective?

Apply the lean principle ‘deliver as fast as possible’ to your top priority objective and aim to have working software in place for your top objective as soon as possible, even if that means that lower priority objectives are not fully planned in.

Once the stories for the top priority objective are underway or on the relevant backlog, move onto the next objective, ensuring that all teams understand that these are lower priority. Limiting the number of objectives that are being worked on concurrently will help focus efforts on these.

Attempting to come up with a complete set of stories that will achieve all objectives would involve a prolonged discovery period, delaying the commencement of the actual development.

What else?

Once the programme is underway it is essential that the Programme Director inspects and adapts to changes in the overall business environment as well as information relating to initial programme deliveries.

For teams working with continuous flow methods, such as Kanban, look at events such as monthly analytics reports or quarterly business reviews as the key triggers for reviewing the priority and continued validity of the programme objectives. This is in addition to reviewing feedback associate with parts of the programme that were delivered first.

If the products that are created or updated are done so using Scrum then, in theory, revised programme priorities could be fed into every Sprint Planning meeting. However, the reality is that reviewing programme objectives priorities every 2 to 3 sprint cycles may give the teams an opportunity to prepare and refine the stories before being included into a sprint.

The Programme Director must then decide when to begin work on each of the remaining objectives. This needs to be when there is capacity within the teams to pick up these objectives without jeopardising delivery of the higher priority objectives. This is a decision that should be taken at the last responsible moment, which is when there is still just enough time to do the necessary preparation work but without it becoming out-of-date before it can be used.

To summarise

• Create a programme vision and prioritised list of objectives.
• Commit to deliver the highest priority objective first and look to realise the associated benefits of that objective as quickly as possible.
• Accept that lower priority objectives may not have a committed schedule when work on the programme commences.
• Work to deliver each individual objective will then be added to the programme at the last responsible moment.

This article was first published at Agility in Mind.

[i] CCTA (1993a) An Introduction to Programme Management, HMSO, ISBN: 0 11 330611 3

[ii] The most commonly used variant of ‘SMART’ objectives are Specific, Measurable, Achievable, Relevant and Time-bound – see https://en.wikipedia.org/wiki/SMART_criteria