Combine your OKRs with Agile Strategy Map™ for Success

/by

OKRs are one of the most widely used goal-setting frameworks, defined by a set of Objectives and Key Results, which each employee in an organization works towards. The Agile Strategy Map™ is a collaborative framework developed by agile42 that helps organizations design, manage, execute, and support their strategy. 

In this blog post, I’ll bring you an alternative look at the Agile Strategy Map™ and how organizations can combine it with the OKR approach to planning, with the ultimate result of more realistic goals.

What is The Agile Strategy Map™?

The Agile Strategy Map™  is a way to design a company strategy in a transparent and incremental way, based on continuous experimentation and adaptation. It makes this strategy available to everyone in the organization. The framework also provides a solid operating model that allows you to break down identified success factors into workable items, in a collaborative and agile way. agile42 has developed this framework through real-life experiences with clients and the help of many coaches who contributed over time to refine and improve its usability. The Agile Strategy Map™ can be a stand-alone tool for an organization, or it can be used in the context of an approach inspired by the principles of ORGANIC Agility. In this case, it corresponds to the basic principle of validating changes in small increments. 

What are OKRs?

OKR (or OKRs) stands for Objectives and Key Results, and it is a framework for setting a company, team, or individual’s goals. The value of OKRs is that they create transparency around the organization’s goals, which in turn helps employees feel more aligned and committed to achieving those goals. 

Further reading: A Complete Guide to OKRs

The overlap between OKRs and The Agile Strategy Map™

OKRs and Agile Strategy Map share two crucial principles that contribute to success:

  • Change (and delivery) in small and frequent increments
  • Engaging people actively in the process of change (and delivery)

Along with those principles, there are also a few other common elements:

  • Both spotlight focus
  • They combine bottom-up and top-down approaches
  • They have regular cadences
  • Each has roles

Advantages of The Agile Strategy Map™

The Agile Strategy Map™ will help you build more realistic KRs, experiment in a safe-to-fail way, and avoid flying blindly. There are a number of advantages to combining the two frameworks, rather than simply using OKRs alone. 

The Agile Strategy Map™ can distinguish the different types of KRs more clearly

I have been involved in many different companies’ OKR plans over the course of my career. I observed that the teams were usually struggling to name the correct “target” for their Key Results. Most of the time, people use common sense or draw from previous experiences or market benchmarks. The challenge is to strike a balance between ambition and achievability. The OKR framework uses different types of Key Results, including “Learning, Committed and Aspirational.” However, in reality, I’ve mostly encountered Key Results for “Committed” and “Aspirational” types; I rarely see “Learning” KRs. 

The Agile Strategy Map™ uses Success Factors

To indicate how you will accomplish your Goal, The Agile Strategy Map™ uses Success Factors. Depending on the organization’s prior knowledge level about the goal, these will be either Confirmed or Potential Success Factors. Distinguishing the “possibility” from “plausibility” will decrease your risk and improve the success of your decisions.

The Cynefin Framework presents the basis of this approach. Cynefin provides a way to make sense of the context we are in by observing patterns and constraints. It also provides guidance about the most appropriate way to act.

After analyzing our path towards the targets, if we don’t recognize patterns, best or good practices, governing or rigid constraints, most probably we are finding ourselves in an “Unordered Domain.” In that case, we have to be empirical, maybe design a few experiments to probe the environment in the hope to identify emergent practices. All the Key Results (or Success Factors) we see are the “Potential Success Factors” and we need to validate these at some level. 

The Agile Strategy Map™ allows you to see your journey more clearly

The Agile Strategy Map™ collects and shows all learnings, failures, and decision points. As Spanish philosopher George Santayana said, “Those who don’t remember the past are condemned to repeat it.” 

The Agile Strategy Map™ follows the insights and theory provided by Wardley maps, named after Simon Wardley. Wardley combined the thinking of OODA loops (the decision-making cycle of observe, orient, decide, and act) from military strategist John Boyd and The Art of War from Chinese general Sun Tzu to create a basic cycle for thinking about strategy. According to Wardley’s Map, good strategy tools shall be visual, context-specific, positional, and display connections. It helps us navigate the plan, anchoring us by reference a direction and suggesting a movement and/or changes, where we are going, and where we have been. 

The Agile Strategy Map™ allows you to iterate and improve on OKRs

OKRs are usually followed for a certain period, and when they are done, they are done. It’s possible to re-iterate the Key Results and make them more ambitious, but they don’t show you the journey and what you have learned along the way. Although OKRs are visual, context-specific, positional, and have anchors, they lack movement. They are static. They don’t suggest changes based on where you have been. This can make it difficult to recognize and respond to  the signals that are hinting towards direction changes, potentially invalidating the relevance of the defined Targets/Objectives. The Agile Strategy Map™ allows you to constantly introduce new Potential Success Factors (PSFs) as they appear, and quickly relate them to the existing map, and identify dependencies and impacts very quickly. 

How to combine OKRs and Agile Strategy Map™ 

It’s possible to combine the OKR framework to achieve the above-mentioned advantages. Here is an outline of how to do this effectively. 

Step 1: Create your OKR pyramid 

Define an inspirational goal for yourself and/or your team and then divide that into smaller, reachable, quarterly objectives. Then, define the Key Results that will help you reach your objective. Next, plot the tasks and projects that will result in achieving the defined Key Results. 

Step 2: Reframe your Objective as your “Strategic Goal” 

Ensure that your Goal has clearly defined “desired outcomes” which are measurable and connected to creating value for users, customers, and/or employees. They should also give direction. 

Step 3: Refine your Key Results and decide if they are “Confirmed” or “Potential” Success Factors

Confirmed Success Factors (CSFs)

Confirmed Success Factors (CSFs) are based on past learnings or proven practices and they might be in the form of processes, rules, policies, constraints, approaches. In short, they include everything that works within the organization, and has an established value proposition for customers. Given the defined Goal, we may identify a subset of CSFs that will be enablers for achieving that Goal. These are our “Committed Key Results.” The fact that they are confirmed tells us that they are Learned, and the fact that we choose them as relevant for achieving our goals makes them Committed.

A Confirmed Success Factor may be expressed in the following form: 

Potential Success Factors (PSFs) 

Potential Success Factors (PSFs) are hypotheses that we believe might help us to achieve our goal. These hypotheses need to be made explicit so that through transparency, dependencies can be made visible. The primary purpose of declaring explicitly what could be helpful towards achieving the goal is to identify changes or adaptations that can be used to our advantage. As such hypotheses could emerge at any time, integrating them with the Agile Strategy Map™ provides a means to re-evaluate our strategy and the relevance of all existing success factors.

A Potential Success Factor is expressed in the following form:

Step 4: Classify your projects and/or tasks as Necessary Conditions or Experiments depending on the Success Factors

To be able to leverage a CSF we need to maintain and continuously evolve it. This requires a CSF always has at least one Necessary Condition (NC). The NC will bring the strategy to a tactical level and allow operational work to start. NCs can act as an anticipatory trigger, reacting to or prompting specific events/needs. For example, we could periodically review a policy to check how it’s performing against some Key Performance Indicators (KPIs). 

We may express a Necessary Condition in the following form:

Experiments are our way to decrease the unknowns of our hypothesis, so we can validate or invalidate them as fast as possible, empirically, and without relying on assumptions that ultimately increase risk. Experiments also help prioritize and identify dependencies. They may need NCs as the prerequisite elements to start the Experiments. To get quick feedback and make decisions, the recommended duration of an experiment should be between four and 12 weeks. While, in Cynefin terms, experiments in the Complicated domain should evaluate identified options, experiments in the Complex domain aims at identifying potential options.

