Category: Blog

Exploring the controversy around SAFe’s approach to Product Ownership

Exploring SAFe’s Approach to Product Ownership

What is SAFe’s perspective on the Product Owner role? How does it differ from the Scrum Guide? Why is Product Ownership split to Product Owner and Product Manager in SAFe?

SAFe’s approach to Product Ownership draws quite a bit of criticism. As a Professional Scrum Trainer who’s also a SAFe Fellow/SPCT, here’s my perspective…

 

Product Ownership is a crucial element in improving Outcomes

SAFe and Scrum both consider product ownership crucial to maximizing outcomes in environments of complexity and uncertainty. Teams are ideally organized around Products / Value Streams so they can apply customer-centricity. Product people and their teams are ideally accountable to outcomes and are empowered to figure out, inspect, and adapt requirements/scope as needed.

 

SAFe has multiple Product Ownership/Management layers

As organizations tackle bigger products, they have some alternatives for how to tackle product ownership/management. Scrum advises having one Product Owner for each Product, even if multiple teams develop the Product. This is at the core of scaling frameworks such as Nexus and LeSS. SAFe takes a path that is more aligned with the classic structure of Product Management organizations which is to have multiple layers of Product ownership/management.

Product Owners own Product at the Agile Team level. Product Managers own Product at the teams of agile teams level (Agile Release Trains). Solution Managers own Product for huge teams of teams of teams working on even larger products/solutions.

Why did SAFe make this choice?

SAFe takes the perspective of learning from experience in the trenches and what patterns organizations are using and applying lean/agile principles as needed to help organizations evolve. And many organizations have been struggling to scale product ownership when we’re talking about multiple teams. Product Management experts such as Melissa Perri also talk about multiple Product Management roles (see some thoughts about how this relates to SAFe below). Interestingly enough, Scrum@Scale also has Product Owners at every level. And LeSS/Nexus also introduce multiple Product Owners when you scale beyond a handful of teams.

The advantage of this approach is that it aligns with the Product Manager/Owner journey. Working closely with one or two teams, owning product choices for a couple of product features or a certain slice of the product can be a great jumping point for Junior Product Managers/Owners (What Melissa Perri refers to as Associate Product Managers in Escaping the Build Trap).

As the Product Manager/Owner gains experience, they can take on a whole product themselves. It takes time for a Product Owner/Manager to gain the experience to act as the visionary entrepreneur for their product. They might start feeling more comfortable writing stories and executing experiments and, over time, learn to influence, design product experiments, and make tougher prioritization decisions with multiple demanding stakeholders. In other words, Product Managers/Owners naturally evolve from focusing on tactics to strategy over time.

 

What are some downsides to splitting Product responsibilities between the Product Owner and Product Manager?

An anti-pattern we often see is that the PM/PO split allows an organization to staff the PO role with “story writers” and “project managers” – people who aren’t empowered as Product Owners, and that reinforce the project mindset of requirement order-taking and managing scope-budget-timeline. This lack of empowerment leads to delays and an environment where the team is focused on outputs rather than outcomes.

 

Empowering Product Owners and their teams is a common challenge in SAFe AND Scrum. What I’ve seen work well is carving out an appropriate product scope within which the Product Owner and team are empowered to figure out what to build to achieve the desired outcomes and optimize the value of that product or that aspect of a bigger product.

Doing this requires figuring out the product architecture and moving towards an empowering leadership style.

As in many other areas, SAFe takes the evolutionary approach. If you’re a purist or a revolutionary, you’ll probably struggle with it. Real-world practitioners are more likely to relate to the evolutionary approach. It’s important to ensure that the PO/PM separation is not seen as an excuse to continue doing everything the same.

Product Managers and Product Owners – A Collaborative Relationship

Leaders implementing the PO/PM split should ensure healthy collaboration, involvement, and partnership across the product ownership/management team.

Product Managers should internalize the SAFe principles of unleashing the intrinsic motivation of knowledge workers, in this case, Product Owners. Product Managers have a role as lean/agile leaders to nurture the competence, awareness, and alignment in the product team that would enable them to decentralize control and let Product Owners OWN a certain slice of the product.

Product Managers and Product Owners should have conversations about what decisions make sense to centralize and which should be decentralized. And the goal of Product Managers should be to grow Product Owners over time so they can make more and more decisions – and minimize the decisions that need to be made centrally. This is key to scaling without slowing down decision-making while still maintaining and ideally improving outcomes in alignment with strategic goals.

Increased risk of misunderstandings around Product Ownership with Product roles filled by non-product people

