Lots of people that we work with struggle with Objectives regardless of their preferred delivery methodology or Framework. In this uncertain world we need to focus on outcomes more than outputs more than ever. The confusion can come from anywhere: too much detail, not enough detail, too many objectives.
In this article I want to explore how we can use objectives to help keep us aligned, and have driven toward a common purpose.
Where do we use Objectives and Goals in SAFe?
There are three main places that we take advantage of Objectives and Goals in SAFe.
- OKRs (Objectives and Key Results) - to articulate Strategic Themes
- PI Objectives - to articulate what we plan to achieve in the Programme Increment (PI)
- Iteration Goals - to articulate what we’re going to build in an iteration
For the purposes of this article, we will focus on PI Objectives.
Objectives are critical as they are the mechanism that we can use to find the balance between planning and agility. Most organizations need to have an idea about where they are going, the stakes are too high not to plan. In the Agile Manifesto, we have the value ‘Responding to Change over following a plan’, that does not so say that we do not need to have a plan--we can’t respond to change if we don’t have a plan in the first place!
There are a few aspects of this that we need to understand. Firstly, we need to recognise that when we commit to something it becomes a queue, and we have to manage our queues to promote the flow of value. Secondly, we have to acknowledge the ‘Cone of Uncertainty’.
The Cone of Uncertainty suggests that the further we are away from something the less likely we are to be right. Essentially, we simply don’t know what is going to happen in the future, none of us have a crystal ball and we need to plan in a way that allows us to adapt quickly.
That is as true during the PI planning process as it is in a large waterfall process. Therefore, what we need to do is make the direction and the outcome as explicit as possible while maintaining flexibility for how we’re going to get there. Roll-on the wonder that is the objective. Objectives clearly state what we’re trying to achieve in Business Language. Most business owners--even in technical businesses--don’t speak in features. We need to explain what we’re trying to achieve in a language that can be understood by everyone so that we can drive alignment and transparency throughout the organization.
Many years ago I was travelling back from the British Virgin Islands. The plane was delayed, and the airport was small enough that you could in and out of security without a problem. After a delay of an hour or so, I decided to go back to the check-in desk and find out what was going on. I will never forget what the agent at the desk told me: “Sir, I did make an announcement, but the speaker is broken so nobody will have heard it”. The sheer craziness of the statement still provokes a mixture of feelings; bewilderment, anger, giddiness! However, it does make me think of a more serious point. How often do we try to communicate in a manner that we have no real confidence that it will be fully understood by the person that needs to hear it the most?
Another benefit of articulating work as objectives is that it allows us to reflect the requirements back to make sure that we fully understand what is required. Many Scrum Masters and coaches use a technique called Reflective Listening. Essentially, after listening to someone speak, you repeat back to them what you think you have just heard in your own words. This process allows you to understand categorically that you have heard them. I can’t tell you the number of times that I have used this technique and had to clarify a point or two--basically every time!
Simply, that is the value of the objective. As Einstein said, “If you can’t explain it simply, you probably don’t understand it well enough”. Therefore, phasing the work as objectives has a number of advantages:
- We take out technical jargon to state what we’re going to do in a way that everyone understands
- We have the opportunity to reflect back and make sure that we are all agreed on what we need to do achieve and that we’re all on the same page
- We focus on outcomes rather than outputs
How do we write good Objectives?
SAFe suggests that we use the SMART Method. Smart objectives are goals that are designed to be specific, measurable, achievable, relevant and time-bound. These typically include end-goals such as revenue or meaningful steps towards end-goals such as launching a new product.
I typically use this template to get me started:
To help/improve < problem / challenge / area>
increase/reduce < measure >
from < x > to < y >
by < date / iteration >
- To improve our customer experience, reduce our page load time from 2 seconds to 1 second by iteration 2.3.
- To improve our DevOps capability, increase our automated test coverage from 20% to 30% by the end of the PI.
You can play with the elements to make it work for your context. You don’t need all the elements all the time, and you may want to use different verbs to get your message across. I always reword objectives so that they are as compelling as possible, but this formula is a great starting point.
Putting it into practice with PI Objectives
The most visible time to write objectives is in PI Planning. Teams take the top features from Product Management, break them down into high-level stories, plan them into iterations (taking into account dependencies with other teams), and summarise what they’re going to as objectives.
PI Objectives and features are typically very closely linked. However, we cannot overlook the fact that in the same guidance SAFe recommends that we take the top ten features into PI Planning. Remember, features are going to take longer than an iteration to complete, but less than one Programme Increment.
The teams commit to the PI Objectives in PI Planning, not the features. The reason for this is simple when you think back to the Cone of Uncertainty that we discussed earlier. We know where we want to go, but how we’re going to get there may change over the course of the 10 weeks. Objectives, however, tend to be more resilient to change. We’re still essentially trying to accomplish the same outcome, but in a way that fits with the shifting landscape of Product Development.
So, when the features linked to an objective are complete the objective is complete, right? Well, not necessarily! This is where we need to go back to our roots and the Agile Manifesto.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Our focus should be on Individuals and Interactions rather than the processes and tools. We should focus on collaboration and our ability to respond to change. With that in mind, the relationships are the key to unlock agility within the business.
What we need is a conversation; relationships built on trust and transparency.
Remember, we also have Uncommitted Objectives in SAFe. We should use Uncommitted Objectives where we don’t have enough information or the outcome isn’t clear. We plan the work, but it doesn’t make up part of the team’s commitment.
In SAFe, we have the role of Business Owners; the people that have the ‘primary business and technical responsibility for the governance, compliance, and ROI for the solutions’. It is this group that assigns Business Value to the objectives--just out of ten. Therefore, if we’re going to make changes to the objectives during the PI, they absolutely need to be involved. The Product Management Team is going to work very closely with them to make sure that we continue to build the right solutions.
It is, of course, possible that you can meet the objective and the business value without developing all the features and stories. In fact, the manifesto suggests that we should strive for it: Simplicity--the art of maximizing the work not done--is essential. To play it through, it is also possible to complete all the features and stories and fail to meet the objective. It is for this reason that we need system demonstrations. Working software is the primary measure of progress. Period. Mic drop.
What if we need to change PI Objectives in the middle of the PI?
Well, there are two schools of thought on this one, and it warrants a deeper discussion. My take is that if continually re baseline plans then you don’t get an accurate picture of what is happening on the ground. PI Objectives and uncommitted objectives properly, tend to be more resilient to change as there is enough flex to deliver the outcome. Whatever you do, make sure that you are transparent, and that you show exactly what happened. Don’t try and cover it up, make it real #nofilter.
So, why do so many people fail?
In my experience, it is that we have too many objectives; we typically suggest 6-8 per team. We try to cram too much work into the system to the point where we lose track of what is really important. If you set objectives correctly, everyone should know what it is that we’re trying to accomplish, and how their little bit fits into the wider strategy. It helps to use iteration goals as a subset of the objectives and refer to them every day in our stand-ups.
We need to get into the habit of continuously referring back to outcomes and objectives, and if you can’t remember them all, you’ve got too many.