Unleash your ART with the right Business Owners

For years, I wondered why Dean Leffingwell had to use another name for stakeholders with the "Business Owner" construct in SAFe.   My description in training used to run "an ART will have many stakeholders, but somewhere will be the 4-6 whose support is critical to your success - they're your Business Owners".

At some point it dawned on me.  If you consider the size of investment involved in running an Agile Release Train, under any legacy delivery model there would have been some form of executive steering committee.  Through this lens, you are offering the ART Business Owner construct as a Lean|Agile alternative to the traditional steering committee.

I have been rewarded by deliberate focus on formalizing the Business Owner construct.  It has unlocked one of the key decentralization puzzles I have encountered in my years with SAFe.  At some point in the journey of envisioning an ART, you are looking for a Product Manager.  A single person with a huge amount of delegated responsibility as the strategic voice of the customer.  Finding that one person the enterprise agrees can effectively represent all the competing interests for the ART's strategy and capacity can be almost impossible.  The problem also rears its head for the Release Train Engineer (RTE).  Most ARTs will be working on multiple strategic assets with a diverse ownership throughout the IT organisation - owners who often have significant concerns about others working on their platforms.

I have come to think of the RTE and Product Manager as empowered delegates of the Business Owners for the ART.  The Business Owners are then collectively accountable for rapid response to any decision escalated to them.  When these 2 layers of leadership operate effectively together, magic happens.

When and How to select Business Owners

The journey of an ART begins with leadership training and a vision workshop.  We are looking for a group of leaders and stakeholders collectively aligned in their understanding of the framework and with a shared vision for what the ART will be.

It is ideal for Business Owners to be a part of this early journey, so the time to map candidate business owners is when you're determining the attendees for the Leading SAFe and the vision workshop.

When selecting business owner candidates, an overall stakeholder map can be a useful input.  You need 2 types of representative:

• Business Stakeholders
• The owners of the operational value stream(s) the ART will service
• Stakeholders with policy, regulatory or other assurance concerns in relation to the ART's mission
• Owners of funding (if not covered above)
• Technology Stakeholders
• Designated owners of Strategic Technology Assets the ART will impact
• Line Managers of staff the ART is likely to recruit

What level executive?

If you look too junior for your Business Owners, they won't have the teeth to fulfil their mission.  Conversely, looking too senior will give you authority but is unlikely to yield the time commitments you will be pursuing.

Whilst most organisations have their own leadership hierarchy, I find the sweet spot in large organisations is "the most junior level still considered to be an executive" - just above the line where senior middle management begins.  Considering this to be a "level one exec", I take one extra step - find the level 2 exec in that area and seek a nominated delegate.

How many do I want?

There is no set answer to how many Business Owners an ART should have, but I have some rules of thumb based on experience.  A number of times two were nominated - the Business Sponsor and the Technology Owner.  These struggled, partially due to a lack of diversity of voice and nearly always because the Business Sponsor had numerous peers who had interests they did not feel the sponsor adequately represented.

So, I worry if I see less than 4 Business Owners.  On the other hand, too many is also a huge problem.  It's incredibly difficult to reach and maintain alignment and move on critical decisions with a large and unfocused group.  I once had the misfortune of trying to facilitate an ART vision workshop with 30 candidate Business Owners and convergence was near impossible.

You want enough to be appropriately representative (usually at least 4) and not so many you'll struggle to make decisions (usually painful to move beyond 8-10).
 

The importance of setting expectations

Your prospective executive business owners need to understand what comes with the job.  As a collective the organisation is making them accountable for fiscal oversight and executive championing of the ART's mission.

They will attend and actively participate in a number of SAFe events, with a not inconsiderable accompanying time investment.  They will be needed for at least the following:

• Participation in the ART vision workshop
• Participation in the Program Backlog prioritisation workshop(s) each PI
• Attendance at PI planning, validation and acceptance of objectives and participation in the management review
• Attendance at System Demos (as part of their oversight obligations)
• Attendance at and participation in Inspect and Adapt
• Periodic participation in governance and escalation workshops with respect to ART performance.
• Being the 'voice of the ART' in their area of the business.

They will need to understand the purpose of each of these, their role, and the ensuing time commitments.

I believe the position of Business Owner on an ART should be formally nominated and accepted, and would go so far as to suggest formalising a Terms of Reference for the Business Owner committee.

Leveraging your Business Owners

The primary times your train and Business Owners will intersect will be through the afore-mentioned SAFe events.   Following are some of the patterns I have found beneficial.

The ART Vision Workshop