One very specific risk of the SAFe choice to split the PM and PO role is that it creates the need for many more people in a Product role than the number of people in the Product organization. This vacuum pulls people like Business Analysts, Project Managers, and Development Managers into the Product Owner role. Some people can become great Product Owners but come with very little Product (Management) experience. Business Analysts, for example, are used to consider what the customers say as requirements. They are used to the “waiter” mindset. They struggle to say no or to think strategically about what should be in the future or what should be in the product. Development Managers are used to being subject matter experts, guiding their people at the solution level, and managing the work. Project Managers are used to focusing on managing Scope/Budget/Timeline rather than value and outcomes.

Use the Professional Scrum Product Ownership Stances to Improve your SAFe Product Ownership

One technique I found very useful is to review the Professional Scrum Product Ownership Stances with SAFe Product Owners and Product Managers. We try to identify which misunderstood stances we’re exhibiting and what structures are reinforcing these misunderstood stances/behaviors. For example – what’s causing us to be “Story writers”? We explore the preferred Product Owner stances and discuss what’s holding us back from being in these stances. Why is it so hard to be an “Experimenter,” for example?

An emerging realization from these conversations is that SAFe structurally creates a setup where team-level Product Owners play “story writers” and “subject matter experts” more often. It’s non-trivial to switch to an environment where they are a “Customer Representative” and a “Collaborator” with the space to “Experiment” with their team towards the right outcome rather than take requirements as a given. It’s hard to get SAFe Product Managers to be the “visionary,” “experimenter”, and “influencer”. The issue here isn’t unique to SAFe. Product Owners struggle to exhibit these behaviors in most Scrum environments as well. What I find useful is to align on a “North Star” vision of what we WANT product ownership to look like at scale and take small steps in that direction continuously, rather than settle for “project management” or “business analysis” called a new name.

SAFe Product Management – Providing vision and cohesion in a Pharma IT environment

Let’s close with an example of how this can play out in practice. I’m working with the IT organization of a Pharma company. As they were thinking about how to help their Enterprise Applications group become more agile, one of the key questions was how do we create product teams that are empowered to directly support the business – by minimizing dependencies and creating real ownership of each of the enterprise applications as a platform that other IT functions can more easily build off of and leverage. Several Enterprise Applications have multiple teams working on different aspects of them. We created stream-aligned teams, each owning and managing that aspect as a Product. The Product Owners and their teams are empowered to consider needs and wants coming in from other IT functions and the business and shape the future of their product. Most of these product ownership decisions happen at the team level. Product Managers focus on alignment and cohesion across the platform. We are still working on establishing the right mechanisms to balance vision/alignment with local initiative at the team level.

 

SO WHAT NOW WHAT

SAFe’s approach to Product Ownership is a frequent target of criticism in the hard-core agile community. Some of it is pure business/commercial posturing (aka FUD) and some of it is fair and constructive.

My aim in this article was to help practitioners explore the rationale, the potential, and the risks behind SAFe’s approach to Product Ownership, as well as some patterns and models, such as the Professional Scrum Product Ownership stances, that can be used to inspect and adapt/grow the effectiveness of your product ownership approach.

As an individual Product Owner or Product Manager, you can use these models/patterns to drive your learning journey and to help you structure the conversation in your organization around creating the environment that empowers you to be a real Product Owner or Product Manager.

As leaders of Product organizations in a SAFe environment, I hope this can help you establish a vision of how you want your Product organization to look like and guide you on the way there.

It probably won’t surprise anybody that one of my most popular offerings these days is the “Fix our Agility” workshop/engagement with a starting point of SAFe Theater. More and more leaders realize that SAFe works better when built on the foundation of professional high-quality Scrum, which leads them to look for people with deep experience in both SAFe AND professional Scrum when looking for advice on how to bring the two together.

Note – Ryan Ripley and I explored this topic on a recent episode of Breaking the SAFe. Check it out if you prefer video/audio over the written word

The Next Agile Frontier – Agile Company Development

Dealing with common business challenges through agility

I’ve been helping companies improve their operations for over a decade. A repeating pattern is where a very successful company is facing growing pains affecting its ability to scale to the next level. Some examples of the challenges I’m called in to help with:

  • Losing the Ability to Innovate You often see companies that grow successfully to the point where it seems their ability to innovate stalls. When you look deeper, you see them struggling to cope with growing technical complexity, coordination costs across teams, and leadership bottlenecks. This affects product innovation as well as GTM innovation and other key business processes.
  • Time to Market / Time to Learn — The more complex the organization, the more time it takes to deliver value or close a learning loop. And in an environment of volatility, uncertainty, complexity, and ambiguity, this hurts your ability to compete. The bigger you are, the more you resemble the incumbents you once disrupted. Everywhere you look — product development or how the company runs its key business processes, there’s more and more friction and slowdown.
  • Losing Key Talent — Talented people are looking for an environment where they can thrive, have the right level of autonomy, work on interesting problems with minimum friction and headaches, and see the value and connect to a worthwhile mission/purpose. As companies grow, the way they operate becomes less and less attractive to talented people. They feel bottlenecked, stuck, and mired with more and more legacy and start looking for greener fields.

