Category: Agility

Fix Your OKRs – Back to First Principles

Context

OKRs (Objectives and Key Results) have become the latest management framework to suffer the fate of becoming popular too quickly, to the point where in many organizations, OKRs are a theater/charade with little useful substance or benefits. That’s a shame because OKRs have huge potential if used effectively. So let’s go about fixing your OKRs! 

Why OKRs

Let’s start with the basics. What are OKRs even about? 

OKRs aim to help you execute effectively on what matters most (your strategy), while overcoming silos, politics and turf wars, the ongoing grind (aka whirlwind), and other management challenges. To face all of these challenges, OKRs provide organizational alignment and focus. 

As defined by WhatMatters.com:

OKRs – an Alignment Framework – a collaborative goal-setting methodology used by teams and individuals to set challenging, ambitious goals with measurable results. OKRs are how you track progress, create alignment, and encourage engagement around measurable goals.

Let’s now dive into HOW OKRs (used well) set you up for success and what might go wrong. 

Achieving Focus – Focusing on the few Strategic Objectives

OKRs should help you focus on your strategic priorities. Having a small set of strategic objectives reduces context switching and provides a rallying cry that helps cut through silos and politics. 

Choosing where to focus is hard, though. It’s much easier to define an OKR for everything – and then when everything is important, nothing is really important. and that’s exactly what we often see out there. 

So with that in mind – 

Avoid … mapping all planned initiatives to OKRs. 

Try … rallying around 1-2 OKRs. 

Working IN the business vs. working ON the business

Another way organizations drown themselves in OKRs is by having OKRs for everything. 

Running the business doesn’t require OKRs. Key Performance Indicators (KPIs) can be used to manage/monitor operational work. 

OKRs should be used just for development/growth work – work we do to change how we do things. 

As you might imagine, This distinction helps reduce the number of OKRs significantly, leaving a set of fewer, more focused objectives. 

Development/Growth/Transformational work typically involves more uncertainty and complexity than running the business as usual. In this environment, a  lot is unknown – What’s the best way to achieve the goal? Does the goal still make sense? 

Our way of working ON the business might need to look different than our way of working IN the business. (see this article for a deeper dive on what working ON the business might look like, leverage the perspective of Private Equity firms who focus on working on the business to maximize value creation)

This environment calls for evidence-based management – a management approach designed to improve outcomes when facing complexity through unleashing empiricism, self-management, and cross-functional collaboration. 

OKRs are designed to be an evidence-based management approach. But there are a couple of key principles and practices that need to be in place for that to take place. 

Rally around Outcomes (rather than managing outputs/activities)

One key aspect in ensuring OKRs enable evidence-based management is the type of goals we use. Managing outputs and activities can work reasonably well for working in the business since that work is typically operational and defined. 

On the other hand, Using output/activity-based goals to work ON the business fixes plans, specifications, and designs too early. It reinforces a “factory” mindset where people focus on their deliverables rather than the wider problem/opportunity. And it lends itself to heavy-handed command and control. 

For complex, uncertain work, you should set goals using outcomes. Outcome-based OKRs unleash self-management, empiricism, and people’s creativity to explore/discover. They create environments where people are empowered to work together to solve problems. This is how you should be working ON the business. 

One of the challenges with managing through outcome-based goals is that you need to wait longer to see outcomes – making it tempting to manage through outputs or even activities. But remember – the role of OKRs isn’t to manage the day-to-day. It is to provide alignment around where to aim. People can use other processes to manage their work toward the OKRs. 

Instead of breaking outcomes into outputs/activities, experiment with identifying intermediate outcomes. This is challenging but satisfying (TIP: Slicing outcomes is similar to identifying a Minimum Viable Product, Minimally marketable features, and Slicing Stories… so your Product leaders and Agile practitioners can help out on this front). If coming up with outcome-based KRs is too hard, Start with making sure at least the qualitative Objectives are outcome-focused and, over time, evolve from output towards outcome KRs. 

Aligned Initiative over Command and Control

When leaders want to align their wider organization around their strategic goals, they often cascade OKRs throughout the organization. This strict cascading means that by the time you get to the people who will work towards the goals, they are bound to tasks/activities and don’t have the maneuvering room they need to seek the best way to achieve the goal, not to say reconsider what’s the best goal. This looks quite similar to OKR’s predecessor – Management by Objectives (MBO) which was very control-oriented. And it results in people who are disengaged. (did anyone say “quiet quitting”?)

