Effective Change Control "by Release" in SAFe

“Control by Release … Control by turning loose within well-understood parameters.  Control by trusting the process.  This doesn’t mean anything goes” – Artful Making, Rob Austin and Lee Devin

Under a “traditional” delivery model, organizations employ a combination of gating and detailed scope, cost and timeline commitments to facilitate governance, change control and executive oversight of strategic product spend. 

With SAFe, the move to Lean Budgeting and outcome-based metrics enables the elimination of much of the overhead and inefficiency inherent in the traditional approach.  SAFe 4.6 crystallized this with the introduction of the four Portfolio Guardrails:

1. Guiding investments by horizon
2. Optimizing value and solution integrity with capacity allocation
3. Approving Significant initiatives
4. Continuous Business Owner engagement

The opening quote is from one of the books that profoundly influenced me early in my Agile career – Artful Making.  The notion of “Control by Release” has been a core component of my coaching toolkit for many years, particularly in the context of decentralization.  In this post, I will explore the “Control by Release” aspect of each guardrail as we determine “what to do” then move beyond into the tools that help us during PI execution while we “are doing”.

Guiding Investments by Horizon

This guardrail controls the percentage of investment capacity that can be consumed by a particular horizon of investment idea.  “Release” is achieved by not constraining the ideas under consideration, but "control" ensures innovative horizon 3 and “coming attraction” horizon 2 ideas are not drowned out by the all-consuming “demand of today” in horizon 1.
 
Horizon allocation authority often exceeds the remit of the Portfolio itself, requiring validation at the enterprise level – particularly given the high-risk nature of horizon 3 investments.  However, once established it releases the Portfolio team to more futuristic investments within the agreed constraint.

Optimizing value and solution integrity with capacity allocation

Another percentage-based control tool, this is typically applied more at the Solution and Program levels.  A classic scenario is B2B digital products – often stuck in the following dilemma:

• “Without the B2B providers we can’t attract B2C consumers” 
• “Without B2C consumers we can’t sign up the  B2B providers”.  

This is a level well above “what feature should we build” – it’s a strategic tool.  “For the next 2 PI’s, we want to invest heavily in the B2B space with 70% of our capacity”.  We thus achieve "control" by specifying the percentage of ART capacity to be consumed by B2B features and "release" by the fact we have not actually talked about what B2B features should be considered. 

This decision is often not within the remit of Product Management.  It will need validation by their Business Owners, Portfolio Management or some combination of the two – but once set they are released to find the best features to use that capacity for.

Approving Significant Initiatives

The Product Manager for an ART has significant remit when it comes to feature selection.  In mature SAFe most features built are independent features identified in service of product strategy rather than derived from Epics.  The Product Manager is empowered to identify Features and facilitate their prioritization (through WSJF), but accountable for the economic outcomes achieved by the ART justifying the spend.  There is a level of safety and control in this as we know that the Feature should have a quantifiable, rapidly measurable benefit and has to be small – small enough to fit in a single PI for a single ART. 

However, what happens when the Product Manager encounters a big idea – something too big to be a Feature - an Epic.  This attracts more due diligence, approval and monitoring at the Portfolio level.  “Before you start down this path, we need to validate it.” 

The Product Manager is “released” to pursue a range of small valuable investments, but works within the “control” that if the investment passes a certain threshold higher authorities must become involved. 

Continuous Business Owner Engagement

Late last year I dedicated a whole post to this.  How do we “release” the Product Manager to do the job they’ve been appointed to do?  By providing the “control” of engagement with executive business owners for involvement in moments where key constraints are established.

There are 4 clearly defined “control” events for this in SAFe:

• Business Owners collaborate to define the Cost of Delay for candidate Features and thus “control” the priorities whilst having “released” the Product Manager to find features to present for prioritization.
• Business Owners collaborate to “control” tradeoff decisions during Management Review at PI planning whilst having “released” the teams to identify the tradeoffs required, then accept the committed objectives to establish a “control” around commitment expectations for the PI.
• The System Demo (attended by the Business Owners) demonstrates progress in the previous iteration, and should illustrate alignment to the agreement reached at PI planning.
• The PI Demo where achieved outcomes are assessed against committed objectives by the Business Owners

Beyond Portfolio Guardrails

Each of the guardrails provides controls on what we choose to do, at varying levels of seniority, regularity and granularity.  However, what happens once we are “doing?”  Or, in more traditional language “how do we apply change control during execution?”.
 
The “hippy agilist” inside me gets nervous about tackling the second half of this post.  Surely I’m not going to start talking about the dreaded “change request”.    What about Agile principle 2 – “Welcome changing requirements, even late in development”?  Unfortunately, I have probably seen this principle abused more than any other (albeit, the sustainable pace of principle 8 is definitely the most commonly ignored – typically in the context of abuse of principle 2).  All too often, it is interpreted as “I thought this was agile and I could change my mind anytime I liked” without accepting that the change might impact cost, timeframe or other commitments.

So, how do we enable the “release” to embrace changing requirements whilst maintaining the “control” to ensure this occurs in a responsible fashion?

Establishing Guardrails for ART execution

We have the hints for these controls from the Portfolio.  A decision-making framework must address the following:

