I encourage all readers to check out the SAFe® guidance article on the subject before
reading this article. SAFe® and Scaled Agile Framework® are registered trademarks of 
Scaled Agile Inc. Last Updated: Saturday, September 22, 2018

An aside about Business Value & Reflection

Some SAFe® acronyms defined:
Epic Owner (EO), Business Owner (BO), Product Owner (PO), Product Manager(PM), Lean Portfolio Management (LPfM), Scrum master (SM), Release/Solution Train Engineer (RTE/STE), Solution Management (SMg), Business Value (BV), Story Points (SP)

---

Introduction of Business Value in a SAFe Implementation

We have to understand what business value is before we can explore the nuances of PI Planning and Program Execution in the SAFe. This is important because I have observed anti-patterns of gaming the system. The concept and body of knowledge are sound, but the mental models’ teams adapt when using business value are defective in a way that shows a misunderstanding of intent.

If I had to describe Business Value in SAFe with just one word, I would choose the word ‘trust.’ If we were to further explore ways to understand “business value” we could use words like ‘alignment‘ and ‘collaboration.’ We could easily argue to include all of the core values of SAFe and the Agile Manifesto, but for argument’s sake let us stick with the three points. The Agile Release Train (ART), or team of teams, hypothesizes business value in the form of objectives at PI Planning by collaborating to build alignment in the team of teams. The effectiveness of the business outcome of our collaboration and alignment either builds trust, or it destroys it. This is what the SAFe refers to as ‘predictability.’ An indicator of in or out of control development. But is predictability a strong or deep enough way to describe the intent?

The way in which we objectively communicate the results of our experience (as an ART) in terms of business outcomes is business value and Program Predictability Measure (PPM). In other words, at the Inspect & Adapt event at the end of the PI boundary the teams and more importantly, the ART, are essentially given a Trust Score. Trust is critically important in the value systems we use in SAFe, the Agile Manifesto, and Lean thinking. Without trust, teams (or organizations) never achieve a high-performance state. Trust itself describes a previous outcome, not an input.

In psychology, trust is believing that the person who is trusted will do what is expected. – wikipedia

I believe that thinking about the business outcomes of an ART in terms of trust bears more fruit than thinking in terms of value. I believe there is a tendency of human factors to equate value with monetary or score value. This is the wrong thinking and coaching should drive trustworthy behavior rather than the achievement of a monetary award or winning a game.

Business Value Reflection

Note: I'm still on the fence as to whether or not this concept holds water. It was originally written to answer a question related to an anti-pattern.YMMV.