Business/Organizational Agility — The New Business Operating System

Addressing these challenges by improving our ability to innovate and deliver, solving complex problems in an environment of uncertainty, is what we call “agility.” It essentially translates to having a scalable ability to build/try/measure/learn, in fast cycles, customer-facing products, as well as business/internal processes, in a way that is aligned with the company’s strategic focus. You might also call these OKRs, Distributed Leadership, Nimble, DevOps, Lean Startup, or Scrum.

While Agile was created in the IT/Software world, more and more organizations realize that its principles and thinking apply broadly. Business/Organizational Agility is emerging as the term used for this new and improved “business operating system” that applies these agile approaches across the organization, from product development/IT through revenue-generating activities such as Sales/Marketing to how the C-suite/Senior executives are working as a team on the biggest gnarliest challenges the company is facing in executing and validating its business model.

This new “business operating system” typically requires some virtual reorganization to teams and teams of teams that own products/experiences/value, adoption of evidence/data-driven ways of working, and a leadership style that provides clarity and empowers teams to figure out how to work and how to achieve their goals. It includes work on focus/flow, empiricism, and continuous improvement at all levels of the organization.

A useful definition of the essence of this agility is provided in the Evidence-Based Management (EBM) framework created by Scrum.org. This framework can also be used to assess a company’s maturity on the journey towards being an “evidence-based managed company” or operating on an “evidence-based operating system.” The EBM framework purposefully stays away from prescribing ways of working.

In recent years I’ve been working with more and more companies that are applying these “Evidence-based agile operating systems” across the company.

The trigger to “upgrade the operating system” is sometimes proactive internal leadership. More frequently, there’s a major event driving it. This can be a major new threat/opportunity, a major change in leadership, or an investment/recapitalization event.

Focusing Agility Where It Matters The Most

Having a company-level evidence-based operating system doesn’t mean every activity in the company should be managed in an evidence-based manner. This way of structuring/working is especially useful when working on developing — developing products, services, or generally “ developing company #2” (the company you want to become). Running ongoing operations might or might not require this way of working.

Try this – once you come up with your strategy for the quarter/year (e.g. your OKRs) assess each element according to uncertainty, complexity, dependency, and impact. Then, based on this analysis, choose the ones that would benefit the most from an “evidence-based management approach” and plan how to manage them this way. This might mean organizing a cross-functional, empowered, focused team of the portfolio company employees and external SMEs (if relevant) that will work in short cycles to create useful increments of value in this area and review them frequently with other stakeholders. It might mean creating high-level “Goals” and providing people with clarity on the Bet while giving them the space to explore alternative ways to achieve the desired outcomes via trial and error in the trenches.

Replacing the Engine Mid-flight