A practical example of combining OKRs with The Agile Strategy Map™

Let’s put all that theoretical knowledge into a more concrete example.

As the “Space Tourists Inc.” you have the company vision “Be the leader of the space tourism market.” During your annual planning meeting, you have decided to increase your share of space tourism as part of your Q1 goal. 

Example Key Results 

After some conversations with your team members and management, you picked two Key Results to focus on: 

  • Increase sign-ups for Mars travel by 30% (which you know will increase your share in the market)
  • Increasing the returning travelers by 20% (which you hypothesize can help to increase your share in the market)

Example CSFs and PSFs

In this example, you have one CSFs and one PSF.

Unpacking the CSF

We learned that “increasing sign-ups for Mars travel” can help us to achieve our goal of “increasing our share in the space tourism market”. We can measure it with the “number of the tickets sold to Mars.”  

  • Increasing sign-ups for Mars travel by 30% comes with two Necessary Conditions
  • We need to increase the Marketing Activities by 20%; otherwise, we can’t reach enough people to create Mars’ travel demand
  • We need to operate two more spaceships to Mars; otherwise, we can’t meet the demand

Although you’ve got some clear plans and conditions for increasing sign-ups, you aren’t sure if increasing the returning travelers will expand your market share. If there are more returning travelers, your market share will be higher if these returning travellers book more flights through you, and do not go through a competitor. 

In order to increase the number of the returning customers, you want to start with increasing the flight satisfaction. It makes sense to have this as a Key Result because your previous experiments validated that people tend to fly with you more than once if they enjoyed the experience. 

Unpacking the PSF

By improving our flight satisfaction, we expect that more people will sign up for a second flight as returning travelers (and don’t prefer a competitor), which should support achieving our goal of increasing the space tourism market share. 

Your hypotheses are, “if we can increase your flight service satisfaction and improve the landing experience, this will positively impact the returning customer rate.”

For each different hypothesis, you can create separate PSFs. 

Let’s start with the following piece of the puzzle: “by improving our in-flight service satisfaction…” If you achieve this, you expect that people will want to fly with you more often, which should support achieving your goal of increasing your market share in space tourism. We will measure this with an improved flight satisfaction survey.

Next, we’ll look at the “improve our landing experience” part. If you achieve this, you can expect that people will want to fly with you more often, which should support your goal of increasing your market share in space tourism. We can also measure this with an improved flight satisfaction survey.

Unpacking the Necessary Conditions and Experiments

Landing experience is strictly tied to one Necessary Condition, “Launching Landing Gear 2.0,” and one experiment, “Distribute laughing gas during landing.” 

  • We need to launch Landing Gear 2.0; otherwise, we’ll keep having hard bumps, which increases significantly the risk of injuring passengers 
  • To complete Landing Gear 2.0, we have to complete dummy-crash tests and score 100 points from the NASA evaluation. 

As for the experiment:

  • We need to distribute laughing gas inside our crafts during landing to foster positive memories. If we don’t, we won’t be able to positively influence the memories of our customers. 
  • To start experimenting, we need to buy laughing gas, buy a distribution device, and install the device in our crafts.

This example sums up the interpretation of OKRs together with the Agile Strategy Map. In that way, you can define your Objectives and Key Results with more clarity and confidence. 

Want a guided free demo of the Agile Strategy Map™?

Our experienced coaches are happy to talk you through this software and how it can supercharge your goals. You can read more about the Agile Strategy Map™ and pricing information, or contact us to book a free demo with our experienced consultants. 

Webinar | Agile Certifications: New Year, New Opportunities

/by

While the Agile journey is exciting, it can be overwhelming. In this webinar, our senior coaches Daniel Lynn and Giuseppe De Simone help to give you direction on this journey. They explore the many options and agile certifications available to you. They outline the Path to CSP as well as the many other qualifications and experiences that can help you along the way. When mapping out your path, our coaches explain that you should be guided by what you want to learn and how you want to grow. 

Watch now | Agile Certifications: New Year, New Opportunities

Stay in the loop about upcoming webinars by joining our mailing list 

Meet your webinar hosts 

Daniel Lynn started his career as a software engineer and found himself passionate about developing products inside of Scrum. He is an experienced Agile Coach with a demonstrated history of working in the information technology and services industry. Daniel is passionate about what he does and helping others. 

Giuseppe De Simone is a Certified Scrum Trainer, Certified Enterprise and Team Coach who is passionate about helping individuals, teams and organizations become more productive by embracing Agile values, principles and practices. Being an Approved Certified Agile Leadership and Path to CSP Educator, he is one of the very few in the world holding all the guide level certifications from Scrum Alliance. Giuseppe holds a Master degree in Electronic Engineering and started his career as a Software Developer. He became interested in how people can effectively work together and how teams can transform into an organism capable of delivering products and services which customers love. 

Browse the agile42 Agile Certifications

agile42 offers Scrum courses, as well as:

  • online Agile certifications;
  • Kanban training with certification from Kanban University;
  • ICAgile Agile Team Facilitation (ICP-ATF) and Agile Coaching Certification (ICP-ACC) training; and
  • Scrum Alliance Certified Agile Leadership training.
Scrum events

A Practical Guide to the five Scrum Events

/by

Scrum is simple. Indeed, it is a very lightweight framework everyone can understand. However Scrum is purposefully incomplete: It just defines the rules of the game, like the rules of a sport. You need to know the rules well to play a certain sport, but knowing them is not enough to win a championship. That’s one reason why Scrum is hard to master: you need to know so many things outside Scrum to make it work successfully. Since Scrum is based on empiricism, a key success factor is how well a team runs their Scrum Events, which represent an opportunity to inspect and adapt either the product or the process. 

In this article, we will give you some practical suggestions on how you can make them work effectively, which you will not find in the Scrum Guide. And even if you are not using Scrum, you will be able to apply what you learn here to other contexts. 

Recommended e-learning: Learn to run better Scrum Events with our Facilitating Scrum online course 

What are the Scrum Events?

There are five Scrum Events, namely the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. In this article we will take a deep dive into each of the Scrum Events that happen within a Sprint. In Scrum, the Sprint is a fixed length event of maximum one month, which contains all other events. 

Scrum online course

Scrum Events or Scrum Ceremonies?

The Scrum Events are often also called “scrum ceremonies”. This was a term used in the 90s and probably borrowed from some other agile framework, but it never appeared in the Scrum Guide, where the official term has always been “scrum events”, since its first version published in 2010.

Sprint Planning

The Sprint Planning event takes place on the first day of the Sprint. Its purpose is to plan the work to be done during the Sprint and the whole Scrum Team is involved in this event. Sprint Planning should have roughly three parts. Topic One should focus on the “Why?”. The outcome should be a defined Sprint Goal. Topic Two covers the “What?”. During this topic, the developers should work to decide which Product Backlog Items are going to be worked on during the Sprint, and if necessary, refine the Sprint Goal to reflect this. Finally, Topic Three deals with the “How?”. During this final stage of the meeting, the developers create an actionable plan to get the work done. 

Sprint Planning meeting

When: The first day of the Sprint.
Duration: The Sprint Planning should be a maximum of eight hours for a one-month Sprint. For shorter Sprints it is usually shorter, roughly four hours for a two-week Sprint. A good Scrum Team is usually able to plan a two-week Sprint in less than three hours.
Participants: The whole Scrum Team participates in this event: Product Owner (PO), Developers, and Scrum Master (SM). The event is usually facilitated by the Scrum Master. Other people may be invited by the Scrum Team, including anyone who can contribute to plan the Sprint, for example stakeholders, users or specialists from other teams.
Input: A well refined Product Backlog (PB) with an adequate number of ready Product Backlog Items (PBIs)
Output: The Sprint Backlog, consisting of the Sprint Goal (Why), the list of items pulled from the Product Backlog (What) and a plan for how to achieve the Sprint Goal and deliver the Increment (How)