There’s a false dichotomy that many leaders fall for, which is the belief that alignment requires control. Actually, alignment and control are two separate aspects that can work in concert to create effective management. Donald Reinertsen calls this Aligned Initiative. David L Marquet talks about Intent-based Leadership. Henrik Kniberg, in his usual brilliance, maybe nailed it best in this diagram describing Spotify’s “Aligned Autonomy” engineering culture principle (Jason Yip elaborates on this principle here). 

Why does initiative/autonomy matter so much? There are two main reasons. The most important one is that in the creative work that working ON the business requires, the best solutions emerge from the people in the trenches. And by providing them with a clear goal and empowering them to take the initiative, we dramatically improve our chances of achieving the desired outcomes. A secondary benefit is that people are intrinsically motivated by being empowered and provided with the right level of autonomy.

The key, then, is to achieve alignment without strict cascading. Leaders should use OKRs to provide context and direction. To inform about why rather than prescribe what/how. Teams/groups then come up with their OKRs. The connection can be reinforced as part of the “Why Now” for each objective. Teams/Groups share their intent with each other and with relevant leaders to help ensure alignment in an environment of empowerment/autonomy. 

(This might seem like a complex process to pull off… the good news is that there’s a lot to learn from agile ways of working about facilitating such processes. For example, I helped a fast-growing biotech startup create an approach for cross-company OKR planning leveraging a process similar to SAFe’s PI/Big Room Planning)

Figuring out the right Cadence 

A key aspect of evidence-based management is the feedback loop. Many organizations set OKRs for the quarter and then forget about them until the end of the quarter. It’s like setting your sales quota and only checking back at the end of the quarter. Recipe for disaster, right? 

The other extreme is to micro-manage OKRs to death. 

It’s all about finding the “goldilocks” cadence that provides frequent enough transparency and the opportunity to inspect and adapt at the right level. There can be a different cadence for everyone involved in achieving an OKR as compared to the cadence involving all stakeholders interested in that OKR. The right cadence also provides an opportunity to reinforce/communicate strategic priorities and focus. 

The Scrum framework provides one example of how such a cadence could look. Consider a cadence that involves Planning, Reviewing, and Retrospecting with a clear distinction between the team working on the OKR and its stakeholders. 

Cross-functional Alignment 

Leaders struggle to manage the cross-functional collaboration and dependencies many OKRs require. The coordination overhead makes it tempting to divide and conquer and cascade the OKRs into focused/defined OKRs for each function/group. The problem is that this immediately turns into output/activity focus and ends up with the same challenges described earlier in the Rally around Outcomes section. Why? Because functions cannot own cross-functional outcomes. 

So what’s the alternative? To organize around OKRs. After identifying the few real OKRs, assess who’s needed to work towards each of them. If they require cross-functional collaboration, create an empowered cross-functional work team to make collaboration easier. Another benefit of organizing around OKRs is that working on a team around a clear business strategic goal with a clear, quantifiable metric that the team is empowered to have a direct impact on boosts the feeling of purpose and creates better engagement and motivation. 

Disconnect/confusion between OKRs and agile ways of working

I often see teams and organizations that struggle with the relationship between OKRs and agile ways of working. They’re unsure of the best way to relate OKRs to their Backlogs and feel there’s a redundancy between the agile and OKRs cadence. 

Hopefully, at this point of the discussion, you can see that OKRs and agile ways of working are very similar. Both are based on focus, cross-functional collaboration, alignment, empowerment, and empiricism. 

So how do we address the overlaps? 

Some OKRs map cleanly onto existing teams/groups in a product development organization. In this scenario, they can inform the creation of Product Backlog Items for the team/s to focus on (or the creation of Features/Epics in a higher-level backlog ). If a new product development team or team of teams is created to focus on a cross-cutting OKR, the OKR can become the Product Goal / Vision for this new group. In both cases, how we’re doing on our OKRs should be inspected during Planning and Review events and inform decision-making. There’s no need for an additional ongoing OKR cadence. Quarterly or so OKR review/planning can replace “Release Planning” with a higher focus on outcomes/impact. If needed, this OKR review/planning can include a “dry run” planning exercise along the lines of SAFe’s PI Planning to make sure that the OKRs are both aligned with the business stakeholders and realistic. 