More often than not, these strategic interventions will need to occur in parallel to continuing to run the business as hard as ever. People struggle to balance their day job (Company #1, the current company that needs to continue running) and transformation work (Developing Company #2 — the one we are working to create) — how much capacity to assign to each? Does managing the day job and transformation work as part of the same bucket make sense? Who’s in charge of each type of work? Who mediates when there are conflicts?

I hear from CEOs in these situations that they frequently need to get involved in resolving these conflicts between the day-to-day and the transformation. This results in delays, frustrations, and feelings of disempowerment. If this transformation also coincides with other bigger company changes (e.g., new leadership, new investors/owners), the environment is even more volatile.

Another common friction/frustration area is goal-setting. What should we focus on now? What’s realistic to achieve? Do we involve people who will do the actual work in goal setting? OKRs are a popular goal-setting mechanism. But they’re not as trivial to implement as they might seem… One common anti-pattern is to set too many OKRs, top-down. ( A better way is to provide alignment via Objectives and let teams come back with realistic Key Results. There’s much more to say about the effective usage of OKRs in a PE environment, maybe later…)

This balancing act between operational and transformational work, alignment, and autonomy is a key area of focus for business/organizational agility. In my experience, Patterns such as “product ownership” and “developers,” while they sound very IT/product-centric, can come in handy.

Organizing around Bets

Another common sign of trouble is when teams are overly dependent on other teams to the point that their progress is frequently blocked, and spend precious time coordinating and managing across the organization rather than executing. This can manifest as leaders of teams being extra busy in trying to coordinate the complicated network of dependencies and the desire for more and more “coordination/management layers” such as PMOs, project managers, and the like.

A preferred play is to reorganize around value — rethink team structure and bring together the people collaborating closely in executing the transformation into empowered, focused teams that self-manage with minimal overhead. These teams might include people from different functions — for example, Product Management, Marketing, Sales Enablement or Finance, Legal, and HR. This virtual team structure should be aligned with the key initiatives the company is focused on.

The New Frontier for Agility

Agile was born in software development and has been widely adopted in IT and Product organizations to the point that there’s little argument that product/technology organizations should operate using agility principles.

More recently, other functions, such as Marketing, have adopted these agility principles and practices. I see these as useful stopgap measures on the journey toward real organizational agility.

The next frontier I’m seeing in a couple of early adopter organizations is the evolution towards a more holistic definition of “development” that I explored in this article – developing the company’s capabilities.

The Future of Agile Roles != The Future of Agility

The story of Capital One laying off hundreds of people in Agile roles is making the rounds. I have no direct connection to Capital One, so I can’t comment about what’s going on there. 

What I can share is for years now, I’ve been coaching companies and leaders to see the Scrum Master and similar roles like the SAFe RTE as accountabilities relevant leaders take on (it can be formal managers/leaders or natural leaders from within teams that are passionate about agility and gravitate to this). See the Scrum Guide for Leaders. 

One example is the VP of Engineering in a growing startup, who decided to take on the SAFe RTE role (Chief Scrum Master for the Agile Release Train) since they felt it was up to them to provide this sort of leadership. 

Remember – Scrum Accountabilities != Scrum Roles

This way of thinking is supported by the 2020 Scrum Guide update that changes the language from Scrum Roles to Scrum Accountabilities. SAFe also sees itself as a dual operating system in parallel to the organizational structure, which means the Scrum Master and other roles should be seen as accountabilities.

If/When leaders take these new ways of leading and showing up to heart, it creates healthy and sustainable agility. Getting there requires support and coaching of course.

Sometimes you do need someone dedicated to agility

In addition, there are situations where no one is passionate about organizational performance, health, agility, and development. In these contexts, the right move IS to have a person dedicated to these accountabilities. Most of the time, these people are brought in to become part of the leadership team of a larger group. 

So what do the layoffs of Agile roles mean? 

Is “laying off all agile roles” a sign that a company achieved agile nirvana? Probably not. 

My take on what we’re seeing right now in the market is more often one of these scenarios: 

  • Companies wake up to the reality that they are DOING Agile (rather than BEING Agile) and see the Agile roles as part of the problem. 
  • Companies that believe in their Agile way of working and have achieved a reasonable level of agility. They want to continue to improve, but when they are looking to extend their runway in the current macroeconomic environment, they make the tough but necessary decision to spend less on the “future of work” and more around “doing current work”. 
  • Change in leadership and the loss of a formal or informal Agile Champion leads to a change in perspective about agility. 
  • Companies where people in agile roles are making an impact, but either don’t care or struggle to provide transparency to this impact in a way that will resonate to business people (think CFO). In the current context, this isn’t a very sustainable strategy… 

Now what? 

If you’re in an Agile role (Scrum Master, RTE, etc.) I recommend you focus on continuously improving the effectiveness and results of your team (or ART), in a way that is impactful to the business, ideally in a quantifiable way. Look at Evidence-based Management for ideas regarding what to focus on and what conversations to have with your team and your stakeholders. 

It might be frightening but you should also consider asking your team, stakeholders, and leadership a question used in Netflix – How hard would you fight to keep me here? The answer and conversation might be hard to hear – but it will provide the transparency you need to inspect and adapt your focus. 

If you’re in a big organization with a formal or informal agile role community of practice I recommend you make this a topic you work on. 

The optimistic in me hopes that, as a community, we will use 2023 as a wake-up call that will positively impact what we focus on and the value we bring to organizations. 

And finally, one of the hard truths about our role is that our ultimate success is when we’re not needed anymore. Moving between teams, contexts, and sometimes companies is part of this profession we took on…

Exploring the Connection Between Business Agility, OKRs and Private Equity – Interview w/ Yuval on the Quantive Dreams with Deadlines Podcast

If you’re here, you might be interested in OKRs. If so you should check out the Dreams with Deadlines podcast published by Quantive (formerly Gtmhub).

I was delighted to accept an invitation to come on the podcast to discuss OKRs, Business Agility, Agile, Evidence-based management and the connection to increasing value creation e.g. in the Private Equity space. Check out the podcast here or in the embedded audio below.

https://cdn.transistor.fm/file/transistor/m/shows/8550/f9a496eaa9f4c99574381dcc521d39a0.mp3
Dreams with Deadlines Podcast Interview with Yuval Yeret

We discuss the role of OKRs in aligning the goals of a portfolio company and how they can be used to facilitate cross-functional collaboration and focus on outcomes. we also discuss the importance of going beyond the surface level of frameworks like OKRs and Scrum to truly understand and utilize their principles, as well as the dangers of getting caught up in the hype of the latest buzzwords and trends.
 

What you will learn

  • The connection between business agility and OKRs in private equity
  • The role of OKRs in alignment and focus within an organization
  • The principles shared by various frameworks such as OKRs, Scrum, and SAFe
  • The importance of understanding and implementing frameworks effectively
  • The benefits of dynamic team organization and shuffling based on OKRs
  • The value of discussing outcomes rather than specifying outputs and having conversations about OKRs
  • The dangers of chasing the next shiny thing without fully understanding and implementing it
  • The connection between agile principles and OKR success
  • The role of transparency, collaboration, and psychological safety in creating a successful environment for progress and continuous improvement
  • The challenges and opportunities in improving work environments and creating meaningful organizational progress.

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…

Agility / Evidence-based Management and their role in improving returns in the Private Equity…

In this article, I’ll explore the need for and the attributes of an agile business operating system related to Private Equity (PE) portfolio companies. It hopefully helps leaders of such companies and PE professionals focused on the operations side expand their perspective on what “Agile” and “Agility” mean in their world and how they can help them improve returns realized in their investments.

Dealing with common business challenges through agility

I’ve been helping companies improve their operations for more than a decade now. A repeating pattern is where a very successful company is facing growing pains affecting its ability to scale to the next level. Some examples of the challenges I’m called in to help with:

  • Losing the Ability to Innovate You often see companies that grow successfully to the point where it seems their ability to innovate stalls. When you look deeper, you see them struggling to cope with growing technical complexity, coordination costs across teams, and leadership bottlenecks. This affects product innovation as well as GTM innovation and other key business processes.
  • Time to Market / Time to Learn — The more complex the organization, the more time it takes to deliver value or close a learning loop. And in an environment of volatility, uncertainty, complexity, and ambiguity, this hurts your ability to compete. The bigger you are, the more you resemble the incumbents you once disrupted. Everywhere you look — product development or how the company runs its key business processes, there’s more and more friction and slowdown.
  • Losing Key Talent — Talented people are looking for an environment where they can thrive — where they have the right level of autonomy, where they work on interesting problems with minimum friction and headaches, and where they can see the value and connect to a worthwhile mission/purpose. As companies grow, the way they operate becomes less and less attractive to talented people. They feel bottlenecked, stuck, and mired with more and more legacy and start looking for greener fields.

Business/Organizational Agility — The New Business Operating System

Addressing these challenges by improving our ability to innovate and deliver, solving complex problems, in an environment of uncertainty, is what we call “agility.” It essentially translates to having a scalable ability to build/try/measure/learn, in fast cycles, customer-facing products as well as business/internal processes, in a way that is aligned with the company’s strategic focus. You might also call these OKRs, Distributed Leadership, Nimble, DevOps, Lean Startup, or Scrum.

While Agile was created in the IT/Software world, more and more organizations are realizing that its principles and thinking apply broadly. Business/Organizational Agility is emerging as the term used for this new and improved “business operating system” that applies these agile approaches across the organization from product development/IT through revenue-generating activities such as Sales/Marketing all the way to how the C-suite/Senior executives are working as a team on the biggest gnarliest challenges the company is facing in executing and validating its business model.

This new “business operating system” typically requires some virtual reorganization to teams and teams of teams that own products/experiences/value, adoption of evidence/data-driven ways of working, and a leadership style that provides clarity and empowers teams to figure out how to work and how to achieve their goals. It includes work on focus/flow, empiricism and continuous improvement at all levels of the organization.

A useful definition of the essence of this agility is provided in the Evidence Based Management (EBM) framework created by Scrum.org. This framework can also be used to assess a company’s maturity on the journey towards being an “evidence-based managed company” or operating on an “evidence-based operating system.” The EBM framework purposefully stays away from prescribing ways of working.

In recent years I’ve been working with more and more companies that are applying these “Evidence-based agile operating systems” across the company.

The trigger to “upgrade the operating system” is sometimes pro-active internal leadership. More frequently there’s a major event driving it. This can be a major new threat/opportunity, a major change in leadership, or an investment/recapitalization event. This is where the Private Equity (PE) connection comes in.

Private Equity — Betting on improving the value of companies

Generally, at least in my understanding, PE firms search for opportunities to “improve” assets in the form of companies. This improvement can be described as taking a company with current value (CV) and tapping into unrealized value (UV).

These opportunities are identified and validated via a Due Diligence (DD) process. Traditionally, PE “deal teams” focus on this gap between CV/UV and forming an investment hypothesis around what might be the return on investing to realize this additional value over a certain number of years. At this point, the PE deal team has essentially a set of “bets” that if successful will create outsized value for the investors.

Why are we saying bets/hypothesis? Because there’s a level of uncertainty around whether indeed these bets will create the value they’re intended to. There’s also uncertainty around the company’s ability to change/transform in the way these bets require. Some bets require creating products, and some change how products are sold/serviced. Some require different organizational structures. Regardless of the type of bet, one other thing to consider is that if this was such a sure bet — wouldn’t current company owners move forward on this already? In some cases, the answer is that they couldn’t without the funding brought in by the PE round. In other cases, the answer is that making the change isn’t trivial, and requires a strong capability to innovate and deliver in the company.

Validating Change Readiness as part of the PE Investment Hypothesis

One inherent but sometimes implicit bet is whether the company is change-ready. Does it have the culture and operating systems needed to execute the investment thesis? While traditionally PE firms focused mainly on the financials, more and more are realizing the importance of assessing and thinking about culture, team health, and other operational aspects as part of the investment thesis. Looking at modern due diligence processes, you might recognize elements of Lencioni’s 5 Dysfunctions of a Team framework (or The Advantage), eNPS/Glassdoor results, or other cultural / talent-oriented aspects. The EBM framework described above provides an additional facet to explore and think about.

If gaps are identified, working to become a lean, mean, agile change-ready company using an evidence-based operating system should be considered part of the PE “100 days plan” — as an enabler for working on other elements of the business transformation plan.

Focusing Agility Where It Matters The Most

Having a company-level evidence-based operating system doesn’t mean every activity in the company should be managed in an evidence-based manner. This way of structuring/working is especially useful when working on developing — developing products, services, or generally “ developing company #2” (the company you want to become). Running ongoing operations might or might not require this way of working.

One exercise that a PE deal team can run with the leadership team of a portfolio company is to assess each element/bet in the investment thesis and categorize bets according to uncertainty, complexity, dependency, and impact. Then, based on this analysis, choose the ones that would benefit the most from an “evidence-based management approach” and plan how to manage them this way. This might mean organizing a cross-functional, empowered, focused team of the portfolio company employees and external SMEs (if relevant) that will work in short cycles to create useful increments of value in this area and review them frequently with other stakeholders. It might mean creating high-level “Goals” and providing people with clarity on the Bet while giving them the space to explore alternative ways to achieve the desired outcomes via trial and error in the trenches.

The Day-to-Day Challenges of the 100 Days Plan

Some interesting challenges typically stress the business operating system when executing a transformation.

People struggle to balance their day job (Company #1 the current company that needs to continue running) and transformation work (Developing Company #2 — the one we are working to create) — how much capacity to assign to each? Does it make sense to manage the day job and transformation work as part of the same bucket? Who’s in charge of each type of work? Who mediates when there are conflicts? What I hear from CEOs in these situations is that frequently these conflicts between the day-to-day and the transformation go all the way up to their table, resulting in delays, frustrations, and feelings of disempowerment in times when people are already sensitive to any cultural changes and there’s increased challenge to retain top talent.

Another common friction/frustration area is goal-setting. What should we focus on now? what’s realistic to achieve? Are we involving people who will do the actual work in goal setting? OKRs are a popular goal-setting mechanism. But they’re not as trivial to implement as they might seem… One common anti-pattern is to set too many OKRs, top-down. ( A better way is to provide alignment via Objectives and let teams come back with realistic Key Results. There’s much more to say about the effective usage of OKRs in a PE environment, maybe later…)

This balancing act between operational and transformational work, alignment and autonomy, is a key area of focus for business/organizational agility. In my experience, Patterns such as “product ownership” and “developers”, while they sound very IT/product-centric can come in very handy.

Organizing around Bets

Another common sign of trouble is when teams are overly dependent on other teams to the point that their progress is frequently blocked and spend precious time coordinating and managing across the organization rather than executing. This can manifest as leaders of teams being extra busy in trying to coordinate the complicated network of dependencies and the desire for more and more “coordination/management layers” such as PMOs, project managers, and the like.

A preferred play is to reorganize around value — rethink team structure and bring together the people collaborating closely in executing the transformation, into empowered focused teams that self-manage with minimal overhead. These teams might include people from different functions — for example, Product Management, Marketing, Sales Enablement or Finance, Legal, and HR. This virtual team structure should be aligned with the key initiatives the company is focused on.

Continuing the conversation

Disclaimer: If it’s not obvious by now, I’m not a PE expert. I wrote this article based on my experiences as an agility coach in the trenches with PE portfolio companies, conversations with former clients who went through a PE transaction later on, conversations with CEOs, and my research into the PE space (I found the ParkerGale Private Equity FunCast especially useful btw). I’m sure I’m butchering some PE lingo and process. Please, call me out on it!

Hopefully, this article, as imperfect as it is, convinces you to take a different look at agility as something you or others in the PE ecosystem you work with should care about. If it has, or if it hasn’t, I’ll be happy to hear your reactions or comments and am of course happy to help you explore further.

Originally published at https://www.linkedin.com.

Working towards Sustainable Pace in Scrum, SAFe and Kanban

Aiming towards Sustainable Pace

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” — The Agile Manifesto Principle

“programmers or software developers should not work more than 40 hour weeks, and if there is overtime one week, that the next week should not include more overtime.” — Extreme Programming

An unsustainable pace is unhealthy. It contributes to burnout, quality issues, and unpredictable results.

If you are an agile leader — do you know whether your teams are currently operating at a sustainable pace? Do you care? Would you rather not know because you’re afraid of the answer?

Measuring Sustainable Pace

Beyond having a general idea of the sustainability of pace, perhaps it would help to have a concrete KPI related to it?

If we use the language of OKRs, maybe something along these lines:

Objective Achieve a healthy sustainable pace KR1 — People working reasonable hours AMB (as measured by) hours per week KR2 — People happy about their pace AMB continuous survey KR3 — Plans don’t assume unsustainable pace AMB ability to achieve forecasts without resorting to unsustainable pace measures

Forecasting towards Sustainable Pace by inspecting sustainability of past pace

The last KR relates to the planning/forecasting approaches we use in agile. Agile approaches leverage empirical planning approaches. They look at the past (Yesterday’s weather) to try and forecast the future. Whether it is PI Planning, Sprint/Iteration planning. Whether by looking at Velocity, Throughput, or Cycle/Flow Times — most approaches tend to ignore how these past results were achieved when using them to predict future capacity.

For example, if our velocity in previous Sprints was 15–20 points, we will probably take on about 15–20 points. But what if these 15–20 points required a herculean effort that wasn’t sustainable?

Similarly — if we just concluded a PI in which the ART achieved a Program Predictability Score of 85% we will be tempted to assume we have a pretty serviceable approach to planning/forecasting. But what if this required killing it through nights and weekends and skipping any sort of Innovation in the IP iteration? Where does this come into the calculation?

If our cycle/flow times are 7–10 days 85% of the time we will be tempted to set that as an SLE (Service Level Expectation) to ourselves. But does that make sense if this was achieved while working 60 hour weeks?

Planning/Forecasting using a Sustainability Factor

What I’m advising teams/organizations I’m working with is to consider the “sustainability factor” when considering any past results for the purpose of forecasting the future and adjusting accordingly. This isn’t trivial. It requires making sustainable pace an explicit “citizen” of the measurement dashboard and conversation.

We have learned that speed and quality are related. We now understand that inappropriate speed might be at the expense of quality, so we look at a balanced scorecard of speed and quality. Moving forward, we need to add pace sustainability to this scorecard and to the conversation around how much work does it make sense to forecast.

A metric I’ve been toying with is Weighted Predictability/Sustainability:

As you can see here, achieving reasonable predictability scores is weighted down by the unsustainable pace required to achieve them. so a score of 80% is actually weighted down to 53%. This 53% is what should be used for future planning purposes. For example in SAFe I&A and PIP.

Moving Forward — Treating Pace Sustainability as a first-class citizen

First, we need to come up with a good name for this metric / KPI. Flow Sustainability? Pace Sustainability? Work Sustainability? Burnout Risk?
 Are you explicitly measuring anything related to Sustainable Pace? Do you have goals around it? Do you take it into consideration when planning? Please share in the comments!

Connecting OKRs, KPIs, OVSs, and DVSs in SAFe® — Scaled Agile

The title of my post may read like acronym soup but all of these concepts play a critical role in SAFe, and understanding how they’re connected is important to success. After exploring some connections, I will suggest some actions you can take while designing, evaluating, or accelerating your implementation.

KPIs and OKRs

The SAFe Value Stream KPIs article describes Key Performance Indicators (KPIs) as “the quantifiable measures used to evaluate how a value stream is performing against its forecasted business outcomes. “

That includes:

  • Health of day-to-day performance
  • Work to create sustainable change in performance

Objectives and Key Results ( OKRs) are meant to be about driving and evaluating change rather than maintaining the status quo. Therefore, they are a special kind of KPI. Objectives point towards the desired state. Key results measure progress towards that desired state.

But how do these different concepts map to SAFe’s Operational Value Streams (OVSs) and Development Value Streams (DVSs)? And why should you care?

Changing and Improving the Operation

Like Strategic Themes, most OKRs point to a desired change in business performance. These OKRs would be the ones that company leadership cares about. And they would be advanced through the efforts of a DVS (or multiple ones).

For example, if the business wants to move to a subscription/SaaS model, that’s a change in the operating model-a change in how the OVS looks and operates. That change is supported by the development of new systems and capabilities, which is work that will be accomplished by a DVS (or multiple ones).

This view enables us to recognize the wider application of the DVS concept that we talk about in SAFe 5. Business agility means using Agile and SAFe constructs to develop any sort of change the business needs, regardless of whether that change includes IT or technology.

Whenever we are trying to change our operation, there’s a question about how much variability we’re expecting around this change. Is there more known than unknown? Or vice versa? Are we making this change in an environment of volatility, uncertainty, complexity, and ambiguity? If yes, then using a DVS construct that employs empiricism to seek the right answers to how to achieve the OKR is essential, 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 an Agile and SAFe DVS approach.

These OKRs would then find themselves elaborated and advanced through the backlogs and backlog items in the various ARTs and teams involved in this OKR.

In some cases, an OKR would drive the creation of a focused DVS. This is the culmination of the Organize around Value Lean-Agile SAFe Principle. This is why Strategic Themes and OKRs should be an important consideration when trying to identify value streams and ARTs (in the Value Stream and ART identification workshop). And a significant new theme/OKR should trigger some rethinking of whether the current DVS network is optimally organized to support the new value creation goals set by the organization.

Maintaining the Health of the Operation

As mentioned earlier, maintaining the health of the operation is also tracked through KPIs. Here we expect stability and predictability in performance. It’s crucial work but it’s not what OKRs or Strategic Themes are about.

This work can be simple, complex, or even chaotic depending on the domain. The desire of any organization is to bring its operation under as much control as possible and minimize variability as it makes sense in the business domain. What this means is that in many cases, we don’t need Agile and empiricism in order to actually run the operation. Lean and flow techniques can still be useful to create sustainable, healthy flow (see more in the Organizational Agility competency).

Whenever people working in the OVS switch to improving the OVS (or in other words working on versus in the operation), they are, in essence, moving over implicitly to a DVS.

Some organizations make this duality explicit by creating a DVS that involves a combination of people who spend some of their time in the OVS and some of their time working on it together with people who are focused on working on the OVS. For example, an orthopedic clinic network in New England created a DVS comprising clinicians, doctors, PAs, and billing managers (that work the majority of their time in the OVS) together with IT professionals. Major improvements to the OVS happen in this DVS.

Improving the Development Value Stream

The DVS needs to relentlessly improve and learn as well. Examples of OKRs in this space could be: improving time-to-market, as measured by improved flow time or by improving the predictability of business value delivered, as measured by improved flow predictability. It could also be: organize around value, measured by the number of dependencies and the reduction in the number of Solution Trains required.

This is also where the SAFe transformation or Agile journey lives. There are ways to improve DVSs or the overall network of DVSs, creating a much-improved business capability to enhance its operation and advance business OKRs.

Implementing OKRs in this space relates more to enablers in the SAFe backlogs than to features or capabilities. Again, these OKRs change the way the DVS works.

Running the Development Value Stream

Similar metrics can be used as KPIs that help maintain the health of the DVS on an ongoing basis. For example, if technical debt is currently under control, a KPI monitoring it might suffice and hopefully will help avoid a major technical debt crisis. If we weren’t diligent enough to avoid the crisis, an objective could be put in place to significantly reduce the amount of technical debt. Achieving a certain threshold for a tech debt KPI could serve as a key result (KR) for this objective. Once it’s achieved, we might leave the tech debt KPI in place to maintain health.

It’s like continuing to monitor your weight after you’ve gone on a serious diet. During the diet, you have an objective of achieving a healthy weight with a KR tracking BMI and aiming to get below 25. After achieving your objective, you continue to track your BMI as a KPI.

Taking Action to Advance Your Implementation Using OKRs

In this blog post, we explored the relationship between operational and development value streams and the Strategic Themes and OKRs. We’ve seen OVS KPIs and OKRs as well as DVS OKRs and KPIs.

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

Start by reviewing your OKRs and KPIs and categorize them according to OVS/DVS/Change/Run.

You can use the matrix below.

This process can also be used in a Value Stream Identification workshop for the initial design of the implementation or whenever you want to inspect and adapt it.

Find me on LinkedIn to learn more about making these connections in your SAFe context via an OKR workshop.

Originally published at https://scaledagile.com on December 1, 2021.

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.

INVEST in effective SAFe PI Objectives

INVEST in effective SAFe PI Objectives

Could the INVEST criteria Bill Wake came up with for evaluating User Stories help us come up with effective PI Objectives in SAFe as well?

I think a good PI Objective should be:

– Independent — meaning ideally it could be delivered and evaluated on its own without any dependency on other PI Objectives. And if a team is able to own a PI Objective and delivery it on their own — it’s a sign that it’s a cross-functional autonomous team.

– Negotiable — meaning that we keep the details of the HOW open. The team commits to the WHAT and will figure out the HOW along the way based on what they learn. This relates to “Assume Variability, Preserve Options” which is a crucial but sometimes ignored principle in SAFe.

– Valuable — in the eyes of the business owners. At a minimum, a good PI Objective should be UNDERSTOOD by business owners of the Agile Release Train. Even if it is about enabling a future outcome rather than delivering it directly.

– Estimatable — In order to figure out if the objective is realistic and can be delivered in the upcoming PI, the team should be able to estimate what it might entail

– Small (Or Sized appropriately) — In this context Small means sized to fit into a PI

– Testable — can we test that we actually achieved this objective? How would we know what to give it as an “Actual Business Value”? This is where things like “Key Results” (Think OKRs) can help us make a PI Objective more concrete.

So what do you think? Is the INVEST criteria useful for PI Objectives?

Exit mobile version