How to run a Sprint Planning event

  1. Introduction
    The Scrum Master, who acts as facilitator, introduces the event by welcoming the participants, explaining the purpose of the meeting to the people invited by the Scrum Team and showing the agenda for the meeting. (5-10 min)
  2. Topic One: Why?
    The Product Owner takes the lead, provides an overview of the Product, and reminds everyone about the long-term aim for the Product as well as the current Product Goal. They come prepared and propose a draft Sprint Goal. For example, assuming that we are in a payment domain, a Sprint Goal could be: By the end of the Sprint, we will support card payments for all EU customers. (10-15 min)
  3. Topic Two: What?
    The Product Owner and the Developers quickly go through the Product Backlog. The Developers should have contributed to refining the Product Backlog, spending “just enough” time to do some final clarification and possible changes after the last Product Backlog Refinement session. (30 min)The Developers make a forecast of how much capacity they think they can spend on building the Increment during the Sprint and then select a list of PBIs they believe they can complete by the end of the Sprint. If those PBIs seem to be sufficient to achieve the Sprint Goal proposed by the PO, this part of Sprint Planning is complete. Otherwise the PO and Developers collaborate to craft a new Sprint Goal which better aligns with what the Developers can deliver. In the example above they might come up with something like: By the end of the Sprint, we will support only debit card payments for all EU customers. (15-30 min)
  4. Topic Two: How?
    The Developers collectively create an actionable plan to deliver the Increment. They self-organize on how to best achieve that. It is not necessary to create a detailed plan for the Sprint. Instead, the Scrum Team should anticipate emergent opportunities and be prepared to adapt their plan as they learn. It is probably enough to have an idea of what each Developer will do in the coming 2 to 3 days. In this phase of the Sprint Planning the PO is not really necessary. However it is good if they are available to answer questions or clarify customer needs. (30-45 min)
  5. Closing
    The Scrum Master thanks the participants for their contribution and officially closes the event. (5 min)

Tips for Sprint Planning

The Sprint Planning is not supposed to be a “surprise party” for the Developers. It is not meant to be the first time they look at the PBIs which are candidates to be pulled into the Sprint. Developers usually spend 10% of the Sprint capacity to work on refining the PB and look ahead at what might come in the next Sprints. Otherwise the risk that the Sprint Planning becomes an endless death march is very high.

Scrum master certification

Daily Scrum

The Daily Scrum is the moment where the Developers step back for 15 minutes, analyze where they are in respect to the Sprint Goal, and collectively decide what is the most important thing each Developer has to do in the next 24 hours to get closer to the Sprint Goal. It is a planning meeting, not a generic synchronization meeting. If your Developers are waiting for the Daily Scrum to speak to each other, you have a problem. 

It is important to focus the conversation on the most important Sprint Backlog Items, not on individuals stating what they have done. The Daily Scrum is not a status report meeting. The SM should help create the right environment to encourage open communication, identify obstacles, and promote quick decision-making.

Daily Scrum

When: Every working day at the same time
Duration: A maximum of 15 minutes
Participants: The Daily Scrum is the only event that is self-managed by the Developers. The role of the SM is to teach and coach the Developers to run it autonomously.
Output: An adapted Sprint Backlog, if necessary
Structure: The Developers decide how they want to run it

Tips for the Daily Scrum

It is usually not necessary that the PO attends the Daily Scrum, but it is also not forbidden. Even if the PO is not directly involved in planning how to build the Increment, the Daily Scrum can be a good moment to check how things are going and offer help to the Developers.

Sprint Review

The Sprint Review is an opportunity for the whole Scrum Team to stand in front of their users, stakeholders and customers and inspect and adapt the Product. It takes place at the end of the Sprint. The meeting should include an overview of the state of the product in terms of progress, budget and next steps. Usually, there is also a hands-on demonstration of the actual product. The users and stakeholders provide feedback, and then the developers incorporate relevant feedback into the Product Backlog.

Sprint Review

When: Last day of the Sprint
Duration: A maximum of four hours for a one-month Sprint. For shorter Sprints it is usually shorter: roughly two hours for a two-week Sprint.
Participants: The whole Scrum Team: (Product Owner, Developers, Scrum Master) as well as the customers, stakeholders and users. The event is usually facilitated by the Scrum Master.
Output: A revised Product Backlog and changes to the product or release strategy, if necessary
Structure: An inspection phase followed by an adaptation phase (working session)

How to run a Sprint Review

  1. Introduction
    The SM, who acts as facilitator, introduces the event by welcoming the participants. They explain the purpose of the meeting to the participants which can include users, stakeholders and customers. Then they show the agenda for the meeting. (5-10 min)
  2. Inspection phase
    The PO takes the lead and provides an overview of the state of the product in terms of progress, budget and next steps. They remind everyone of the Product Goal and describe the Sprint Goal the Developers were trying to achieve. (10 min)
    The PO leaves the stage to the Developers to demonstrate the Increment. This is not a PowerPoint presentation of what the team has done, but a hands-on demonstration of the actual product. Usually Developers will go through the scenarios described in the acceptance criteria of each PBI. Some teams even let users or customers try the product themselves, while the Developers and the Product Owner observe how they interact with the Increment. (30 min)
    The Scrum Team collects feedback on the Increment from all invited participants. (15-30 min)
  3. Adaptation phase
    Users, stakeholders and customers might leave the meeting at this point, while the Scrum Team continues with a working session to incorporate relevant feedback into the Product Backlog. Should the feedback be related to something which does not impact the upcoming Sprint, they can simply take notes to address the feedback in one of the upcoming Product Backlog Refinement sessions. However, if the feedback potentially affects the next Sprint Goal, the Scrum Team will perform a quick Product Backlog Refinement session during the Sprint Review to get ready for the upcoming Sprint Planning. (30 min)
  4. Closing
    The Scrum Master thanks the participants for their contribution and officially closes the event. (5 min)

Tips for the Sprint Review

The Sprint Review should not be a “surprise party” for the PO, who is supposed to collaborate with the Developers throughout the Sprint. The whole Scrum Team is accountable for delivering a valuable and usable Increment at the end of each Sprint.

Sprint Retrospective

The final Scrum Event is the Sprint Retrospective. The Sprint Retrospective is the only event in Scrum that is exclusive to the Scrum Team. The intention is to create a safe space where everyone in the Scrum Team feels comfortable to openly share their observations and express their views and ideas. The purpose of the event is to inspect how the last Sprint went and plan ways to increase quality and effectiveness.

Related reading: 11 ways to improve your Retrospectives

Sprint Retrospective

When: Last day of the Sprint, right after the Sprint Review
Duration: A maximum of three hours for a one-month Sprint. For shorter Sprints it is usually shorter.
Participants: Only the Scrum Team: Product Owner (PO), Developers, Scrum Master (SM). The Scrum Master usually facilitates the event
Output: An improvement plan
Structure: A good structure is suggested in the book “Agile Retrospective – Making Good Teams Great” from Esther Derby and Diana Larsen, which comprises the following 5 steps:

  1. Set the stage
  2. Gather data
  3. Generate insights
  4. Decide what to do
  5. Close the retrospective