There’s a wider opportunity here, though. While Scrum was created as a framework for managing product development, it is appropriate for working on any complex problem. As we’ve established earlier, work to achieve OKRs is typically complex, even when it’s not product development work. The natural next step is to apply Scrum (or other agile ways of working) as the approach to doing the work towards achieving the OKR. Scrum can become the operating system for working ON the business.

All together now – OKRs AND Agility for the win

To sum up, OKRs and Agile/Scrum aren’t in conflict. Looking at OKRs with Agile/Scrum lenses reinforces the first principles that OKRs are based on. To successfully leverage OKRs, you should: 

  • Focus on working ON the business vs. IN the business
  • Stop starting, start finishing – Focus on a few key strategic initiatives (maybe even just one) 
  • Rally around outcomes rather than micro-manage outputs/activities
  • Provide alignment and enable initiative through empowered teams/groups
  • Organize around value – leveraging OKRs
  • Leverage agile/scrum to execute on OKRs
  • When in doubt – go back to first principles – Alignment, Empowerment, Focus, Empiricism

If you’re curious to learn more about these principles and how to apply them – a good place to start is the Evidence-based-management framework. The Scrum.org Evidence-based Management Training (PAL-EBM) workshop is a one-day workshop that explores this space and can be a great way to start fixing your OKRs or, better yet, get started the right way…

Iterating faster with SAFe

Here’s a frequently asked question in the SAFe community: I wanted to understand what SAFe says about someone who wants to go faster than 2 weeks of iteration? I mean the whole PI concept is based on 5 iterations worth of planning. What if a team/organization wants to develop and synchronize faster than 2 weeks? Is speed going to be compromised by following the standards of PI cadence?

Here’s my take:

Adjusting Cadence Length in SAFe — Can you? Should you?

SAFe considers the 2-week iteration length as a default rather than a rule.

The question you need to consider is what inspection and adaptation cycle you’re looking to accelerate — the Iteration or the PI.

Basically, do you want an opportunity to tactically adjust priorities more frequently than every 2w? Or do you want to adjust a more strategic direction more often than every 8–12w?

With the answer to that, you can experiment either with iteration length and/or PI length. Of course, the cadence length affects coordination overhead — there’s a fine balance.

Additionally, we’re talking about a Planning, Inspection, and Adaptation cadence — NOT the release cadence. Releases are on-demand meaning can be more frequent (or less).

Iteration Goals and PI Objectives provide us with room to maneuver

Another point to remember is that you can adjust iteration backlogs as long as you’re focusing on iteration goals. And even PI objectives can be adjusted — “Assume Variability Preserve Options”. If it’s occasional adjustment it’s not a reason to necessarily use a faster cadence.

Is team-level Kanban the solution to the need for more flexibility in SAFe?

Many teams think Kanban might be the best choice for them if they need more and more flexibility. Kanban CAN be a better fit if your demand is extremely volatile. I would be very careful though. Doing some level of goal-setting and prioritization and planning on a cadence is a powerful way for a team to focus. Do we really WANT to be a strictly reactive team?

Kanban combined with flexibility with some of the capacity we have each iteration can definitely be helpful and is why we recommend all Agile Teams in SAFe use Kanban to limit their WIP and improve their flow — this actually enables them to change scope even within an Iteration if that’s needed in order to achieve their Goal. (see my recent blog post that talks about dynamic scope in SAFe).

“Kanban Teams” in SAFe have an iteration cadence with the establishment of iteration goals even if not detailed iteration backlogs. Maybe that’s a good fit for your context maybe not. It might be an interesting experiment to try.

What if Planning a PI doesn’t make sense?

Finally, if PI planning doesn’t make sense even if PI is shorter — maybe you need to reflect on SAFes appropriateness for your context or on what’s so volatile about the demand coming your way and whether it’s “nature of the beast” or a systemic impediment to work on …

What’s the Bottom Line

What I tried to show here is that a conversation about what to do when the iteration feels too long should start with “Why”. Get to the bottom of what’s currently not ideal, look at the different options, consider Lean, Agile, and SAFe principles, and figure out whether it makes sense to change the cadence, change your approach to the balance between planning and flexibility, the difference between committing to goals and committing to backlogs, and the role that more flow-oriented techniques such as Kanban can play in addressing your issue.

