Category: SAFe

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 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…

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?

How Vendors Can Apply Customer Centricity When Organizing Around Value

A lot of our clients are technology vendors that struggle to use the SAFe Operational Value Streams “out of the box”. Here, I explore how such a B2B vendor should organize around value when building products that are used to support its customer’s business operations.

This article was originally posted in the Scaled Agile blog.

Organizing Around Value

Lots of organizations are organized around functional silos — such as business, system engineering, hardware, software, testing/QA, and operations. These structures exist because they support specialization and allow organizations to grow and manage their people effectively. It’s why so many organizations are set up in this way. And many organizations persist in this siloed structure even when they start their journey toward business agility.

For example, they create Agile teams that map to specialized components or subsystems. Similarly, they create Agile Release Trains around entire departments or functions. From a change management perspective, it’s easier to keep the current structure and apply Agile ways of working on top of it. But value doesn’t flow in silos. In many cases, these so-called Agile teams or teams of teams struggle to deliver valuable increments because what’s valuable requires collaboration across the silos. Additionally, teams struggle to see how their work builds up to something valuable for the customer.

Business agility and digital transformation are all about speed of learning and value creation in the face of a dynamic changing environment. The classic organizational structure isn’t optimized for this speed, which is why SAFe® introduces the value stream network as part of a dual operating system that runs parallel to the organizational hierarchy.

Development and Operational Value Streams

Development value streams (DVSs) are the organizational construct used by SAFe to create this value stream network. DVSs are where the essential activities of defining, implementing, and supporting innovative, digitally enabled solutions occur. Defined correctly, DVSs are able to deliver valuable business solutions on their own with minimal dependencies on other parts of the business.

Alongside the DVSs are Operational Value Streams (OVSs) which describe the steps needed to deliver value to the organization’s customers. Examples might include providing a consumer loan or provisioning a software product. With this in mind, the DVS has one purpose: to create profitable OVSs. They do this either by creating the systems that the OVS relies on to operate effectively or by building the products that the OVS sells. With this in mind, understanding how the work is done in the OVSs helps us understand what value looks like, how it flows from demand to delivery in our context, and how we might organize our DVSs to support this.

What’s the Right Approach to Defining Operational Value Streams?

Identifying the OVS is a relatively straightforward exercise for a technology/development organization trying to organize effectively around the value that the wider organization is delivering to customers. People supporting systems that are used when providing these services (digital or physical) can easily apply customer-centric thinking and identify an OVS oriented around the needs of the real external customer.

It gets tougher to map an OVS when you’re a vendor selling your product/solution for use as part of another organization’s operational activities. A great example is an independent software vendor (ISV). Other examples include vendors building and selling cyber-physical systems such as medical devices and manufacturing equipment.

Consider vendor ACME Corp, which provides banks and financial institutions with banking systems. ACME Corp is building an AI-powered loan underwriting system that will fit into their banking systems portfolio. What OVS should ACME Corp model when considering how it might organize around value?

Many SAFe practitioners would suggest that ACME Corp model an OVS that focuses on how it would market, sell, and operate its solution.

Vendor IT folks supporting systems like CRM and ERP find it a useful way to model the business process they’re supporting. With this OVS in mind, they can make sure they organize around the whole buyer journey. And they can apply systems thinking to explore what features to introduce to the systems supporting this process.

The problem with this approach is that this OVS is mainly from the vendor and buyer journey perspectives. It doesn’t provide any information on how the solution will be used or the kind of work that it will support. An alternative approach is to use the real customer’s experience/journey as the OVS. Basically, take the same perspective that an internal technology organization would when building systems for these customers.

Both the buyer journey OVS and customer-centric journey OVS exist. The question is: which of them is more useful to focus on? Remember that we map OVSs in order to build a hypothesis around what’s an effective DVS. In this example, both OVS perspectives can be useful.

The customer-centric fulfillment OVS focusing on the solution context within which the ISVs product lives is the perspective that product development/engineering should focus on — this is where the systems/products/solutions that they create exist. This perspective would be more relevant to people building the products the vendor is selling because it would get them closer to their customers. It would also help them apply systems thinking to which features can really support generating value for these customers and for the enterprise serving these customers.

When to use which modeling approach

Emphasize Customer Centricity as Part of Value Stream Identification

The example above illustrates why vendors can find it daunting to figure out which OVS to focus on. Going down the software product OVS perspective often leads to confusion and lack of guidance because it’s disconnected from how the products are used and from the solution context. A common move vendors make at this point is to fall back to organizing around products. Being able to explore, build, deploy, release, and operate/maintain a product can be a significant improvement for some organizations.