• At what point does a Team need to escalate a decision or notification to the Program level?
• At what point does an ART need to escalate a decision or notification to their Business Owners?

The answer in both cases lies in the controls we have established:

• Committed PI Objectives
• Capacity Allocation

Both have been validated and accepted by the Business Owners.  The ART has been “released” to make any change it likes within these controls.  For example, it has pre-agreed with the Business Owners that if the PI runs into challenges the stretch objectives can be sacrificed without consultation.  However, to examine some example “control triggers”:

Capacity Allocation for BAU

The application of capacity allocation to BAU/Unplanned work was explored in detail in my recent post on BAU and Unplanned work, but to illustrate a change control example:

• A team was given a capacity allocation of 10% for BAU/Unplanned work
• The Product Owner is now “released” to prioritize any stories they feel are important (be it minor enhancements, tech debt remediation or minor production defect fixes) so long as they fall within 10% of the team’s capacity each iteration.
• In the event that BAU and Unplanned work threatens to exceed the capacity constraint (eg a string of urgent minor enhancement requests from a noisy stakeholder), we trigger the “control”.  It’s no longer a team decision, and must be escalated to Program Level.
• At the Program Level, there may be a “System-level” solution to it that can still be constrained to the ART.  For instance, redirecting some of the work to another team or sacrificing a stretch objective due to the importance of the unplanned work.
• If there is no ART-level solution that doesn’t compromise committed objectives and the Program Team cannot politically refuse the BAU work, it must be escalated to the Business Owners to make the decision: “Are we willing to sacrifice a strategic committed objective for this unplanned work or will we exercise our executive authority to defer the unplanned work?”

Significant change in Committed Objective

We know that teams don’t commit to delivering either their plans or their stories at PI Planning – they commit to achieving their committed objectives.  The stories and plans constitute a current belief as to the best way to achieve the objectives.  There’s more to this story than meets the eye though:

• Whilst objectives are meant to be “SMART”, they rarely are.  This leaves interpretation very much open, and its easy for a Product Owner to wind up in a world of pain with subject matter experts, stakeholders and product managers arguing that there is implicit scope in the objective that the team never planned for.
• The objectives are “in a system context”.  Business Owners accept “the overall objectives for the ART”, and make tradeoff decisions to optimize the whole rather than the parts.  Implicit in the process of arriving at this is that the team’s plan reflects the rough percentage of the team or ART capacity that will be consumed achieving the objective.  (ie In the plan, there were 78 points of estimated stories associated with it).  We know estimates are guesses, but if we are suddenly dealing with 150 points of stories there is no doubt we are in a world of pain.  This could occur due to ugly surprises, missed stories, or interpretation arguments but however it happens there’s no doubt we’re in pain.  Whether it’s caused by dysfunction between the Product Owner and Team, Product Owner and Product Manager, or Product Owner and Stakeholder this objective may compromise a number of others.

A common technique is to establish a “size threshold” type control.  For example, in the event that the total estimated size for the Feature varies by more than 20% from that established at PI planning, it should be escalated to Program Level for review.  Often, it can be solved at the Program Level through effective tradeoff decisions (by resetting expectations, swinging other teams to the rescue or sacrificing stretch objectives).  However, if it cannot be resolved we’re now in a position where following through on one committed objective compromises one or more others – and that’s a Business Owner decision.  Once again, it should be escalated.  They may lend their executive support to downscoping the work, or elect to sacrifice another objective to support it continuing in its inflated state.

An objective cannot be met.  

This seems to happen most often due to an issue with an external dependency (eg delayed infrastructure, rejection of design by ARB).  As soon as the ART is aware that an objective cannot be met, this must be escalated to the Business Owners.  Notwithstanding the importance of transparency, its quite possible that they can swing their executive weight behind moving the blockage.

Conclusion

If I had read this post 10 years ago, my response would have been “that’s far too structured to be agile”.   My views have become a little less simplistic over the years as I’ve worked with large organizations and government agencies who need evidence of documented controls in place and are looking for “simpler, less wasteful, but still responsible”.

But, to be honest, what motivates me most to address it is helping “teams in pain”.  I’ve worked with a number of ARTs in recent years who have struggled massively with achieving 50% “Release Predictability” let alone 80% even with obscene levels of overtime.   There are numerous contributing issues, but uncontrolled scope creep is a recurring culprit.  Teams trying to collaborate with their Product Owners accept too much change with the Product Owners bright new ideas.  Product Owners struggle to push back when their Product Manager keeps reinterpreting the goalposts of their Features thanks to fuzzy PI objectives and absent/incomplete Feature Acceptance Criteria.   Product Owners struggle to say no when senior stakeholders come up with great ideas.  It’s not fun, and teams enjoy neither the overtime pressure nor the feeling of failure when they miss their objectives time after time.
 
The truth is, every change involves a decision and every decision is a tradeoff decision.   A team will make a trade-off that leads to team-level optimization, a Program Team will make a trade-off that leads to ART-level optimization, and Business Owners will optimize still more broadly.  Good backlog discipline and effective leveraging of the controls built into SAFe enable the right trade-offs to be made at the right level at the right time, and satisfy the auditors that effective controls are in place!