Improving Focus and Alignment by Organizing around OKRs and managing OKR Flow

Improving Focus and Alignment by Organizing around OKRs and managing OKR Flow

Today, I wanted to share two quick observations about OKRs.

Too many teams working on each strategic OKR

I encounter many organizations that use OKRs. Too many of them have this crazy matrix where the high-level OKRs — those that aim to achieve the organization’s strategy — map to too many teams/functions in the organization. This creates a need to cascade the OKRs, create sub-OKRs, or other techniques which eventually create a larger and larger distance between the OKRs at the team level and the strategic OKRs. While this at least creates transparency of who’s involved in executing each aspect of the strategy, we can and should do better.

One key thing that unlocks agility and value is to “Organize around Value”. Scrum talks about each team having ONE Product Goal they focus on. SAFe has a specific principle around “Organizing around value”.

If you’re using OKRs One question to ask yourself is what is the relationship between OKRs and teams/teams of teams. If most OKRs require a multitude of teams across the organization/portfolio to achieve them, this will require a lot of coordination.

Try reorganizing into a value stream network/topology/team structure that aligns with your OKRs — where each team/team of teams can focus, and where there is clearer accountability around which team/group owns a specific high-level OKR.

Yes, you can find OKR and Agile management tools that will let you deal with complex networks of cascading OKRs, but Simplicity FTW…

Too many OKRs

Another symptom I’m seeing way too often is too many OKRs. Some of that is related to the OKR matrix I mentioned above. Some of it is just plain old push vs pull and classic wishful thinking at all levels. What could we do about that? Do we have a proven approach that can help? mmm…

Maybe we should visualize the FLOW of OKRs through the funnel of considering them, prioritizing/refining, committing to them, working on them, reviewing, achieving…
How about LIMITING and REDUCING the amount of OKRs in progress across the organization at any point in time — the alignment that OKRs promise relies on focus rather than trying to boil the ocean
Next, let’s manage the flow of OKRs proactively. Maybe even use some metrics like OKR cycle time, throughput, WIP, and aging.
Let’s inspect the flow from time to time. We might learn a few things. Maybe we should adapt the definition of how these OKRs flow and how we’re managing them.

How many of you ARE leveraging Kanban/Flow practices to improve how your organization uses OKRs to align strategy and execution?

PS do you see how similar this would be to a portfolio Kanban? Could it be the next generation of portfolio Kanbans? ????

Organizing around Outcomes with OKRs and Scrum

Aligning Scrum Team Topology to Strategy with OKRs and Product Goals

Yeah, I know. Could I squeeze more buzzwords into the title? I guess I could include Digital Transformation, Cloud, AI, and Machine Learning for effect. But seriously, I wanted to share some insights around how to align your Scrum Teams to your strategy leveraging OKRs and Product Goals.

Driving Change Using OKRs

We maintain performance by tracking the health of Key Performance Indicators(KPIs). We use Objectives and Key Results (OKRs) to drive performance change. Objectives point towards the desired state. Key results measure progress towards that desired state.

This performance change could be about our product or the ability to innovate/create that product. (Gap between realized and unrealized value / ability to innovate in evidence-based management (EBM) terms)

By setting OKRs we’re typically setting our sights on a complex problem — the space where Scrum and Empiricism thrive.

Achieving OKRs using Empiricism and Scrum

Working in self-managed empowered multi-disciplinary teams using fast feedback loops is a great way to tackle complex problems.

This is true regardless of how much IT or technology is involved. We might have an OKR that requires business change involving mainly legal, marketing, procurement, HR, and so on, that would still benefit from using Scrum’s empirical team-based approach.

For example, if a health care provider is aiming to digitize their patient journey to streamline it and make it more efficient, part of that will be to implement an electronic medical records system (EMR). But the objective isn’t just about implementing an IT system. It’s a change in the operating model. The organization supports this change by the development of new procedures, systems, and capabilities.

Focusing on Outcomes rather than Outputs

OKRs and Scrum are both designed to focus on outcomes over outputs. Most agile practitioners would recognize the N from “INVEST in User Stories” which stands for creating Negotiable user stories that provide optionality/flexibility for learning about what’s the best way to achieve outcomes. Having said that, most agile practitioners do feel like user stories are a form of requirements — meaning they are required.