The problem with this structure is that it still has silos. And once we look at the value the vendor is trying to create, we might see a lot of dependencies between these silos. The management challenge is to connect the right silos — those that need to collaborate to deliver the value that the organization’s strategy is pointing toward.

Leveraging customer centricity using the customer’s fulfillment OVS can help the vendor transcend product silos and maximize the value created by their product portfolio. More vendors we work with that started with ARTs and DVSs oriented around products find themselves with heavy coordination overhead across different DVSs and ARTs when executing on strategic themes and portfolio initiatives.

Look beyond one product/system — look for collaborations amongst products

Going back to our AI-powered underwriting product example — This product actually supports multiple steps in the customer-centric OVS, and requires new features across a range of the vendor’s products. Maximizing the value of AI-powered underwriting requires collaboration and coordination with the groups developing these products. If all of these different products are built by different DVSs, this coordination will be slow and painful. If the vendor organizes around value and brings the right people with the ability to get AI-powered underwriting integrated into the different products, time-to-market and quality will be improved. People would also feel more motivated and engaged since they’re very focused and effective.

Using a customer-centric OVS is key to understanding your real solution’s context. This can enable you to organize effectively to minimize dependencies and enable collaborations that streamline the customer journey. Which is essentially the goal of most products — to help a business better serve its customers.

Other benefits of starting from Customer-Centric Operational Value Streams

When a DVS is created to support a customer-centric OVS, the organization can use techniques including value stream mapping and design thinking to innovate “in the Gemba — where the real value flows.” When this DVS includes everyone needed to explore, build, deploy, and support solutions that cut across the customer-centric OVS, we’ve truly created a network operating system that’s organized around value. And we’ve taken a huge step toward enabling real business agility.

There’s also a video available of me teaching the concept of organizing around value. Check it out

Handling scope change during a SAFe Program Increment (PI)

How do we handle Scope Changes in a SAFe Program Increment?

A question about handling scope changes in SAFe was posed recently on a forum I’m participating in (The SAFe Community Forum). This is a question posed regularly in training and on ARTs I’m coaching so I thought I’d provide my thoughts here.

How do you handle a scope change in a program increment? Specifically when it comes to switching one feature for another? And what’s the impact on PI Objectives and Predictability Score?

A lot of people somehow get the notion that SAFe advocates for “limiting/controlling changes during the PI”. The main source of this notion is that we “Plan the Program Increment” and commit to a set of PI Objectives as part of PI Planning.

But remember one of the key SAFe principles is “Assume Variability- Preserve Options”. This applies within a PI as well. While it makes sense to create a baseline plan for the Program Increment, we should also be prepared for adjustments. After all we want to “Welcome changing requirements, even late in development.”, remembering that “Agile processes harness change for the customer’s competitive advantage. “

So let’s say Product Management is considering a change. They have a Feature that wasn’t in the original Program Backlog or was and there’s something that changed about it. Product Management should use WSJF to consider what to do. The Cost of Delay and Job Size of these suggested changes should be compared to Cost of Delay and (remaining) Job Size of existing PI Scope.

And if at this point the WSJF score for the considered change is higher than continuing down the current path then it makes sense to go for the change.

Some people are worried about the Predictability Score — “We would lose points since we won’t tackle some of our planning PI objectives and won’t get credit for them”. Yes some PI objectives won’t be achieved but new objectives should be added or objectives can be changed to align with the changed scope. (Think for example we didn’t manage to hit the “Deploy MS Teams” but we added “Enable all clinicians to provide telehealth meetings using Zoom” as a change made in a PI during the first couple of months of the covid19 pandemic)

Another important question is how do we run a PI in which it is relatively easy to switch some features midway?

We do it by following strong priorities and small batches going into the PI and limiting the number and size of features in progress in early iterations so lower priority Features / PI Objectives are kept as options rather than already started.

The goal is to avoid situations where we want to change direction but there’s already sunk cost since we already started the low priority Feature. We don’t take the sunk cost into consideration when prioritizing, but it will mean that continuing down the planned path will win the WSJF more often. Might be easier for the ART but isn’t necessarily maximizing value delivered.

Even more important than the mechanics of the answer is the mindset. If a question like this comes up — go back to the principles. Lean, Agile, SAFe principles will help you think about the situation and what might be the right systemic way to address it.

Originally published at https://www.agilesparks.com on May 4, 2021.

SAFe Program Dependency Board Retrospective

Learning from the SAFe Program Dependency Board

The SAFe Program Board or Program Dependency Board is a key artifact used in PI Planning and Execution. The ART Teams and Stakeholders used it to align, anticipate risks, and adapt the plan accordingly.

This “inspection and adaptation” of the plan based on insights from the Program Dependency Board is “first loop learning” — making changes in the plan based on what we see.