Every ART should start with a clear vision, and this is the workshop that first crystalizes it (documented here).  Agreement is reached on Customers, Success Measures, Vision Statements and the nature of the solution to be built and the business owner roles are confirmed.  As the executive owners of the ART, it is critical not only that the business owners have a voice in shaping the vision but that clarity and alignment is reached on how the ART's success will be measured.

Program Backlog Prioritisation Workshops 

In preparation for this workshop, the Product Manager has been decomposing Epics, talking to customers, and reflecting on learning from shipped features to identify and shape a set of candidate features to add to the Program Backlog.  Each feature has a value proposition, and in SAFe we use  a contextualised Cost of Delay (COD) estimation and the Weighted Shortest Job First algorhythm to arrive at economic priorities.

In this workshop, new features are evaluated to determine their COD and existing backlog features where conditions might have changed are re-assessed.  Based on known information about feature value proposition, Business Owners use agile estimation to come into alignment on the cost of delay.  This enables the Product Manager to fulfil their responsibility to maintain an economically prioritised backlog whilst leveraging the diversity and organisational authority of the business owners to make the assessments.

PI Planning

Little needs to be added to existing material in this space.  Business Owners have a critical role to play both interacting with teams on an adhoc basis and in a planned fashion through plan reviews and the management review.   The PI Planning event provides amazing "Gemba time" for executives, with much to be learned by observing and interacting as the teams build their plans.

The event commences with a set of priorities that have been validated and endorsed by the business owners.  By the end of day 1, there will be various challenges to that vision.  Regularly, hard decisions will need to be made, and made on the night.   Management Review provides the forum to revisit their earlier "value proposition discussion" in the light of emerging information and provide rapid response with the same set of authority as drove the initial priorities.

On the second day, the all-important "Business Owner walk-around" occurs.  The Business Owners visit each team and conduct a review and assessment of the PI objectives.  It both establishes direct executive/team engagement and feedback, and permits clarification of objective intent - maximising the chance both the team and their stakeholders leave the room aligned in their commitment expectations.

System Demo

The primary "Execution reporting" vehicle for the ART culturally is the System Demo.  Every 2 weeks, it provides a transparent checkpoint based on demonstrated functionality and linkage back to PI objectives.  It also acts as a platform for feedback.   As implementations are demonstrated, where they differ from the vision of the business owner or expose new challenges or insights this is the forum to both trigger and receive that feedback.

Inspect and Adapt

Business Owners have a role to play in all 3 phases of the Inspect and Adapt workshop.  During the PI Demo, they are gaining an understanding of "what has been achieved" in the PI with reference back to the objectives committed at PI Planning.  During the quantitative measurement phase, they are both reviewing ART PI Metrics and evaluating performance of teams against their committed objectives based on the Demo.

Finally, during the problem solving workshop they provide the all-important executive lens to root cause analysis and brainstorming.  It provides them with invaluable time "at the Gemba", and insights into enabling initiatives that should be prioritised.

Governance

Each of the SAFe events described above qualifies as a governance event.  Collectively, they enable the Business Owners to steer ART strategy, provide rapid decision-making response at key moments in the lifecycle and maintain visibility through System Demos and Inspect and Adapt.

However, it is also typical to establish some form of cadence-based "ART Steering" forum.  In previous versions of SAFe this was known as "Release Management", but I suspect it has receded from visibility in the framework due to confusion over the title.  A monitoring and escalation forum needs to exist for the ART during PI execution.  It is informed by the standard SAFe events, but facilitates monitoring and follow-through of the various risks and issues that emerge.

Enabling

To succeed in mission, the ART will need to collaborate across the organisation - particularly for exploration activities.  Business Owners provide a built-in channel of access to the areas that will typically be critical.  Through their understanding of the focus areas for the ART, they can proactively plan who from their areas should be involved and how.

Conclusion

I have become so convinced of the power of a well-identified, engaged group of Business Owners that it is one of my top priorities when shaping a potential ART these days.  I have found it to be a hugely critical key in unlocking empowerment and ability to move for Product Managers and Release Train Engineers, whilst providing the Business Owners a great sense of comfort in the level of insight and input they have.

Effective Feature Templates for SAFe

Introduction

Features are the key vehicle for value flow in SAFe, yet they are also the source of much confusion amongst those implementing it.  The framework specifies that “Each feature includes a Benefit Hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI)”.

It is obvious that you need a little more information about the feature, and on what feels like countless occasions I have facilitated the definition of a Feature Template with a Product Management group.  People in classes ask me for a sample, and of course the only samples I have belong to my clients and aren’t mine to share.

The new emphasis on Lean UX in SAFe 4.5 finally inspired me to put some time into crafting a Feature Template of my own that I could share.  The result is a synthesis of recurring patterns I have observed in my coaching, and focuses an “essential components” with guidance on additional information that might be required.