Actually, user stories, any other form of Product Backlog Items, and even the Sprint Goal should be considered options — meaning they are optional. We currently think they are valuable, but we might learn of more valuable things to focus on.

Even the Product Goal is just an option. Maybe there we will find a better Product Goal for the Scrum Team to rally around or maybe there’s another better Goal that requires a different team topology.

Be Agile about your OKRs

Similarly, OKRs reflect the strategic direction at a certain point in time. We might learn something that would suggest a change in the Key Results or even the Objective itself. The frequent transparency provided by sprinting towards an OKR enhances the empiricism that might drive these realizations and is an enabler for strategic agility.

Many organizations fail to see this perspective. They consider OKRs as if they’re set in stone.

The same sort of time, budget, scope-oriented project management mindset that is hampering so many agile teams is affecting OKR implementations as well.

The problem with activity/output-based OKRs

Many OKR practitioners struggle to figure out how to break an annual strategy/OKR into meaningful outcome-oriented quarterly OKRs. By default, they break the big outcome into implementation steps a.k.a activity/output/milestone OKRs. It’s the project management mindset again — we basically bring in the classic work breakdown structure (WBS) into the OKR framework.

Going back to the patient journey digitization effort. Many organizations would define an initial OKR of choosing an EMR system. This is an example of an activity. It doesn’t deliver business value on its own. Once we set this OKR it’s harder to think of alternatives that might obviate the need for an EMR system in order to achieve the desired outcomes.

We’ve seen it happen countless times on agile teams struggling to slice stories in a meaningful manner and not sure how to come up with a useful Increment at the end of a short Sprint.

When working with OKRs we can leverage the same techniques that help these agile teams identify valuable partial outcomes that enable us to inspect and adapt our tactical and strategic direction.

Organizing Around OKRs

Another common reason why we see output-based OKRs is the team topology.

We often see organizations defining OKRs and then mapping them to their existing teams. In this example, this will mean cascading OKRs throughout different IT and business functions. The cascaded OKR grows farther and farther away from the desired Outcome because functions/silos can’t deliver these outcomes. They can only deliver outputs. Hence, the prevalence of Output-based OKRs.

After we define these OKRs the different functions will, of course, try to collaborate but we know how hard it is to collaborate effectively across functions. And with each group focused on an output-based OKR, we lose the opportunity to align around outcomes and are back to managing “projects”. This might work fine for some OKRs. But some OKRs are simply too complex to successfully achieve this way.

OKR-Driven Team Topology

A better approach might be to consider the level of complexity each OKR exists in. Then, create focused cross-functional Scrum Teams around the most complex OKRs. You might call this “OKR Driven Team Topology”.

Each one of these teams would focus on an OKR and have that as their Product Goal. Their Product Owner would have ownership of the OKR. This team would be THE team to talk to about this OKR.

If an OKR requires more people than would fit one Scrum Team consider forming a Nexus (or any other agile team of teams structure) around this Product Goal. Or maybe you can split the Objective and have separate Scrum Teams working on each Key Results (KR). There are multiple possible topologies.

The key point is to try and keep the outcome orientation all the way to the trenches where people work to create usable valuable Increments. In your Sprint Review, Inspect the Increments created with an eye towards your OKR. Adapting might mean changing tactics of how to achieve the OKR or even changing the Key Result or the Objective itself.

OKRs and Focus

The approach I laid out above is the ultimate way to achieve focus on one strategic outcome.

Realistically, not all OKRs would map 1:1 to a team or Nexus. And that’s ok. For example, you might have 20% of your most complex/critical OKRs handled using dedicated teams with the rest of them mapped to existing teams/functions.

If that’s the approach you’re taking, make sure you’re limiting the amount of OKRs that map to each team in each time period. For example, set an “OKR in Process” limit of 3 per team per quarter. And when a team hits the limit, don’t set the OKR for this quarter. This will drive a tough but important conversation about priorities. But it will set the teams and therefore the organization for a better chance to actually deliver on the strategic outcomes that matter the most.

Having 3 OKRs per quarter that you actually achieve is much better than 6 OKRs per quarter that drag on from quarter to quarter.

NOTE: You might find it useful to start tracking flow metrics (WIP, Flow/Cycle time, Throughput, Aging) as they relate to your OKRs…

