Tag Archive for: strategy map

goal-setting and OKRs

Goal setting as a tool for organizational change: a case study

This article explores how Objectives and Key Results (OKRs) and goal setting can change the collaboration style within an organization, based on agile42’s experiences with a particular recent case study. In this instance, we introduced OKRs and noticed a number of changes emerging organically within the organization. The OKRs were intended to set strategic product goals, but we noticed new ways of collaborating, bringing about positive organizational change and empowering teams to self-organize. In this article we outline the challenges the company was dealing with initially, the positive side effects the OKRs supported, and some assumptions that contributed to these positive side effects.

The challenges the company faced

We were approached to work with a product department made up of 15 tech teams, all of which work on a single product. They had several challenges that both the teams and management were hoping to improve. 

Firstly, they had identified a strong lack of direction and priority on department level because there was no product strategy or roadmap. They were working from a long feature list from stakeholders, which had a number of contradictory requests and contained detailed descriptions with fixed scopes.

The teams were also noticing a lack of team autonomy. They weren’t able to make decisions related to product improvement. It was the kind of culture we refer to as a Feature Factory, where the team was building a large quantity of requested features rather than taking an iterative approach to build and improve the product. The result was a lack of focus on the value of the functionality. To make matters more difficult, the dev teams didn’t have access to the business problem, so they were not able to do any reasonable scoping.  

Additionally, there were strong dependencies between teams. Most of them were able to deliver smaller features independently within their area, but when it came to bigger releases, dependencies occurred all over the place and created bottlenecks.

Team feature list

OKRs as a tool for organizational change

The leadership team started to experiment with OKRs and set strategic product goals for the department. Over time it grew to a full goal-setting framework. They started with big and broad intentions that were valid for the year. The intentions for the year included the following examples: 

  • Build up a new revenue stream (including a new customer type)
  • Increase the product usability
  • Integrate partners via an SDK (Software Development Kit)
  • Migrate to new cloud provider

For every quarter the big intentions were broken down into Objectives and measurable Key Results, which were valid for the whole department. Some examples for the quarterly department Objectives and Key Results included the following:

  • Yearly Intention: Build up a new revenue stream
    • Objective: soft-launch our MVP
    • Key Result 1: Launch two cities
    • Key Result 2: Sign up 50,000 new users per city 
    • Key Result 3: Learn the top five feature wishes of our users
  • Yearly Intention: Increase the product usability
    • Objective: Decrease misleading items in sales funnel and checkout
    • Key Result 1: Increase conversion rate by 4%
    • Key Result 2: Reactivate 100,000 passive users
    • Key Result 3: Identify the top three usability flaws during checkout

With those given targets all teams were asked to set their own quarterly OKRs that contribute to the abovementioned department goals. All this was synchronized and made transparent in newly introduced events: every quarter there was a Review, Retrospective, and Planning event with all teams together. 

The positive effects of goal setting

Some time after introducing the new goal setting framework, there were three key positive organizational changes noticeable that had not been anticipated. 

Focus on outcome instead of output

There was a distinct shift in the mindset, from an output- to an outcome-oriented approach. In the beginning the strategic goals were used to get a feature list implemented (e.g. integrate voucher provider X). This gave little freedom to the product teams for problem-solving. 

By formulating the Key Result as a measurable business value (e.g. increase monthly active users by X%) the teams were asked to find solutions themselves. In this case a voucher provider could help to reach the Key Result, but it is only one possible way to do so among many others. The teams needed to ask themselves, “what can we do in order to increase monthly active users? And that's a totally different challenge than “I have to implement feature X”. It encouraged team members to consider the impact of their work and the features they built, rather than just checking them off a list. 

Product Discovery Streams

This positive side effect came along with another challenge and opportunity. While the teams were great at delivering a clearly described feature, most of them were not accustomed to being involved in solving a business problem. They simply didn’t have the skills required to dive into the business context, understand the customer, run interviews, evaluate possible ideas, and design and run experiments with a subset of users. 

The organization started to realize that there was huge scope for new skills to be learnt. So they began to experiment with product discovery streams that were using design thinking, user experience design, and other approaches depending on the situation. Within a stream, people from different departments started to work together that wouldn’t have been in contact before, e.g. business development, operations, UX, product teams, and developers. 

The organization increased its ability evaluate and test ideas before implementation, and reduced potential waste of unwanted features. Customer centricity also increased significantly as there was research made about their needs and wishes rather than untested assumptions.  

The emergence of temporary teams

Another unplanned positive effect was the building and dissolving of temporary teams around business problems. Depending on the nature of the topic, as well as its complexity and size, a group of people came together to solve the problem. Previously, backlog items would have been sent from one team to another, with bottlenecks forming in between. The new system meant that teams faced with time pressure, teams could simply come together for a short period of time, get the work done, and then move back to their original teams - with the added bonus of enhanced sharing of knowledge. 