In a given SAFe® implementation, a long-lived ART should come to a state where Business Value (BV) is reflective, but not necessarily equal to in any way, of normalized story points (or of the number of normalized items for you #notestimates folks) at the team level. In Tuckman’s stages of group development, this indicates the team of teams is normalized or high performing. In other words, the objective measure is verifiable through attribution to the value delivery and related to a predictable and accurate, but not specific, estimating function/process.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” – the Agile Manifesto principle #3.

Why is this principle insufficient (in one way)? Working software does not automatically equate to valuable software. As in the expected value (intent) the customer wanted to receive. Since we work with customer proxies in Lean-Agile practices we need to have a way to objectively measure value (even if we work with the actual customer too, but that’s nearly impossible as we’ll explore in another article). The measure must also be validated. We can’t assume that the SAFe method of objective measure with BV is valid as implemented in each unique situation.

This is a critical notion because the Business Owners (BO) and product owner/management (POPM) (and other stakeholders) functions should be constantly working together with the ART(s) to improve the predictability of product development, quality, and delivery (release on demand). There needs to be a mechanism in place between the ART and the LPfM/BO/POPM functions to objectively measure the outcomes of the team of teams during a Program Increment (PI). This helps focus management and executives on successful outcomes and value rather than how many features or story points teams completed. Or worse, how many hours were spent on tasks or wishful thinking dates from the planning fallacy.

We should be organizationally focused on value delivery and successful outcomes as priorities over other traditional ways of measuring performance.

 

Portfolio Management

In consideration of portfolio management as a critical function of any enterprise product and/or service provider. Executives, EO‘s, LPM‘s, System Architects, BO, POPM, RTE/STE, SMg, and Teams of teams (traditional portfolio management, requirements analysts, program/project management, business office functions) need to be able to estimate quickly and accurately during the intake processing of new work (business office/sales/contracts/business/epics/new features, etc.). Estimates by definition are not specific but must have controls in place to be predictable, or accurate.

Hey, over here! We do the work. You know, the “teams”

Teams should always be involved in estimation, but may not have the capacity to do so in every case for all quotes and ROMs. In many organizations, the teams that do the work are never involved in the first pass of estimating. To the detriment of the organization.

Developing an accurate estimating mechanism (a tool with a process plus people; ITSM and a service catalog?) for ROM’s/quotes is paramount to successful LPfM in the SAFe. Look for an article in the future about how we tackled that problem with one of my clients. In my observation of many organizations this process is broken, and/or extremely laborious, and usually very inaccurate even though it was specific.

How many times have you seen the goal posts moved on a “project” to make the organization/company look good/better/as less bad as possible? How many times have you seen a “project plan” copied and pasted with a few labels changed? Out of touch PM’s or managers performing the planning fallacy to forecast cost/schedule/scope?

 

Scaled Agile Framework on Business Value:

During PI planning, teams set team PI objectives, which provide many benefits:

• Provide a common language for communication between business and technology
• Align teams to each other and to a common mission
• Create the near-term vision, which teams can rally around and develop during the PI
• Provide an important Metric, the Program Predictability Measure, that the team and Agile Release Train can use to improve performance
• Communicate with management and highlight each team’s contribution to business value
• Expose dependencies between teams that must be addressed for system success

Read more at: http://www.scaledagileframework.com/pi-objectives/
Copyright © 2010-2017 Scaled Agile, Inc.

Normalization of estimating (in story points and business value) on long-lived teams (Epic Owners, Lean Portfolio Management, BO,  POPM, & ARTs) should occur over time. A pattern should develop that is useful for capacity planning and management of outcomes across ARTs. This is where the Program Predictability Measure (PPM) is used as an objective measure of outcomes for an ART and the teams that are the train. It [PPM] is the measure of alignment between the ART and the other roles playing a part in product development.

Think of BV and normalized story points as checks and balances for each other between BO, POPM, and Teams on an ART. Teams using relative estimating techniques like planning poker, white elephant or fast story estimating in story points…should have a mean (velocity) that develops over time, on long-lived teams. Likewise for long-lived BO’s working on assessing planned and achieved BV for an ARTs PI Objectives. This way, deviations can be more easily identified and root-caused for problem-solving. Metrics should be created to measure standard deviation (SD) and a team rule identified to document what is done when the SD for BV is exceeded (aka, out of the 80 – 100% target in control band).

Using this built-in mechanism in the SAFe is critical for the organization to tie together portfolio management to the production machine. Without it, there is no woman in the middle communicating and managing the inputs and outcomes to determine whether success was achieved. Often, the simplicity of the process itself identifies numerous unknown dependencies. Also, I have observed executives and management becoming much (significantly) more aware of the inner workings of the organization when collaborating with teams in this way of working.

Validating SAFe BV

It is unacceptable to assume SAFe business value measurement is functioning properly without having a mechanism in place to validate (really need some depth in the method that is connected to the economic decision-making framework). I’ll hazard a generalization and state that in most cases Business Owners (and their LeSS/XScale/DSDM/SoS/Nexus equivalents) are almost always proxies for the actual customer. At least when performing the value measurement function. Also, in most cases, the actual customer or a proxy customer of the customer organization will not be available to perform the BO function of assessing value at PI Planning and attributing value at Inspect & Adapt.

Controls/Sensors/Measurements and governance must be created to perform validation of the ART’s business value production. We can easily create delusional BV assessments by having internal BO’s attributing value from a silo. If we consider a vanilla Scrum team in an enterprise context it is also very easy for the team to create self-fulfilling prophecies if the PO isn’t truly connected to the actual customer using the product/service.

Internal and External Measurement

Organizations using SAFe as guidance for their way of working on the path to true innovation are strongly encouraged to measure business value produced by the product development social structures known as ARTs. Internally this can be accomplished by creating recursive feedback loops that attribute feature level story point estimates (multi-source and multi-pass) AND PI Objective business value planned/actual back to the first pass estimating functions in the LPfM process. The feedback is used to accurize the estimating functions at the portfolio level. YMMV organizationally as the specifics will depend on your process and tooling. Create improvement actions (stories?) to continuously observe, orient, decide and act (or PDCA) from the feedback to correct the first pass estimating process. What the heck does that all mean? Let’s simplify.

The Business Office in an enterprise will ALWAYS need a quick way to communicate with customers on estimates. Regardless of what the Lean-Agile pseudo-thought leaders, consultant, snake oil salesman and their Lean-Agile framework nirvana predict, reality will always win. So rather than failing and flailing while grasping at straws we should acknowledge business context and create systems that are as “Lean” as possible while being Agile. Then run experiments, remove muda, and repeat. The SAFe provides a good mechanism from which to start building a lean portfolio function in your organization.

Ideally, every time a customer asks how much something costs they can get a specific and/or accurate price or estimate instantly.

Where complexity is low and certainty is very high businesses can be very specific – think about your grocery store – the actual, specific prices are labeled right there on the shelf edge or stuck to a label on the box. It’s non-negotiable. A loaf of bread isn’t priced as “EST. ~$3.50 depending on whether or not some of the slices are delivered to the register.”

Conversely, where complexity is high and/or certainty is very low businesses are less motivated to commit to specificity (even though many do at their own peril). In this case, consider automakers that are learning how to mass produce reasonably priced electric cars (none exist to date) that are self-driving (none exist to date). Complexity is high because of the power density requirements of the battery system and the fact that the infrastructure and laws to support these type of vehicles are woefully inadequate. Certainty is very low because no one really knows when governments and the culture will accept electric or self-driving electric vehicles. The automakers respond by pricing the product “accurately.” Internally, they are not really sure how much R&D will be required so they raise prices and also pay lobbyists to get the government to subsidize the cars to cover uncertainty.

This is where the Stacey Matrix and the socially inept, but intelligent, curmudgeon Dave Snowden’s Cynefin Framework are case studies on how we can make better decisions. It’s also core as to why organizations need to invest in Lean and Agile. Good decisions require quality data.

Internal measurement can be corrected by tapping into the actual business outcomes and objectively measuring through KPI’s, metrics and results. The iron triangle is still somewhat useful. Measure schedule (fixed in Agle), cost (fixed in Agile), and scope (variable in Agile). SAFe BV can be corrected recursively with internal measurement by tweaking the LPfM estimating functions. Facilitate problem-solving workshops with the LPfM, POPM, and BO role/teams to look at first pass estimates vs. actual outcomes. Create improvement stories for affected functions to correct bad behavior (not following the process), poor assumptions (I didn’t know we needed to test), system bottlenecks/flaws (systems thinking/Lean), or other causes. If this is done consistently, the business office should be able to consistently and accurately estimate work with minimal touch to the people who are doing the work. Keep in mind that the LPfM functions should *always* collaborate with the ART on estimates. ARTs should reserve capacity for this work.

External Validation

Externally the organization should also create controls and feedback loops with the actual customer, not just the proxies. The challenge in an enterprise is that most often the actual customer is thousands of people. How do you get the individual opinions and feedback from hundreds or thousands?

The opinions of the executive approving a PR are of far less value compared to the opinions and value assessment of the people actually using the product. Often, executives are not in sync with the users of products and services. So don’t fall into the trap of trusting the executive’s opinion and the fact that your invoice was paid as validation that value was delivered.

This can be done through surveys. NPS is a common tool to gauge value delivery and customer loyalty (you gain loyalty by delivering real value). Using data analytics and usage patterns to produce metrics to measure value is also another option.

Remember to tie in the complete feedback loop to the system. Internal and external metrics are completely useless if they never cause a change in the product development and delivery system.

Simply put, measure the measurements or risk creating a fictional organization (see feedback markers, OrgMindset).