How to run a Sprint Retrospective

  1. Set the stage
    The SM, who acts as facilitator, introduces the event by welcoming the participants and showing the agenda for the meeting. They work to create the right environment for focused and open communication. Maybe it was a tough Sprint, with conflicts and failures, and it is essential for the team to step back from the stress and consider different perspectives to find opportunities for improvement. (5 min)
    Here is a simple yet effective activity you can do. Ask every individual to write on one sticky note the worst thing going on in their head at the moment and on another sticky note what would make them happy after the event. Then ask them to throw away the first sticky note and keep the second one.
  2. Gather data
    Now it is time to gather both objective (e.g. number of found bugs) and subjective data (e.g. how the different people felt throughout the Sprint) from the Sprint. (10-15 min)
    Sometimes it is hard for people to recollect data after a few weeks. Consider asking everyone to report events when they happen (for example by adding sticky notes on a Miro board) with a short description and a time stamp. During the retrospective you can look at the sticky notes and order them on a timeline. Then each individual visualises their mood related to those events. Then you have both objective and subjective data in a single visual artifact.
  3. Generate insights
    Now it is time to look at data and try to find patterns. These will allow the team to identify one or two improvement areas. (15-30 min)
  4. Decide what to do
    Once the most important improvement area is identified, the team collaborates to define a few actionable items to incorporate in the next Sprint. Consider those items experiments. Once the team validates they actually lead to a positive impact, they can incorporate them into the team’s routines and practices. Using the SMART technique enables the definition of action items which are Specific, Measurable, Attainable, Relevant and Time-bound. (30-45 min)
  5. Close the retrospective
    The Scrum Master thanks the participants for their contribution, closes the event and encourages everyone to celebrate the Sprint. In an in-person setup, this might be a good moment for the PO to share a cake to thank everyone for their effort. (5 min)

Tips for the Sprint Retrospective

The most impactful improvements are addressed as soon as possible. They may be added to the Sprint Backlog for the next Sprint and usually 10% of the Sprint capacity is allocated to address those improvements.

Whether the PO should participate in the Sprint Retrospective or not has been debated for a long time. In the last few years, it has been agreed that the PO must participate in the Sprint Retrospective because they are not the boss of the Scrum Team but part of it and on the same level as SM and Developers. Retros typically include conversations around how to refine the Product Backlog or how to collaborate with the customer, which are part of the PO’s accountability.

The Scrum Master usually facilitates the Sprint Retrospective, but can also decide to participate in discussions. An example might include sharing observations about how the Scrum Team is running the Scrum Events. In that case it’s a good idea to ask another person to facilitate. This could be one of the Developers or a Scrum Master from another team.

Agile Challenges

Eight Lessons We Learned in 2021

/by

2021 was another unpredictable year. Although we seemed more prepared for remote working and different ways of doing business, there were, as always, some unexpected curve balls. COVID-19 variants, hybrid working arrangements, and cancelled Christmas parties, among many other challenges, made for an interesting year of work. If there is anything we can learn from the past few years, it is to expect the unexpected. There is always room to inspect and adapt. 

We asked you, our community, what your greatest agile challenges were from 2021 and what you learned from them. Here are eight of your biggest challenges, and biggest lessons, from the last year. 

If you fail to inspect, you fail to adapt

Having a plan and procedures in place allows you the opportunity to inspect and adapt. This is a vital step towards improvement. As Agile practitioner Jesper Ørting reminds us, “In sport, people train 99% of the time and perform 1%, but in business, we train 1% of the time and have to perform 99%, and we still expect it to work.” This begs the question: are we spending enough time planning, developing skills, and adapting? 

Scrum Master Riaan Johannes R reflects on how important having a plan was for his Program Increment (PI) Planning. “Face to face communication is already difficult with PI Planning, but doing this remotely is a nightmare,” he explained, “You need to not only have an agenda and a plan, but also facilitate via the tool you use and also know this off by heart.” 

Trust and openness can help to overcome uncertainty

When there is massive uncertainty, it can result in a lack of purpose, motivation, and cohesion among your teams. Scrum Master Floris Dafel experienced this. “I’ve learnt that a lack of purpose is like kryptonite to teams”, he said, “and it can be overcome by trust and openness. […] We did some trust-building team exercises that helped and also created our own vision where there was a lack of it instead of waiting for it. The challenges actually built a strong team in the end.”

Trust and openness

Photo by fauxels from Pexels

Change is a process and shouldn’t be imposed

For Agile Coach Matteo Betti, coping with change in a remote working environment was a massive challenge. They had the additional challenge of facing a massive reteaming. “I learned that you have to be patient and wait for the right opportunity to show things from different perspectives,” he explained, “Change should not be imposed. Scrum Master Daniel Palmisano shared a similar experience.“I learned that sometimes we have to be patient and let the people think about change and be willing to accept new ways of working,” he told agile42. 

During times of change, teams need time to embrace the process. The best thing a leader can do is communicate what is expected across the team, be open to new ways of working, and be patient.

Take action after a retrospective

While retrospectives can be a great opportunity to look back on a sprint and make plans to improve in the future, it’s important to make sure they’re geared towards real, actionable change. “Retrospectives can be great and insightful but the pitfall is that if nothing changes teams tend to say, ‘this is all useless!’,” shared Facilitator Valentina Sandi. “So Inspect – Adapt – ACTION”. A successful retrospective ensures action instead of running into the same issues every time.  

Make sure the team has a shared understanding of your goals 

When undergoing change and transformation, especially along your Agile journey, it is crucial that everyone shares the same understanding of both the process and the goal. “Our biggest fail this year was assuming that everybody on the team and organisation has the same understanding of what Agile and Scrum means,” reflects Scrum Master Claus Trohl. “We are now rectifying this by more widespread communication throughout the organisation.” 

Use the correct communication tools 

There are a multitude of tools that can help you communicate better, especially as more and more teams work remotely. For Lean and Agile coach Ilija Popjanev, changing their approach to communication has been instrumental. She says, “Our biggest failure was weak communication through emails. We learnt the lesson and switched to Slack and Whatsapp, now it is totally different.”

Use games, activities and tools in Agile facilitation

Mentor and Facilitator Nissaf Sleimi has incorporated games and tools to build resilience while facilitating. Using games to practise agile methods not only deepens our understanding of concepts but helps us to build confidence, communication skills, and trust. You can practise communication and other Agile concepts through these games, such as the Kanban Pizza Game. 

Agile games

Photo by Parabol on Unsplash

Keep learning, always

At agile42, one of our biggest lessons for the year was that the learning never ends. As we approach the new year, we want to make sure we’re not repeating old mistakes, and learn how to improve on the issues we’ve identified. Want to learn with us? Check out our online courses, enquire about our training and workshops, and sign up for our free webinars.

How to Kanban Your Christmas

How to Survive the Festive Season with Kanban

/by

It’s December, and ‘tis the season to be festive, whether you celebrate Christmas or just take some time off to spend with family, friends and loved ones. However you choose to spend your festive season, sometimes it comes with a little extra stress: bigger groups of people, crowded shopping centres, tight work deadlines, financial pressure, and family obligations can make December one of the most stressful months of the year. You might think we’re kidding, but handling this challenge with a more agile mindset can help smooth things over. Here are 10 ways to use Kanban to make your Christmas and festive season easier. 

Organise your Christmas gifts 

If you and your family and friends give gifts over the festive season, this can start to feel like an expensive, complicated task - and you want to make sure you don’t leave anyone important off your list! A simple Kanban board is a great way to streamline this task. Create a list of people you need to get a gift for on a Kanban board, with columns for each step. Move them along the board as you decide what to buy, purchase the gifts, and wrap them. 

Christmas gift Kanban Board.

Reduce waste 