When to organize around outcomes with OKRs and Scrum

In this article, we explored the relationship between OKRs, Scrum, the teams’ topology, and outcome/output-oriented OKRs (and teams!).

A key step in accelerating agility is to continuously assess whether you’re optimally organized around value. OKRs can provide a very useful lens to use for this assessment.

This is the time of the year when many of you are drafting your annual OKRs. Take this opportunity to consider whether your current team topology (in IT/technology and beyond!) is well-positioned to achieve these OKRs.

Another opportunity to use this lens is If you’re currently trying to figure out what your Scrum team topology should look like (e.g. when starting your agile journey, extending or accelerating it). Considering your strategic focus via OKRs is a great perspective to consider in this process.

A discussion about Strategy/OKRs and how they map to team topology is now a core part of my conversations with clients and our implementation strategy workshops.

Are you trying to figure out how to connect OKRs and Scrum in a way that organizes around outcomes? Feel free to reach out and we can discuss how I might be able to help.

COVID19 and Agile — a fresh perspective on uncertainty, complexity, empiricism and flow and what to…

The COVID19 pandemic gives us plenty of opportunities to think about uncertainty, complexity, and how to deal with those using Empiricism.

When it comes to our work in Agile teams and organizations, the first thing we need to acknowledge is that the first thing that happened to most of us is that we were tumbled all the way down from Maslow’s hierarchy of needs top levels down to the bottom — to our physiological needs. At the time we’re hoarding Toilet paper is probably not the right time to talk about Self-actualization and esteem or Mastery and Purpose if you want to use Dan Pink’s intrinsic motivation model.

In parallel to this tumble, many of us were still expected to continue with the business as usual of running Sprints and Program Increments. Some of us were even expected to adjust course to help our organizations deal with the impact of COVID19. After all — this is what business agility is about isn’t it?

When I ask my students, clients and friends in the agile community, the majority say that the importance of agility has gone up significantly, while actually being agile has become harder due to the physical distancing we’re all facing combined with additional responsibilities at home we have to juggle.

I find that the first step towards dealing with this new reality is acknowledging it. A tool I like to use to acknowledge uncertainty and complexity around WHAT we should build and HOW to do it is the Stacey Matrix.

Current times bring to the front a somewhat neglected axis of the model — WHO are the people on our team/group and what kind of interactions are they having. If the WHAT/HOW dimensions range from simple/known all the way to uncertainty and lack of agreement, when we look at the WHO aspect its about how effective are the interactions between the people. You could look at it as how far along the Tuckman model (Forming, Storming, Norming, Performing) they are. Drawing the three axis it kind of looks like an uncertainty spider/radar.

Many of my clients are facing increased uncertainty around WHAT to build. All of them are facing teams, groups, and ARTs that are back to Storming or even Forming from a team/group dynamics perspective because so much has changed in how they collaborate.

Moving from in-person interactions when you can have a certain level of focus throughout the work day to the limited communication bandwidth we’re getting when physically distant from our teammates combined with some challenges focusing, mean our implicit/explicit rules of engagement/working agreements aren’t necessarily working well for us anymore.

So what can we do? You can start by making this reality transparent. Talk about the uncertainty spider and its dimensions with your team. Self-assess where you were before the pandemic and where you are right now. Start a discussion around what to do about the differences/changes you’re facing.

Some concrete steps I’m seeing teams take are to run a team health self-assessment, discuss adjusted working agreements for a work-from-home environment, re-evaluate forecasts/commitments — e.g. by taking another confidence vote with the entire team (or Agile Release Train) and replan as appropriate.

Generally, historical velocity is even less predictive during this significant shift in how we work. YMMV (Your Mileage May Vary) definitely applies. Some teams take on less work into their Sprint and pull in more work if they see they’re doing ok.

Some teams see so much volatility in their Product Backlog that they shorten their Sprint Length because planning too far in advance doesn’t make sense.

Other teams focus on Goals for their Sprint rather than a detailed Sprint Backlog. (Teams I’m working with that are leveraging Kanban/Flow practices are more likely to think this way by the way).

Teams aware of their WIP (Work in Process) are starting to see the bigger picture of everything that is in process — not just the work on the team but also whatever’s going on at home and in life in general. When they do that they realize that it might make sense to reduce the WIP because we’re suddenly juggling more things while working.