How much detail is needed, and by when?

I divide the refinement lifecycle of the Feature into two phases.  

• Prior to WSJF assessment
• Prior to PI Planning

There is a level of detail required for a feature to enable Cost of Delay and sizing assessment.  Information is inventory, and we want a lightweight holding pattern until the Feature’s priorities indicate it as needing to be prepared for PI planning.

To this end, my template focuses on taking a canvas approach to supporting WSJF assessment, and I provide some guidance on likely extensions of detail in readiness for PI Planning.

Feature Canvas

Problem Statement

Leveraging the work of Jeff Gothelf in Lean UX, we base the feature on a definition of the problem it is designed to address.  Gothelf provides two excellent template statements here:

New Product:
“The current state of the [domain] has focussed primarily on [customer segments, pain points, etc].
What existing products/services fail to address is [this gap]
Our product/service will address this gap by [vision/strategy]
Our initial focus will be [this segment]”

Existing Product:
“Our [service/product] is intended to achieve [these goals].
We have observed that the [product/service] isn’t meeting [these goals] which is causing [this adverse effect] to our business.
How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?”

Feature Hypothesis

Again, leveraging Gothelf’s work we form a hypothesis as to the impact our Feature might achieve.  The template takes the form:

“We believe this [business outcome] will be achieved if [these users] successfully achieve [this user outcome] with [this feature]”.

Objectives and Key Results (OKRs)

Features are intended to provide verifiable impact, this detail is critical to enabling effective Cost of Delay estimation and the post-deployment verification of impact.  We want to ensure that quantifiable movement of identified Leading Indicators supports the ongoing evolution of our Product Management strategy.

As previously documented in this post, I have become quite a fan of the OKR model initiated at Intel and popularized by Google and find this a useful discipline in defining feature impacts.  

If OKRs seem a little daunting, you would instead list Leading Indicators and expected movements in this section.

Cost of Delay Components

The effectiveness/objectivity of Cost of Delay estimation workshops is heavily driven by the data on the table.  The 3 sections for User/Business Value, Timing Criticality and Risk Reduction/Opportunity Enablement provide opportunity to highlight supporting data for the assessment of the three cost of delay components.

Key Subject Matter experts

I rarely if ever work with an ART where Product Management is self-sufficient with their domain expertise.  Deliberate identification of and engagement with subject matter experts early in the lifecycle of a feature is critical.

External Dependencies

Nothing brings a feature unstuck faster than unidentified external dependencies.  These should be flushed early, and inform prioritization and roadmapping discussions.

Non Functional Requirements

We know that an ART will have a standing set of non functional requirements that applies to all features, but occasionally features come with specific NFR’s.  

Sample Completed Canvas

It was incredibly difficult to invent a sample feature because my head kept running to real features, but eventually I settled on a fictitious feature for restaurant reservations.

A glimpse at how you might visualise your next WSJF estimation workshop

Detail beyond the Canvas

As a feature is selected as a candidate for an upcoming PI, it triggers the collection of additional framing detail.  How much or how little detail is appropriate tends to vary ART by ART and at different stages in their evolution.  

At a minimum, it will require acceptance criteria.  However, some other things to consider would include:

• User Journeys:  Some framing UX exploration is often very useful in preparing a Feature, and makes a great support to teams during PI planning.  
• Architectural Impact Assessment: Some form of deliberate architectural consideration of the potential impact of the feature is critical in most complex environments.  It should rarely be more than a page – I find a common approach is one to two paragraphs of text accompanied by a high level sequence diagram identifying expected interactions between architectural layers.
• Change Management Impacts: How do we get from deployed software to realised value?  Who will need training?  Are Work Instructions required?  

Tuning your Template

Virtually every ART I have worked with has oscillated between “too much up-front information” and “not enough up-front information”.  You want to know enough to enable teams and product owners to effectively plan and execute iteratively, yet not so much that you constrain the opportunity for teams and product owners to innovate and take ownership of their interpretation.

Every PI is a learning opportunity.  Take stock a week after PI planning and look at both the information you wished you’d had, and your observations as to the value proposition of the information you had provided.  

Then, take stock again late in the PI.  Look at how the features played out over the PI, and the moments you wish you could have avoided 😊  

Who completes the Canvas/Template?

The Product Manager is the content authority at the Program Backlog level, hence they are the ultimate owners.  However, one of the nice influences Lean UX has brought to SAFe 4.5 is a real emphasis of “collaborative design”.   In avoiding the waste of knowledge handoff, the best people to work through the majority of the detail (including preparing the canvas itself) are the product owners and teams likely to be implementing the feature.