One of the key principles behind Kanban is to reduce waste. In its original context, this meant using visual signals to indicate customer demand, and let the production floor know what supplies were needed. But waste can be thought of as anything that does not add value to your final product or goal. In the context of Christmas, this could mean using Kanban for shopping to ensure you only buy the necessary supplies, rather than doubling up due to a lack of clear communication. It also reduces the mental load on those who are usually overburdened at Christmas time (which is arguably the best gift you could give!) Kanban boards give you a clear, visual, centralised idea of everything that needs to be bought, done, or planned. This makes it easy for any member of the household to pick up a task and complete it without having to wait for instruction from someone else. 

Be more flexible 

In Kanban, all the information about a project - like Christmas dinner, gift shopping, planning a trip, or whatever else you might be doing during the festive season - is easily available, but also easy to reshuffle. Sudden changes can be highly stressful when you’re at capacity in terms of mental load. For instance, if your distant aunt invites herself over for Christmas at the last minute, you might feel overwhlemed and unsure where to begin changing arrangements. With a Kanban Christmas project in place, you can simply take a look and adjust the tasks that might be affected, without having to do all the math in your head. 

Collaborate on cooking 

A big feast - or feasts - forms a big part of the December vibe for many people. But anyone who’s ever tried to take the lead on a Christmas or New Year’s Eve dinner party knows that it’s not as simple as you’d think. Using a Kanban board, you’re able to allocate tasks and keep everything on a shared record, so that everyone is able to help where they can, and nothing slips through the cracks. Share the load and you’ll find everyone has a much better time! 

Christmas dinner family

Photo by Nicole Michalou from Pexels

Share tasks so nobody feels overloaded

Kanban makes it really easy to visualise the responsibilities and workload involved. This makes it really easy to see who is available to help out, and who might have too much to handle by themselves. There are few things as healthy for your relationships as allowing everyone to take ownership of what you do together, be accountable for what they’re bringing to the table, and share the load so that there’s nobody who feels overloaded. 

Be transparent

Kanban is about more than an efficient and dynamic to-do list. It’s about transparency, and allowing everyone involved in a project to have full access to all the moving parts. The clear advantage here, both in the workplace and in the home, is that it places everyone in equal standing and helps to remove points of tension that come about through lack of communication. Kanban also emphasizes the importance of explicit policies: there should be clear common goals with rules of engagement. When everyone agrees that what they’re doing is useful and helps contribute towards a goal, they’re a lot more enthusiastic to be involved. 

Plan a trip

Many people love to take a trip during the December holidays, whether it’s a quest to see snow, a beach vacation to escape the cold weather, or a little road trip to your home town. You can plot your itinerary on a Kanban board, and make lists of everything you need to get done beforehand - from travel documents and currency exchange to packing and bookings. It’s also a great way to split the load: you can assign tasks to your fellow travellers and keep a record of everything, to make sure the trip comes off without a hitch.  

December Road Trip

Photo by Jessie Crettenden from Pexels

Plan next year’s goals 

A Kanban board is a really fun way to set out your personal goals for the next year. You can add pictures, colours, and motivational quotes if you want to, or even deadlines, depending how seriously you take your goals and what tools you’re using. 

Make the kids’ tasks fun and visual

If you have kids, getting them to do chores during their school break can be a challenge. Add some colourful sticky notes, pictures, and break things down into simple, easy-to-complete parts, and kids can get really enthusiastic about helping out. You can also tie in a reward system to help keep things on track. Since the system is visual, it can also help neurodivergent kids out a lot, and they’ll easily understand what’s expected of them. 

Encourage self-organisation and ownership

One of the greatest parts of Agile frameworks, and Kanban specifically, is that it encourages self-organisation and ownership. Just like healthy leadership manages flow, not people, a healthy family knows what needs to be done and is able to take responsibility for tasks of their own accord, without having to be controlled. 

Curious about Kanban? Try our online Kanban Foundations course, designed to help you understand the foundational practices and principles of Kanban.

Design Sprint

Design Sprint: The Innovative Method from Google

/by

A Design Sprint is a five-phase process developed by Google Ventures, which combines the principles of design thinking, business strategy, behaviour science, and innovation. When applied correctly, the process allows you to complete projects that would previously have taken months of back-and-forth in a single week. This allows you to launch new products, enter new markets, develop new features, and more, in a streamlined, cost-effective way.

Watch: Design Sprints Webinar

agile42 coach Dennis Becker sat down with Managing Director of ITR8 and Founder of We Start Academy, Philipp Scheller, in an agile42 webinar to talk about Google’s innovative Design Sprint method.

They covered the basics before diving deep into how to put the theory into practice in meaningful, effective ways. They shared their personal experiences with the method, exploring tangible, real-world examples. 

Watch the full webinar below. 

Five key takeaways from the webinar

1. Design Sprints vs Design Thinking 

“Design Sprints are Design Thinking on steroids”, remarked Philipp Schellar during the webinar. The two are not one and the same: Design Thinking is a mindset and way of thinking, while Design Sprints are a method designed to solve a specific problem in a short time. “It is crucial to be lighting fast,” Schellar continued. “This gives you the competitive advantage. It forces you to move forwards faster than anyone else”. 

Recommended for you: Design Thinking foundations online course

2. Design Sprints are not always the solution 

It may be tempting to use a method that offers innovative solutions at lightning fast speeds, but the fact is Design Sprints aren’t a one-size-fits-all solution. There are some situations where a Design Sprint is not an appropriate method for problem-solving. These include: 

  • Problems with very broad questions: The method is best used for highly focused problems
  • Problems that can’t be solved in a single week: The method is only suitable for the kind of question that can be solved in the five-day process
  • Companies who don’t know and understand their customer very well: Since a design Sprint takes place in such a short time-span, you can’t waste time figuring out who the customer is 
  • Minor improvements: Design Sprints are not suitable for very minor, narrow, specific questions.  

3. Empathy is important in a Design Sprint

So many teams create fantastic products, but forget that they’re creating something for people. Empathy is a huge asset in a Design Sprint, because it helps one to understand what the journey of your user looks like, who you are creating products for, how people are using the products, and what value they find in the products. Empathy helps you to understand these needs and desires and build something great that people actually want to use. 

4. You need to make sure you start with all your research done

By the time you begin the Design Sprint week, you should already have a good sense of the customer, the problem you’re hoping to solve, and the specific question you want answered. There is simply no time to do this research during the sprint week. 

5. It’s important to treat your body well during a Design Sprint

Innovation can be exhausting, and it takes a lot out of you to be fully invested, creative, and engaged for the full duration of the Sprint. It’s important to take breaks and move your body. “We are so brain-oriented”, Philipp Scheller explained, “we totally forget that we have a body”. Make sure you treat your body with kindness – move, breathe, hydrate, and eat well – and you’ll be amazed at how much more clearly you can think.  

Design Sprint Training

If you want to learn more about Design Sprints, agile42 offers Design Sprint training. 

The course is led by seasoned professionals whose expertise lies in empowering people with the practical skills they need to be sustainably successful in a digital world. We focus on agile transformation, innovation management, design thinking, and product management.

This training is aimed at anyone who has to master complex challenges in their daily lives. This may include Agile coaches and product managers, team leaders, project managers, people in sales, managers, designers, agencies, brand managers, and marketing teams. If you would like to improve your decision-making skills, learn how to better coordinate teams, streamline client relations, improve business processes, or innovate in your market, this is the course for you.

Lean Coffee

Lean Coffee: What is it and how does it work?

/by

Lean Coffee is a meeting facilitation technique with a simple but effective format. It is structured, with a democratically selected agenda, and the discussion is led by the attendees of the meeting. 

What is Lean Coffee? 

In a Lean Coffee there are generally one or more facilitators, but it differs from a classic meeting format in that it does not have a predetermined agenda or a meeting leader. Instead, attendees suggest topics they would like to discuss, and then vote on these to create an agenda that is completely tailored to the needs and interests  of the attendees. For this reason, Lean Coffee is a great way to make better use of the time available in meetings, and make sure everyone is heard – even the introverts. 