Deeper Learning from the Program Dependency Board

What we rarely see, though, is deeper learning from what the Program Dependency Board shows us. It’s like the good old times where you would see a project manager / PMO working their MSProject Gantt Chart, moving things around, but rarely stopping to ask deeper questions around the base structure of their plans and why they’re based on a waterfall model.

Program Dependency Boards can drive deeper learning about the structure of our ART and its alignment with the kind of mission/vision we’re pursuing and the backlog of features we’re working on. If we see too much red yarn on our boards it isn’t something to be proud of. Yes, we can be proud that we identified the dependency and even more that we were able to massage our PI plan to deal with it in a reasonable way. But too much red yarn means too many dependencies. Too many dependencies mean our Value Stream Network isn’t configured well. It means we should probably look at ways to reconfigure the network (meaning restructure teams and maybe even the ART).

When to do this deeper learning

I get it. This sort of learning is hard to pursue in the heat of PI Planning. And all too often when PI Planning is done and we have a workable plan in hand its tempting to just move into execution. Resist the temptation. Let the dust settle, but find the time that makes sense to have a deeper retrospective that is based on the patterns you see on the Program Board. This can be a good discussion in your Scrum of Scrums or with an extended forum that includes the wider ART leadership.

There’s no need to wait for the next Inspect and Adapt. It’s fresh now and outcomes from this retrospective might anyhow require a lot of refinement and consideration before they’re actionable. Start the process early in the PI so hopefully, you’ll be in a position to reconfigure the network going into the next PI as needed.

A typical pattern is when such a retrospective raises the need to rerun a Value Stream Identification workshop.

Validating the Value Stream Design Hypothesis — A Key but often Skipped step

Speaking of the VSI workshop — one key element in it that many practitioners skip is the validation of your value stream design hypothesis. After identifying a Development Value Stream, run some water through the pipes — take some work in the form of Features or even higher-level Epics/Themes and explore how they will flow through this value stream/ART/Solution ART. If the work flows nicely with a minimal number of dependencies you found a good setup. If even in this “dry run” you already see you have too many dependencies — time to rework the design!

PI Planning Dry Run

And yes — what this means is that ideally, even in this early phase, before even launching the ART, you should consider doing a light version of PI Planning as a dry run with the value stream design you have in mind — to see that it makes sense. You don’t want to train everybody, spend a serious amount of time on preparing to launch the ART, and then find its not a self-sufficient ART or that it’s comprised of teams that aren’t self-sufficient.

Summary

I’ve talked about some recommended practices here, some are implicitly mentioned in SAFe, some complement the formal guidance. The key point I wanted to make is how important is it to aim for the right value stream network and to continuously inspect and adapt so that value can easily flow with minimal dependencies and slowdowns. And if your value stream network is configured well, everything else becomes much easier.

Originally published at https://www.agilesparks.com on September 17, 2020.

Please don’t come to our Implementing SAFe SPC4 workshops

Seriously, please don’t come.

Don’t come if you’re looking at it as a formality since you already know everything about agile and just need the SPC (SAFe Program Consultant) Certificate.

Don’t come if you’re looking for the cheapest way to get your SPC so that you can add it to your resume.

Don’t come if you don’t know anything about agile and believe the SPC is your silver bullet to becoming an agile coach at the enterprise level.

Don’t come if you’re looking for the certificate rubber stamp.

What we want in our Implementing SAFe classes are participants who :

Are looking to start/continue their Lean/Agile journey. Even coaches practicing agile for 10 years have something to learn and should come curious and willing to explore and take something away.

Know investing 4 of their days is a major investment and it’s more important to get great trainers and experience than saving a couple of $$$. The SPC class or any SAFe class for that matter isn’t a commodity. It matters who’s teaching it. (We try to help people investing in their personal development paying out of pocket but we don’t promise or even try to be the cheapest. we will try to help you take our class if you value taking it from us)

Know what they’re capable and won’t run out of the class, pass the SPC exam and run to teach classes and implement SAFe on their own if they have zero past experience in scaling agile to the enterprise level.

Care about helping their organization or other organizations scale agile in a healthy professional sustainable way and see their SPC as a means towards that end.

Don’t get me wrong — 99% of the people who attend our workshops are the right kind of people. I’m just hoping we are able to keep the wrong people away.

Bottom line — You won’t get far with us if you ask for “50% off on the ticket price since you’re an amazing agile coach already and just need this as a formality”. Just saying.

OK I got that out of the system 🙂 Now I’m ready to go teach a great Implementing SAFe 4.6 w/ SPC4 workshop next week with the right set of people and my colleague and friend SPCT candidate Ofer Cohen!

Exit mobile version