Do we know why?
Enterprise wide Business Agility is the latest hot topic in the Agile space, from conferences to meetups. The challenge is how Agile can impact business strategy in the boardroom, to enable the entire organisation to become more adaptive, rather than be constrained to process optimisation in software delivery teams. Terms like OKRs and Impact maps, Outcomes and Outputs, are now the focus of attention. This is a significant step in helping us to rightfully consider Agile more as something you are, the values held; and less in terms of what you do, the practices and tooling used. To many though, these are alien terms and appear as competing ideas, resulting in inertia and a continuity of the annual cycle of feature laden projects delivering to fictitious business cases.
To clarify; all of these topics are various approaches to address the same issue, they all exist to attempt to address the following critical question:
“What is our purpose, and how can we ensure that everything we are doing is aligned to it?”
Or as Simon Sinek puts it, “START WITH WHY”. Once you approach Agile in the context of WHY, then you can start to be Agile with your implementation of Agile, avoiding a swathe of common errors from dogmatic imposition of methodologies.
A problem with a lot of “Agile Delivery” is that while the approach taken in the teams is healthily supported by Scrum or similar, it is based on implicit assumptions that often do not hold true. Scrum assumes you are building the right thing in that it doesn’t really talk about how the backlog is created, only that it exists, but what if you’re not building the right thing, what if you are just building “Something”?
Enterprise delivery, or for those in large organisations with multiple teams, departments and managers, will know it: NORMAL delivery, suffers terribly from dependencies and conflicts. Millions are spent on delivering new capabilities or features and millions more managing the conflicts between them, without really ever being sure that their efforts are delivering the intended results that triggered them in the first place. Whole departments slowly slip into the “Build Trap” as Melissa Perri refers to it, becoming feature farms, secure in their high utilisation delivering a never-ending stream of potentially pointless changes to their products.
How should we operate?
At BCG I am privileged to work with people who are passionate about helping organisations and initiatives within them, understand WHY they exist, and from that ensuring that the efforts they put in are directly associated to that. VALUE DRIVEN DELIVERY we call it. Unless an organisation can express the PURPOSE it serves, it is near impossible for it to have strong value driven delivery underneath.
There is a cascading nature to the expression of purpose within an organisation and how that should connect to the activities and ways of working that affect the majority of a workforce on a daily basis.
- What is needed to be achieved is the PURPOSE
- How progress against the purpose is measured is its METRIC
- Combining PURPOSE and METRIC gives an OBJECTIVE
- Objectives need a PRIORITY
- Progress is made against the objective through achieving KEY RESULTS / OUTCOMES
- Employees focus on OUTCOMES through aligned MEASURES / REWARDS
- Those Results/ Outcomes are delivered through a series of OUTPUTS
- Outputs are connected to Outcomes on OUTCOME BASED ROADMAPS
- And finally this hierarchy evolves over time through a cycle of INSPECT AND ADAPT
While this feels logical, when we really unpack the ways of working in many organisations we find a very different situation. Often the purpose is known to senior leadership, but the activities within teams are often poorly connected to it. The metrics the teams are being governed by relate to the delivery of the outputs, rather than to the Objective and there is too little, if any, Inspection or Adaption. Lots of activity, not so much VALUE.
How to shift from Outputs to Purpose?
One route to this is through the adoption of OKRs, Objectives and Key Results, at an organisational level. Created in Intel and popularised by John Doerr as he transitioned them into Google, they are a simple way to express the concept to senior leaders that improvements come from focusing on the why, not the what. OKRs are Purpose driven to bridge the gap between strategy & delivery and are proactive, in that they drive decision making in feature capabilities capacity management.
Note these are not KPIs which are always grounded and achievable, OKRs are more ambitious. KPIs are lagging indicators that are helpful to measure progress and assess the effectiveness of existing operations, but they do not assure the reasons behind those activities or processes. OKRs and KPIs should work together, they serve different purposes.
An organisation should only have a few OKRs and have everyone use them to understand how their efforts contribute. There should not be a cascade of OKRs per level or department unless the organisation is extremely large. Cascading OKRs risks reintroducing the original issue of a disconnect between the activities of the teams and the higher level strategic purpose.
An example of an OKR:
An alternative is to employ IMPACT MAPS, as introduced by Gojko Adzic which have a strong correlation to OKRs. Impact Mapping is a little more structured and really helps an organisation to understand how their sense of purpose translates into what they need to do.
Once again Start with, WHY?
Impact Maps start with the Goal, which is broadly synonymous with the previously described Objective. Then there is a helpful division by Actor or “Who”. Who might contribute to the realisation of the Objective? This is useful in large organisations as it enables a division of efforts between those focusing on a goal targeting one group of users, while another division focuses on a different group. Then, for each Actor, Adzic breaks it down into tangible things we want to see happen which are similar to the Key Results, and lastly what Outputs will enable those Impacts to occur (important to note you rarely need to deliver all possible Outputs to achieve the Impact.
In Adzic’s own words, “My understanding of OKR is that the KR part would map nicely to impacts on the map”. OKRs and Impact Maps are similar expressions of the same concept.
Within an organisation there are typically multiple Outputs being worked on, associated to multiple Goals. As long as no individual in the organisation is asked to contribute to more than one of them, then everything should run smoothly, however that is rarely the case. The Objectives, and the desired Key Results underneath them, need to be expressed as a clear set of priorities which are communicated to all employees. This will ensure it is clear which should prevail when there is ever a conflict for a person’s time. Those priorities will need to be reevaluated and recommunicated on a regular cadence by the senior leaders. OKRs are succinct so the communication effort should be relatively low. Where this does not happen we find teams competing with each other or at worst working against each other in pursuit of different goals. Shared capabilities will become stretched and expectations not met as people attempt to please multiple masters at the same time.
How to manage work by purpose?
It is one thing to create OKRs but it is easy to have this as simply an academic exercise that is quickly forgotten. Turning this into something that actually changes the ways of working in the organisation is where the benefit lies. This is where OUTCOME BASED ROADMAPS come in (sometimes referred to as Goal based Roadmaps). Outcomes here are synonymous with Impacts on Impact Maps and Key Results within OKRs.
Traditional Roadmaps represent the planned delivery of a pipeline of features which leaves departments wide open to losing sight of the bigger picture and redefineing success to be software deployed or a process signed off. They also often assume a determinate system, where it is known from the outset what is to be done and how long it will take, which is highly unlikely.
Outcome Based Roadmaps are effective because they both accept the vagaries of delivering into complex adaptive systems and connect what is being worked (Outputs) to to a higher purpose that ultimately defines success or failure (outcome / Key Result). There is decreasing confidence of delivery in terms of scheduling of the outputs. The next Output is likely to have an agreed delivery date within a few weeks range, while the Outputs six months down the line have a much wider date range to reflect the high degree of uncertainty that comes from projecting far into the foggy future of highly complex organisations and markets. A big distinction to more traditional ways of operating is that although teams are still working to deliver an Output (or learning about subsequent Outputs), their measures of success and reward are now taken against the Outcome. This approach helps to maintain a focus on the “Big Picture”, the reason why all the work is being done.
This uses the analogy of Ice, Water, Steam. Things we are about to do are cold and solid, compared to things nine months from now that might cynically be described as “Hot air”. To keep the Roadmap relevant it needs to be refreshed on a regular basis, it cannot be done at the start of the year and left; we understand that the act of planning is more important than the plans it produces.
In Summary
Employees in many organisations are wasting huge amount of time, money and effort delivering changes to products and services without sufficient awareness of why they are doing what they are doing. To address this organisations need to have a comprehensive answer to the question, “What is our purpose, and how can we ensure that everything we are doing is aligned to it?” To answer this organisations will need to adopt Value Driven Delivery and ensure they understand and follow these nine steps:
- Agree on Purpose
- Define the Metrics progress will be measured by
- Express the purpose with its Metric as an Objective
- Share the Prioritised objectives
- Establish Key results / Outcomes that support the Purpose
- Measure and reward people on the Outcomes
- Outcomes are realised though the delivery of Outputs
- Create Roadmaps that map Outputs to the Outcomes
- Inspect and Adapt
Credit to Dragan Jojic and Glenn Bowering for their contributions and support.
Comments are welcomed – even criticism. It is only through feedback that we learn.
Follow me on twitter: @philagiledesign
or reach me on LinkedIn here
philagiledesign 