Where did Lean Coffee Start?

Lean Coffee was started by two Lean coaches in Seattle in 2009. According to the official Lean Coffee website, Jim Benson and Jeremy Lightsmith were looking for a way to discuss Lean techniques without traditional, limiting structures. They “didn’t want to start a whole new cumbersome organization with steering committees, speakers, and such. They wanted a group that did not rely on anything other than people showing up and wanting to learn or create.”

These days, there are Lean Coffees all over the world, both in person and online.

When should you use the Lean Coffee format?

Lean Coffee is a great structure for almost any meeting type, but the structure is commonly used for sprint retrospectives, conferences, open days, Scrum events, or even to replace traditional corporate meetings. They are a good choice if you feel your meetings waste time, attendees are disengaged, and the same topics are discussed over and over again with no real progress towards your goal. They also make for great structured networking events, to bounce ideas off other professionals in your industry.

However, there are some situations when using the Lean Coffee format is not appropriate. An example is when setting a meeting about an important topic that needs to be discussed with your team, or when there are crucial updates that require someone to take the lead and share information.  

Lean Coffee Format

The Lean Coffee process is very simple, although it may vary depending on the size, location, and mature of the meeting. However, the basic structure remains roughly the same. 

Lean Coffee Kanban

Image by Parabol on Unsplash

Step one: Participants propose topics 

During the first phase of the meeting, all attendees are asked to suggest topics for conversation. In some situations, this is a complete free flow of ideas, while other Lean Coffees may have an umbrella theme to discuss, such as an upcoming product or a new goal. These topics can be written on sticky notes and placed on a whiteboard, typed on a virtual Kanban board, or put into a virtual list of any kind. This is a time-boxed activity, where everyone is encouraged to contribute. 

Step two: Vote on topics

Once topics, questions, and concerns are collected, attendees have the chance to vote for the topics they feel are most important to discuss. This can be done via virtual polling tools, or simply by drawing a dot on the sticky note in question. The topics with the most votes are gathered and this becomes the meeting agenda. The clear advantage here is that the meeting – by its nature – is structured around topics that attendees are motivated, invested, and interested in. 

Step three: Break into groups and discuss

Once the topics of discussion have been confirmed, each topic is assigned a time limit, and the group is split into smaller groups to discuss them in the time provided. Usually these discussions happen in smaller groups of three to 10 people. In a virtual setting, this would be done using a feature such as Zoom’s breakout rooms, while in person, groups would simply form in small clusters around the space. Smaller groups have been shown to facilitate discussion that has more depth and richness, and they encourage contribution even from the quieter members of the group. This process can be repeated for each topic.

Step four: Discuss key themes and takeaways

Following the breakaway discussions, the group gets back together to share their insights and discoveries. At this stage, the goal is to decide on the key takeaways of the meeting, and (depending on the context) next steps to take. 

Join our exclusive group to learn more 

If you are interested in connecting with like-minded professionals, and picking the brains of some of agile42’s coaches, you can join our LinkedIn group, The Coffee Club by agile42. If you join the Community, you’ll also have access to an exclusive forum with thousands of other agile and leadership experts, special offers and discounts on training, exclusive content, and events.

OKR

The Ins and Outs of OKRs

/by

Goals are what drives us, and creates a path to our success. Whether you’re a student, employee, or entrepreneur, you should have one big goal in mind that informs everything you want to achieve. But what do you do when you have identified the goal and know what you want to achieve? It’s time to break this goal into smaller parts and measurable outcomes, and Objectives and Key Results (OKR or OKRs) can be the perfect framework to achieve this.

Learn how to successfully implement OKRs in our virtual training: Get your OKR certification now

What are Objectives and Key Results?

OKR (or OKRs) stands for Objectives and Key Results, and it is a framework for setting a company, team, or individual’s goals. The value of OKRs is that they create transparency around the organization’s goals, which in turn helps employees feel more aligned and committed to achieving those goals. 

OKRs put outcomes first because it’s a way of working purposefully, rather than focusing solely on metrics, which can be misleading. Just like the goal of the agile teams, OKRs work to deliver value rather than just checking items off a list. 

Within OKRs, an Objective is what you want to achieve. Once you have an Objective, you  need to define Key Results, which describe how you will reach that Objective. Key results are visible and measurable outcomes which bring success to you and your organisation. When working with OKRs, we refer to all the projects and tasks that will help you realize your Key Results as “Initiatives”.  

John Doerr summarizes OKRs in his well-known book “Measure What Matters” as “Objectives and key results are like Yin and Yang of goal setting – principle and practice, vision and execution.”

What are Objectives and Key Results

OKR Examples

Even once you know the definition of OKRs, it can be hard to fully grasp how they work without some examples. 

Examples of Objectives

According to the definition in the book Measure What Matters by John Doerr, Objectives are defined as significant, concrete, action-oriented, and (ideally) inspirational. 

Although there were no OKRs at that time, there is an excellent example of an Objective in John F. Kennedy’s speech to Congress in May 1961: “I believe that this Nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him safely to Earth.“

Example OKR JFK 

More “formal” examples include the following:

  • Decrease the carbon footprint of every household in Berlin
  • Improve German fluency in daily conversations
  • Make the company website more user-friendly

Examples of Key Results

Author Christina Wodtke said it best when she said, “I know I’ve got the right Key Results when you are also a little scared you can’t make them.”

Key Results represent the “how” part of your journey. They need to be SMART (specific, measurable, actionable, realistic, and timebound) as well as ambitious and verifiable. You should have a direct influence on the results and be able to quantify them.

If we continue with one of the examples of an Objective from above, the related KRs could include the following:

  • Make the company website more user-friendly.
    • KR1: Increase loading speed by 20%
    • KR2: Shorten purchase flow from 6 steps to 3
    • KR3: Increase the NPS from 65 to 75
    • KR4: Grow the recurring visit 10% for Q4

Why do we need Objectives and Key Results?

The OKR process brings your ideas to life by helping you focus on what matters. Many teams and organizations suffer because of distractions. Distractions are all the seemingly good ideas that arise when working towards a goal, but don’t actually help to achieve that goal. They just overload you or take your valuable time without bringing any additional value.  

In addition to focusing your efforts, OKRs are also great for creating alignment, clarity, and achievable commitments, as well as tracking progress. 

The OKR framework is more than a goal-setting framework; it’s an essential part of the drive towards continuous improvement. It requires the involvement of every individual and involves every aspect of the business; from strategy to processes, behavioral changes, and even individual development.

How to write Objectives and Key Results

All levels of the organization and every department must be involved with setting OKRs, which need to serve the same company vision and strategy. Ideally, one individual (or team) should only commit to one Objective and at most five Key Results. 

This process will require making some bold decisions initially, especially when it comes to cleaning up all the unnecessary tasks and processes your company is accustomed to doing. It’s never easy to say “goodbye” and eliminate the hard work you have done before. However, if this work is no longer aligned with your OKRs, you need to be brave and focus on what matters. 

Step one: Define your business priorities 

To get started with OKRs, you need to start defining your long-term business priorities. You don’t need to have your entire future mapped out right away: three to four items for the next 12-month period is a good start. These priorities will form your organizational OKRs. This first step is at the strategic level and helps to define your direction for the year.

Step two: Break your annual goals down into smaller goals

Once your annual, high-level strategic OKRs are in place, you can start breaking them down to your tactical OKRs, which brings you one level down, to the operational level. These are your quarterly OKRs, and they will help you focus on the upcoming 90 days. 

