Agile objectives are best if they describe the intention of the functionality of the system rather than prescribing a specific technical approach. For example, rather than the objective describing the implementation of a new marketing feature, it could be to increase retention of premium users of a system or service. The approach to achieve that objective may well be to use a new marketing feature. If, when the work is underway, it becomes evident that the new feature does not work as expected, then it would be possible to look at alternative ways to achieve that objective.
So how do I write agile programme objectives?
1. Be specific about the outcome, not the method
All of the SMART aspects apply but it is really important to focus on outcomes rather than specific technical changes. For example, instead of
‘Update to the latest version of the content management system by September 2018 as it is more efficient and will save the company money.’
‘Reduce the operating cost of the content management system by reviewing the system and/or its associated processes ahead of the September 2018 budget round’.
In this example, there is no target cost reduction set as I’m expecting the team to look at all reasonable options and to work through them in value order. However, depending on the culture of your organisation, you may decide to include a target for the cost saving.
The key purpose is to reduce the costs associated with the content management system. Upgrading to the latest version may or may not be the best way to do this. Writing the objective in this way allows the team concerned to bring down associate cost by any reasonable method.
2. Start with a general statement and only add the detail necessary
Instead of starting in the detail and trying to get the objective wording right first time, start with something very general and then rewrite adding in slightly more detail. Keep iterating until you have just enough information in the objective.
For example, start with
‘Do something that makes things better.’
Flip it round so that outcome comes across as the most important
‘Make things better by doing something.’
What do we mean by better? Time to be specific in this case it is to reduce costs
‘Reduce costs by doing something.’
Still too general so add more detail
‘Reduce the operating cost of the content management system by doing something.’
We need to put a time limit on this
‘Reduce the operating cost of the content management system by doing something ahead of the September 2018 budget round.’
‘Doing something’ could involve creating something new, changing something we have or even removing / decommissioning a service. In our example we are setting some broad boundaries that make it clear that it is okay to look at processes as well as the system itself
‘Reduce the operating cost of the content management system by reviewing the system and/or its associated processes ahead of the 2018 budget round’.
3. Be prepared to reconsider
As any programme progresses the team or teams delivering it learn as they go. They could uncover hidden complexity, they could get plausible feedback that the expected benefits cannot be realised, or an external factor could have changed.
Sticking rigidly to the objectives that were set at the beginning of the programme regardless of this new information does not seem like the right thing to do. We must be prepared to reconsider the objectives and ensure that they are still relevant and achievable.
Take, for example the following objective for a global company’s app:
‘Make users of the app feel part of a community that has similar interests by delivering a project to allow editors to embed tweets or Facebook posts from the members of the public into articles.’
Let us suppose that after the programme is underway, the popularity of the company’s services significantly increases in China and other countries that have popular Social Media Platforms other than Facebook and Twitter. The interactions from those regions also increases significantly. The company announces to shareholders that this is priority market for the business.
The programme could, of course, carry on and deliver to the original objective but it should be willing to reconsider and decide if this represents the best value. Adding, for example, Sina Weibo, to this list of Social Media platforms may be more relevant to the overall goal of the programme.
By accepting that the objectives can be updated if things change dramatically does mean that that when they are originally written, ‘just enough’ detail can be added to make them useful without having to cater for endless possible permutations.
If an objective does become out dated, it is better to update it than leave it obviously irrelevant or unachievable. The example above could be updated to:
‘Make users of the app feel part of a community that has similar interests. Do this by delivering a project to allow editors to include in articles, social media items from members of the public. These should be relevant to the location of the visitors.’
For an objective to truly be agile it must be periodically inspected and adapted, just as we do with agile processes.
So here are my three tips for writing agile objectives for a programme:
- Still be SMART but be specific about the outcome that is desired, not the solution that is to be implemented.
- Consider starting with a very general statement and add just enough information to make it useful.
- Be prepared to consider changing the objective if the evidence shows limited value.
The most commonly used variant of ‘SMART’ objectives are Specific, Measurable, Achievable, Relevant and Time-bound – see https://en.wikipedia.org/wiki/SMART_criteria