The Daily Scrum becomes more important for many teams because they’re not sitting next to each other anymore and they lack the natural osmosis that happens in a team space. Some teams have multiple Scrums a day. Other teams setup an ongoing live video conference while they’re working individually which reduces the overhead of reaching out to team members and allows for a fun vibe of togetherness. Other teams use realtime chat rooms like Slack or MS Teams for this. Virtual Happy Hours. Watercooler Zooms.

Are all of these good ideas? Many of them will probably turn out to be good practices in the right context.

The important thing is that these agile practitioners acknowledge that things are different and that even during these stressful times and maybe especially during these times it is important to use an empiric process of seeing what works, what doesn’t, inspecting and adapting while keeping the spirit of collaboration, transparency, empiricism, and flow in mind.

The difference between Planned vs Actual vs Actual Actual Business Value when it comes to SAFe PI…

Actual is a relative term when it comes to business value delivered by a SAFe PI Objective. We had a discussion about this a couple of weeks ago in an Implementing SAFe class and I promised a blog post about this. Here it goes.

Planned Business Value — Making sure Business Owners and the Agile Team are on the same page

Let’s start from the basics though. PI (Program Increment) Objectives are used as a “back briefing” mechanism by Agile Teams on an Agile Release Train to share their plan for the PI and validate that they are indeed focusing on the highest priorities and are planning to deliver objectives that will be valuable for the business.

Business Owners (Business Executive, Product Management, System Architect) circulate between teams during PI Planning and score each PI Objective on a scale of 1..10 based on business value they ASSUME will be delivered in case this PI Objective is accomplished in the PI.

This becomes the “Planned Business Value (BV)” for that objective.

Actual Business Value — Assessing Business Value based on Demo of a real solution

Later on, during PI Inspect & Adapt (or earlier during System Demos) the same Business Owners circulate between the teams and score each of these PI Objectives again, this time on “Actual Business Value (BV)”.

What does Actual mean here? Well, in most cases the evaluation is based on seeing a demo of a working solution and still making ASSUMPTIONS about what the actual value would be when the solution meeting this objective will be released and available to real users/customers.

Sorry, but while being much closer, that’s still not ACTUAL business value.

ACTUAL Actual Business Value — Based on released solutions and the outcomes they deliver in the real world

ACTUAL business value delivered can be evaluated only AFTER the solution is released.

On most Agile Release Trains / SAFe contexts the PI I&A is too early to make this evaluation so you could understand why we’re still making assumptions at that stage.

But if we really care about outcomes and delivering value, we shouldn’t close the books on these PI Objectives and the PI at that point. We should get back to it later on and Inspect and Adapt based on real business value delivered.

Adjusting the SAFe Inspect & Adapt to track ACTUAL actual Business Value

If you’re with me, you’re probably asking what can we do about this? What is the right timing to get back and assess the ACTUAL actual Business Value? From a cadence perspective there are two main ways to do this.

The simplest is to take advantage of the Inspect and Adapt PI System Demo to review the ACTUAL business value delivered by the objectives in the PREVIOUS Program Increment. E.g. if we’re now finishing PI 5, we’re assessing actual business value delivered by the objectives in PI 5 that will be released sometime during PI 6, as well as PI 4 objectives that hopefully got released during PI 5.

For each one of these PI 4 objectives, now should be a reasonable time to talk about things like — Have customers started to use this solution? Are they happy with it? Did it achieve the impact we had in mind for it? Did we stop incurring the cost of delay we had in mind when prioritising this? At this point, the 1..10 score should be data/evidence-driven.

If we AREN’T able to evaluate the actual business value at this point — that means there’s a short-circuit in our empiric feedback loop that we should work on fixing.

If we haven’t released the solution yet, then we should keep the actual score for this objective empty and get back to it in the next PI. This objective should still be “work in progress” from our perspective.

It’s not DONE until we evaluated the ACTUAL Business Value

You might guess what’s the next aspect of this. Mentioning Work in Progress should be an obvious clue. The Program Kanban has a role in helping us out here as well. Features on the Program-level Kanban shouldn’t be considered DONE until we collected this feedback and evaluated the ACTUAL actual business value on them. They should hang out on the board — maybe in an area called “Feedback” or whatever you prefer.