Step three: Ask your team how they can contribute 

With your organizational and tactical goals defined, it’s time to bring the team on board. Engage your team, take a bottom-up approach, and find out from your team members how they can best contribute to achieving those OKRs. It is critical to involve your team at this stage, as these are the people who will be bringing the goals to life. The aim of this step is to define your Key Results. 

Step four: Plan projects and initiatives

Finally, teams can come together and start to plan the projects or initiatives they want to do, in order to fulfill their OKRs. 

Step five: Follow up

It’s essential to follow up on the OKR progress. Weekly or biweekly meetings are ideal to talk about the process, progress, and flow. They create transparency and accountability, and solve impediments.

Don’t be discouraged if you don’t successfully meet all your OKR results at the end of the quarter. Companies can rarely achieve their OKRs in their very first cycle. OKRs will mature and improve iteratively. Never forget that “perfection is the enemy of the good”: trying to perfect everything early on can get in the way of long-term improvement. 

The pyramid of clarity

It’s a challenge to create a balance between high-level, long-term goals and short-term plans. Asana’s “pyramid of clarity” is the way to see how things fit together. You can determine how every individual daily task fits into the overall company strategy and mission. When you use the pyramid of clarity, you provide responsibility, strategy, and purpose to your organization. It also assists in structuring your OKRs in nested OKRs and cadences.

OKR pyramid

Cascading vs Aligning OKRs

Cascading OKRs is the process of aligning objectives and key results from higher levels of the organization to lower levels. This ensures that everyone in the organization is working towards the same goals and that the objectives at every level contribute to the achievement of the organization’s strategic objectives.

To cascade OKRs effectively, organizations should start by defining their top-level objectives and key results. These should be specific, measurable, and aligned with the organization’s mission and vision. The top-level OKRs should then be communicated to the rest of the organization, along with the rationale behind them, to gain buy-in and commitment.

Next, each department or team should develop their own set of OKRs based on the top-level OKRs. These departmental or team-level OKRs should be specific and measurable and should contribute to the achievement of the top-level OKRs.

Cascading OKRs

Aligning OKRs refers to the process of ensuring that objectives and key results across the organization are aligned with the organization’s overall strategy and mission. This makes sure that everyone in the organization is working towards the same goals and that the objectives at every level contribute to the achievement of the organization’s strategic objectives, however it doesn’t mandate any hierarchical structure. Aligning OKRs allows for more flexibility and autonomy, and it keeps everyone on the same page. This is the healthy way of committing to realistic OKRs, because it gives an opportunity to everyone to be involved.

Between cascading and aligning OKRs, organizations should choose the approach that best fits their goals and needs. However, in the wrong hands, cascading OKRs could turn quickly to a hierarchical/top-down commanding tool and take away the team’s autonomy. Management should never use OKRs as a control mechanism. They will work at best for the empowered teams, who decide how to reach the desired outcomes. As an organization, you should be able to balance the objects with bidirectional goal setting.

Cascading OKRs (2)

Measuring progress through the OKR cycle

OKRs are a tool for setting and achieving goals. That means you have to take an organized, analytical, and initiative-oriented approach to writing and reviewing your OKRs. A great way to do this is by conducting weekly or biweekly meetings to discuss your OKR progress for the week. 

OKR Cycle - Cadences

How regularly should you review OKRs?

Checking and adjusting different levels of OKRs requires different rhythms: your big annual goals might require an annual check-in, for instance, while operational OKRs require weekly progress meetings. This is a great time to discuss your individual and collective progress toward your company’s stated objectives. During those meetings, you also should check your confidence towards OKRs and go over the week’s priorities.

It can be helpful to sync this cadence with your Scrum rituals. The initiatives can be divided into sprint goals and during every review, it’s possible to see the progress. Retrospective meetings are a great way to improve your processes and collaboration.

OKR and Scrum

OKRs vs KPIs: What’s the difference?

OKRs are not designed to keep track of every single thing going on in the company. They are stripped back to the most important goals, which will have a significant impact when you achieve those targets. KPIs, or Key Performance Indicators, are more focused on the day-to-day, business-as-usual aspects of the company. A KPI is a critical indicator of progress toward an intended result. You may measure many different things within your business, but only a few of them are crucial for your organization. Those crucial indicators are your KPIs.  

A great way to understand this is with the analogy of a car trip. The Objectives are your destination, and Key Results are the road towards this destination. KPIs, meanwhile, are your car’s dashboard, showing that your engine is running correctly. Just like the numbers in your car’s dashboard, your overall business performance, risks, and all the other activities are measured by KPIs. KPIs are direct indicators that immediately tell you if something is working or not. 

OKRs vs KPIs

Is a KPI and a Key Result the same thing? 

KPIs and KRs are not the same thing. However, in some cases, a KPI can become a Key Result. For this, it has to fulfil all of the following criteria: 

  • It needs to have a base-line, target value, time-frame, and an owner
  • It has to have the purpose of advancing you towards your vision and strategy. 

For example, revenue can be one of your KPIs. If you measure your baseline, you may set an ambitious but achievable target for a three-month time-box. If your tactical Objective is”drive worldwide sales growth,” you can add your revenue KPI as a KR: “Increase the Revenue from $3 million to $4 million in the fourth quarter.” 

Health metrics can add to your success

Health Metrics are all the other things clustered together that you need to keep an eye on to keep business going. They can vary from the Team Mood to Customer Satisfaction or Code Health. You may use traffic lights or any other metric management best practice. Just ensure that you don’t overcrowd your radar with unnecessary information. It’s also essential to have up-to-date data.

Company culture plays a significant role in success of OKRs

Adopting OKRs usually requires more than changing the project management approach. It’s a new way of working. A safe company culture is essential, wherein people are not afraid to set ambitious stretch goals, fail, and learn. As in any cultural transformation, change will not happen immediately. But it is possible to transform the company’s dynamics in a few months, if you focus on aligning and engaging the team. To achieve that, your mission and committed goals need to come first, and the team should feel comfortable speaking up and having disagreements. It’s also important to make it okay to deliver the bad news and impediments without fear. 

Conclusion

Consistency and focus are two big keys to achieving your goals, whether they’re long-term or short-term. Over time, your goals and accomplishments will add up and become the building blocks of your success. The OKR technique will increase your team’s capabilities and focus on the right things. It will change your company culture in a more open and collaborative way. All the self-reflections along your journey will make you more resilient and adaptive. Last but not least, don’t forget to celebrate your achievements, learn from your failures, and trust your team members.

If you want to learn more about the OKRs, we highly recommend reading Measure What Matters by John Doerr and Radical Focus by Christina Wodtke. 

Need help with your goal-setting?

Goal-setting is one of the most important predictors of success, but it’s also one of the hardest to get right. Sign up to the agile42 Corporate Learning Program and we can help you set your team up for success, with custom training and coaching based on your particular business needs. Contact us for more info. 

goal-setting and OKRs

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

/by

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. 

Mentoring

Why is mentorship so important?

/by

Mentoring is a relationship centred on personal or professional growth that aims to enhance your skills and help you gain experience in a certain area of your life or work. Many successful people have built part of their professional career on having a mentor. In my personal experience as a mentee, I have found that mentors can guide us through challenges we face, help us grow, and support our lifelong learning process. 

Quotes about mentoring

Read on to learn what mentoring is about, what makes it different to coaching, and how mentoring can help you achieve your goals. agile42 also recently hosted a webinar about all things related to mentoring, and you can watch it below.

What is mentoring?