Why did these positive changes occur?

There are a number of conditions that contributed positively to the above side effects of the goal setting. Although it is highly multifactorial, we want to highlight some factors that we believe have had a strong influence.

Connecting people rather than coordinating 

First of all we observed a strong focus on connecting people rather than coordinating them. The leadership team understood that if people know and trust one another, they will collaborate in a meaningful way when it is needed. So there were a lot of social events and team building activities that created bonds between people, especially during pandemic times. This made it easier to ask for help and to collaborate on a specific problem.

Leadership allowed freedom to self-organize

We observed that the leadership team gave the teams a lot of freedom and set high expectations for the teams to self-organize. This was to such a high degree that there were even complaints about missing structure to help teams coordinate themselves, and concerns that the leadership team was too uninvolved. Although we initiated rounds for coordination, the interference stayed low so that the relevant structures simply grew around specific work needs.

The UX department was strong, capable, and eager

Finally we saw that the UX department was strong, capable and eager to change the mindset within the department and company. They quickly took the initiative to drive a product-focused rather than a project-focused mindset, and to experiment with product discovery. It also was their first time doing so, but they did a great job by involving the right people, being willing to fail and to learn from that.

What can we learn from this case study?

In conclusion we observed these organizational and cultural changes happened due to the implementation of OKRs (or any strategic goal-setting framework). It guided the department towards a few common goals. This influenced how the organization collaborated, while new structures evolved and rituals grew organically around these structures. This resilient structure developed organically - not by management or consultant’s design, but by the needs of the people that work with them. 

Many organizations focus on designing collaboration models and defining how people are supposed to do their work. There’s a saying that will be familiar to most who have heard of Agile frameworks: “manage the work and let the people self organize around it”. This case study was a great example of this, and can serve as inspiration for other managers and leadership teams. Allowing teams to self-organise around the goal-setting framework has a big impact and can be a change management tool in and of itself, leading to new structures and ways of working.

Interested in transformation at your company? 

We are available for training, coaching, consulting, workshops, and courses, both in-person and remotely. Take a look at our online short courses, browse our Scrum and Kanban certifications, and check out our leadership courses. If you’re interested and want more information, feel free to contact us

Agile Strategy Map – Mapping at ACCUS

Two weeks ago, Olaf and I had the pleasure of participating in the AgileCoachCamp US (#accus). We played our brand new Kanban Pizza Challenge on the Games Day, and hosted multiple open space sessions. One of my sessions got exceptionally good feedback, so I decided to provide a little more information on the agile42 Agile Strategy Map

Dave in Full Flow

The opening question was how to effectively manage the work of the leadership or transition teams in large enterprise agile adoptions. The group quickly identified two scenarios: one in which the traditional backlog and task board approach worked extremely well; and one in which the backlog and task board lacked sufficient cohesion to lead an effective adoption, perhaps a result of lack of commitment or discipline.

In the latter case, we discussed the impact of using an Agile Strategy Map. This tool is used to visualize the strategy gap, the link between a corporate objective and the tactical actions taken to achieve that objective. As the following diagrams show, the Agile Strategy Map has 3 distinct components.

ASM Objective

First, the center of the map is the objective of the transition. Ideally, this objective will tie directly to delivery of the corporate goals or mission. In all cases, the objective needs to be clearly stated (rather than wooly management-speak). Preferably it describes what success would look like, to help bring clarity to the purpose of the transition and allow the team to measure their progress against the aims of the transition.

ASM Success Factors

Second, as a leadership team we elicit the possible success factors that, together, will contribute to the successful accomplishment of the objective. In this case, we want to keep in mind all the possible success factors, rather than aim to pick a limited number of critical success factors. Things will change, and part of the value of the Agile Strategy Map is that it visualizes a lot of choices that can be made to deliver on the objective, rather than only showing the current plan with a limited number of success factors.

ASM Full Map

Finally, for each possible success factor we want to brainstorm as many necessary conditions required to deliver on that single success factor. These actions and deliverables should be comprehensive, before we apply conditional thinking to bring the large number of possible actions to a minimum number of necessary conditions.

For more complex situations, any of these components can be considered hierarchically. For example, a single objective might be split into a further 2-3 objectives in different areas of expertise. In this situation, it may be possible that different objectives share some possible success factors.

The outcome is a visual representation of the many different conflicting and shifting priorities that have to be managed to deliver a complex, enterprise transition. The leadership or transition team can use the Agile Strategy Map as a starting place to prioritize actions, which are than managed through a traditional just-in-time backlog and task board.

The value of the exercise is less to do with addressing the underlying issues of commitment, discipline, or poor systemic prioritization (fire-fighting) and more to do with the value of a big visible chart that clearly outlines the connection between the actions that are taken and the achievement of the objective.

Thanks to all who joined the conversation, which was lively and informative.