I’ve been recommending this sort of Program-level Kanban Board structure for a long time now. Some of my enterprise-level clients have improved their Product Management practices dramatically through the accountability and follow-through that this practice encourages.

Just think about the impact on Product Management, Business Owners, Sales people asking for features, if they know they are accountable to the outcomes from these features after they’re released.

Who’s accountable for delivering the actual business value?

This brings us to an interesting question. Who’s accountable to delivering actual business value? Who’s accountable to delivering ACTUAL actual business value? Is it the Agile Team? Product Management? Business? Sales?

I’ve seen way too many teams frustrated when they deliver the objectives according to what they presented as the plan, and yet the actual business value score is lower than the plan because the Business Owners don’t think as much value will be actually delivered. When we’re moving from assumed actual to actual actual the gap can be even bigger. On one hand, in the spirit of transparency and being focused on value and outcomes rather than output, this is the right way to score the business value. It’s about value delivery rather than tracking to plans. On the other hand, you can probably understand the frustration here.

The way I see it, the only way out of this is to understand that the PI Objective plan vs actual vs ACTUAL isn’t an indication of the individual performance of either one of these roles. It’s an indication of the performance of the whole development value stream including the upstream activities related to choosing and prioritising features and the downstream activities related to selling the solution, convincing users/customers to use it, implementing it in the field, operating/supporting it.

That, together with Lean/Agile Leadership that emphasises principles such as Assuming Variability, Objective evaluation of working delivered systems, and relentless improvement of the whole value delivery cycle, is the key to focusing on learning from these surprises whether they are systemic and repeating or rare exceptions.

A relentlessly improving organisation would inspect what’s the trend when it comes to plan vs actual vs actual actual for the whole program and per specific PI Objectives and try to see what it can learn from when the value gap happens and does it happen for a specific type of objectives or in a specific area of the program/business.

It’s all about Value

Value is the goal of Lean and the fast delivery of value is the goal of SAFe. If we’re serious about that, We should raise our game when it comes to managing value as a first class citizen in SAFe. Business value on PI objectives is the perfect place for doing exactly that.

So, Next time you have PI Inspect & Adapt, don’t just look at the PI you’re finishing just now, take a look at the objectives from the previous PI as well. And on your Program-level Kanban only consider features done after evaluating actual business value delivered, ideally based on quantifiable metrics.

I love it when discussions at class drive me to write up some of my experiences, tips and tricks for the blog. Awesome kudos to my students, now SPCs off to implement a healthy and value-oriented SAFe in their organizations!

Musings about “Hard-coded” Frameworks

A recent discussion on the Scrum Alliance Linkedin group was around Mike Beedle’s claim that “Hard-coded Frameworks are neither Agile or Frameworks” which is clearly aimed primarily at SAFe.

I admit to thinking something similar before really getting to know SAFe in depth. Over time I realized SAFe isn’t one size fits all. Far from it.

It has many configurations and options. Do we need the Value Stream level? a System Team? at which level? How many ARTs? Component teams or Feature teams? Which metrics? Which ART to start with? Even if you don’t follow my Invitation-based SAFe implementation approach that is now a formal SAFe guidance article, you still have a lot of options at all levels and it is hardly a hard-coded methodology. Yes, not all practitioners understand this. But that’s a familiar problem from the Scrum space isn’t it. “Though shall do tasks”. “Though shall estimate in story points using planning poker”. “Though shall stand up in the Daily Scrum”.

Scrum was and is a powerful tool. SAFe, Enterprise Scrum, Nexus, LeSS, Kanban and others are powerful tools as well. A powerful tool is typically also dangerous at the wrong hands or the unexperienced hands without good guidance.

Besides — it IS funny to hear about the danger of force-fitting a hard-coded framework from leaders in the scrum community that have been telling us about SHU and following practices and the danger of scrum-but all along. And rightly so! Sometimes you do need to insist on a practice/change even if it feels hard! Agile IS about challenging your comfort zone.

Can we all agree that the real art/expertise is to figure out the right set of practices that is the goldilock between too much force-fitting and too-easy “common sense that is somehow too close to the status quo”?

(Updated) Oh — and also can we also agree there’s a huge difference between force- fitting practices to challenge your comfort zone (which is healthy change management done right) and forcing people to do something vs inviting them to consider trying it?

Exit mobile version