Mentoring serves to transfer practical experience from one person (the mentor) to a less experienced person (the mentee). It is about the mentor sharing their relevant knowledge, experience, and skills while also providing guidance and support. This transfer of knowledge and building of experience is done through discussions, stories, sharing of anecdotes, and advising. Pairing up on practical matters at hand or practical demonstrations of procedures can also help to build up the mentee’s experience. 

Because mentoring is focused on the mentees’ personal and professional development, it usually is a long-term relationship which may also contain aspects of career or life coaching. A good mentoring relationship can be a powerful tool for growth, which could lead to a new job, a promotion, or even a better work-life balance. This is why it is never too late for starting a mentoring relationship – it is not limited to your onboarding phase when starting a new job or the early stage of your career.

WATCH: agile42’s Mentoring Webinar 

Agile coaches Ninja Granzow and Dennis Becker sat down to talk about their experiences and insights on mentoring, from the perspective of mentees. They answered the most pressing questions about mentoring: what is mentoring, and how does it differ from coaching? How can you set meaningful mentoring goals? They discussed the challenges in times of virtual collaboration, and how to nurture an effective mentoring relationship. Whether you’re a seasoned mentor, you have recently started a new job, or you are simply hoping to expand your skills, this webinar is worth a watch.

Coaching vs Mentoring: What’s the difference?

Mentoring is often confused with coaching, because a good mentor must also be a good listener and a good coach. And vice versa: coaches must sometimes act as mentors. As both coaching and mentoring provide similar benefits, there are a few key differences. To understand the differences, we need to explore what both coaching and mentoring are about in more detail.

What is coaching?

My personal coaching experience is as a Systemic Coach: in other words, a coach who works with the system. Systemic Coaching is non-directive, which means that it does not offer advise or direct solutions to problems. Rather, the focus is on asking the right open-ended questions, as well as providing trust, confidence, and space, for the coachee to have an effective and deep conversation and start to find their own solutions. 

The coachee usually has a need to address a specific theme or change, even if they cannot yet put this into defined words. The coach’s task is to help the coachee to define or refine this topic, reach their objectives and consider how to achieve more by finding capabilities within themselves. The information, interpretations, goals and actions all come from the coachee and the coach merely facilitates discovery through discussion. The approach to address the change is and remains up to the coachee. 

In professional relationships, coaching encourages individuals to perform in their roles, which often requires specific forms of coaching like Agile Coaching. Agile Coaching is the art of helping people see reality using an agile and lean perspective and change their paradigms, habits, and roles accordingly. It borrows a lot from Systemic Coaching. However, where the Systemic Coach is non-directing, the Agile Coach usually has an agenda of making the team more agile. As Agile Coaching has two very different sides (agility and coaching) there could also be teaching, role-modeling, advising, and mentoring involved in the process.

What is mentoring

How is mentoring different?

While coaching is about providing a safe space for a journey of self-discovery, mentoring is focused on transferring specific learnings from an experienced person to a person who wants to develop a specific area of interest. As an example, when I joined agile42, I was mentored by a more experienced Agile coach, who provided guidance and direction. In my own experience as a mentee, mentoring typically is less structured and more informal than coaching. Even though I recommend having a mentoring meeting agenda and goals at hand (and it is up to you as a mentee to put this together), coaching normally follows a more rigorous structure for having a conversation.

Why is it important to have a mentor?

For me, as a person committed to lifelong learning, it is helpful to have a mentor for staying focused in terms of my development path. There are so many interesting areas of learning, and I can easily get lost with too many options. I am grateful that I can regularly exchange ideas and thoughts with my mentor and get a different perspective on my plans and development.

Personal growth and development is about learning: learning new skills and behaviours, discovering blind spots, and constantly expanding existing knowledge. This makes both mentoring and coaching extremely effective learning techniques that can dramatically improve your individual growth and performance.

Being mentored could help to deal with situations you do not feel confident with because you have never done them before, lack insights, or need feedback. Mentoring helps with increasing confidence and developing interpersonal skills. This also includes exploring your comfort zone and expanding it step by step. You could learn from your mentor in order to prevent you from stepping into very common traps. 

From a company’s perspective, mentoring can increase employee engagement and retention, and also provides a great opportunity for mentors to learn more about different personality types, contexts, and points of view.

How to set mentoring goals

As a mentee, I found that achieving a goal was only possible after first getting to know my improvement areas, both short and long term, and across various aspects. I recommend asking yourself the below questions, and making notes on your responses:  

Skills and experience

  • What do you want to accomplish professionally in the next three months? 
  • What do you want to know or do within the next year?
  • Can you do it in your current role and with your current knowledge and experience? 
  • Are there any formal requirements you are currently missing?

Personal growth and development

  • What are you good at, and what are your major areas of improvement?
  • What do you want to focus on? Do you want to double down on your strengths or rather work on the things you find challenging?
  • What do you admire others for? How can you work towards those characteristics yourself?

You can start by brainstorming high-level dreams and then break down your lofty ideas into individual goals that you are more likely to accomplish through short-term learning cycles. 

There are a number of strategies and methods for defining your mentoring goals. 

SMART goals 

One strategy to create effective and realistically achievable goals is to use SMART goals. These are goals which are: 

  • Specific;
  • Measurable;
  • Achievable;
  • Relevant; and 
  • Timed.

The graphic below explains a little more about each aspect of a SMART goal:

SMART goals

Competency Mapping

Another option is a technique called competency mapping. It is easy to do and you could even create smart visuals like a matrix in order to create a living artifact you update regularly.

Here’s how to do it: 

  1. Start by listing all relevant tasks you need to be able to do, as well as the skills required to deliver these activities. You could also group competencies that are relevant to identify “core competencies”. This is a step where a mentor could provide direction and input.
  2. Next, run a self-assessment by comparing these competencies to your current experience. This allows you to identify areas of improvement which is a great input to define specific goals. You could easily combine this with using the SMART technique. 

Your mentor could also support you by guiding you through this assessment. When you have found suitable goals for yourself, your mentor can support you by helping you with the following:

  • What you explicitly need to achieve those goals. For example, is it about knowledge transfer or trying out certain steps to build experience? Expanding your comfort zone?
  • What small steps can you take towards the goal to make rapid progress?
  • Your mentor can report from their own experience and give suitable examples.
  • You can get “self-help” by asking your mentor to find helpful training.

Reflecting on goals 

Your mentor can help you to achieve your goals by constantly providing constructive feedback and guidance towards your goal. For example, I usually plan to revisit my mentoring process every 3-4 months or after I have reflected on bigger steps of personal development. Together with my mentor, we then talk about what to change or add. The more specific you can define your goals, the easier it will be to focus on the right things and also find a matching mentor .

How to choose a mentor

When choosing a mentor, one of the most important aspects is to find a person you trust. This is a good basis to open up and talk about your blind spots, improvement areas, and challenges you want to overcome. 

I believe that relationship-building and interpersonal skills are crucial in this context. Because this is a very individual thing, pay attention to your gut feeling. Who do you look up to in your network? Does this person have an honest and keen interest in helping you grow? Make sure this person sees mentorship as an option and not an obligation.

Mentoring should be built on solid and concrete advice, guidance, and first-hand experience, so your mentor also needs to have the knowledge and skills in the area in which you aim to grow. 

Last but not least, the right person should provide dedicated, long-term commitment. Based on my personal experience, a motivating, encouraging energy helps to spice up your development journey. A good mentor is also someone who is open minded and can learn from you as well – a good mentoring relationship is not a one-way street.

Do you need a great mentor? 

If you’re in a period of change or transition and you need to find the perfect person to guide you, get in touch! agile42 offers mentoring services, with certified mentors who are able to help you grow both personally and professionally. They can customise the offering to suit your specific needs, and provide professional guidance in any aspect of leadership, Agile, Scrum, and more.