Introducing our new collaboration - Shaping Agility

In 2015, Martin Burns had a vision.  A passionate agilist and early adopter of and advocate for SAFe, he felt strongly that the community needed a way to come together and collaborate to shape the evolution of the framework.  With the help of his wife Lucy and the support of Scaled Agile Inc, he activated this by creating and hosting the first SAFe Leadership Retreat in Crieff, Scotland.  He was seeking “An event that brings experienced leaders together to build the community and creatively take SAFe forward.”  

Given the general application of SAFe in large enterprise and the prevailing ‘partner consultancy’ based model, creating an environment where both consultants and practitioners came together to transcend boundaries and share was no mean feat.  But Martin’s seemingly boundless energy made it a reality.  Forty people gathered for 2 days of unconference and amazing collaboration and friendship building.

Photos courtesy of Phil Gardiner, unofficial Retreat photographer

We regathered in Banff, Canada in 2016 and then returned to Scotland for 3 days in Edinburgh in 2017.  The conversations were rich, the friendships deepened, and the sense of community continued to grow.   The influence on the framework was also tangible – Essential SAFe being a great example of something created in a breakout session entailing an intense discussion about how much you could remove from SAFe without breaking it. 

Sadly, in 2019 Martin passed away and the world lost an amazing human being.  Although the SAFe Leadership Retreat disappeared without Martin’s energy, the community he’d inspired lived on.  At every SAFE Summit, SPCT or Fellows gathering you’d find clusters of people who’d formed community at a Leadership Retreat gathered, sharing in deep conversation, reminiscing on the retreats, lamenting their absence in our lives and talking about how bring it back to life.  

The first post-COVID SAFe Summit in Denver last year was no exception.  One of the retreat buddies I reconnected with was Wolfgang Brandhuber.   He had been doing a lot of work on Large Solution and wanted to share some of his thinking about a structure somewhere between an ART and a Team called a Solution Area.  We found a spare flipchart, and an hour later we’d figured out this was almost identical to what I called an ‘Agile Release Tram’ and agreed that we should leverage the fact COVID had taught us virtual collaboration and keep the discussion going once we got home.  We started weekly calls, and it was fun.  We were back to the types of conversations we used to have time for at the Retreat, but without the 24 hours on a plane!   Saahil Panikar started to join us, and this series culminated in the events I shared in my ‘Emerging from Seclusion’ post in May.    

As I wrote the ‘seclusion post’ I was sitting in Mexico on a writing retreat.  What I didn’t mention was that I was spending a couple of hours a day chatting to ‘fellow Fellow’ Eric Willeke.  I’d been so energized by my collaboration with Wolfgang and Saahil that somewhere on the train between Munich and Prague I’d dreamed up the idea of deliberately creating a collaboration community.  I didn’t know what it looked like, but I did know it involved a Discord community server and lots of collaboration and creation.  Serendipitously, Eric had reached a point in his ’year of not working’ where he was starting to think about what a return looked like.  We’d both shared the Leadership Retreat experience, both enjoyed engaging with others who could stretch our thinking and both felt very values-driven in our creative intent.  Further, if there was one person in the world I knew could challenge my thinking on pretty much anything in the world of Enterprise Agility it was Eric!

What quickly emerged was the idea of creating a community which provided a shared platform to enable collaboration between thought leaders.  The backdrop to our conversation was an amazing book Eric had pointed me to: Jacqueline Novogratz’s ‘Manifesto for a Moral Revolution’.  We knew the community needed to be purpose-driven, even if our purpose paled in comparison to “changing the way the world tackles poverty”.  Eric’s purpose of ‘Creating a stress-free world of work in pursuit of a kinder, more abundant world of humans’ aligned incredibly strongly with my ‘Create a world where people are excited to come to work and fulfilled by the outcomes they’re a part of creating’, so we had a foundation for the journey ahead.

In true agile fashion, we embarked on an iterative process.  We wanted a ‘collaboration rather than a company’, so we began by testing our ability to generate routine collaboration and generative discussion via our Discord community.   Novogratz suggests that “if you are a change agent, then you are by definition a nonconformist”.  Eric and I both love to ‘live on the edge’ teasing at the boundaries of ‘SAFe Canon’ and our other founding members Wolfgang and Saahil were no strangers to living on the edge either so when it came to picking a name Eric’s ownership of the shapingagility.com domain made life easy – we became ‘Shaping Agility’.  

Next came livestreaming.  We didn’t want to share polished content, we wanted to share the process of creation.  In 'The 5th Discipline', Peter Senge suggests that the discipline of working with mental models “includes the ability to carry on ‘learningful’ conversations that balance enquiry and advocacy, where people expose their own thinking effectively and make that thinking open to the influence of others”.  This was what we wanted, not just between those of us in the inner community but between us and the broader community of change agents and practitioners.  

We started with a Shaping Agility channel on Twitch.tv, the dominant streaming platform in the world of e-sports.   This was brand new territory for me, and I’ll confess I learnt more from my two daughters (who both stream their gaming) than my more traditional forms of research.  We’d been holding a regular Saturday session with whoever could make it and we started streaming them.  My daughter Sammi is an audio engineer by day and helped us figure out the technology in between giggling at my ineptitude and after a couple of sessions where she was our only audience and we struggled our way through managing both the stream and the conversation it felt like it was starting to gel.  

Next came persisting the broadcasts.  Balancing the Australian/European/US timezones meant our conversations happened at very weird times and we needed a way for people to ‘catch what they’d missed in the middle of the night’.  So, we created the Shaping Agility Youtube channel and after a few video editing tutorials I started editing out the glaring flaws in our streams and posting them.  We shared them with a few friends and colleagues for feedback and our community started to grow.

Two things were happening for me over this time.  Firstly, I was loving the learning journey of bringing this community to life and our learning cycles on making it work.   We could feel a high performing team emerging even though we all ran our own companies with our own separate offerings.  We looked forward to our conversations, we laughed, we debated, we learnt, we improved.  

Secondly, the creative energy was flowing back into my personal work.  I’d created a one-day experiential course back in 2015 called ‘Experiencing SAFe’ and despite many good intentions had created nothing bigger than a workshop since.  All of a sudden I was in the thick of creating and delivering a ‘Lean Portfolio Management bootcamp’.  I’d be in a discussion with Eric and he’d reference a book I hadn’t read and I’d race off to read and fill the gap.  The process that began in May is now most definitely running at full steam.  Meanwhile Eric has launched the pilot of his cohort-based mentoring program for leading change – Unleashing Scale.

As I write this, we’re shaping the next iteration.   We're playing with ideas for extra shows for the stream.  Wolfgang is preparing to launch a 64-part series on Large Solution, while Michael Casey and Dave Eva joined Eric, Wolfgang and I this morning for the first episode of a weekly bookclub study series on The 5th Discipline.

The decision to go a little more public also prompted a big backlog refinement session.  Among other things, we're going to need a website rather than a redirect to twitch and an approach to engaging more broadly with those who have feedback on the ideas we stream.  We had a bare minimum of stuff we needed to articulate more clearly before this post went live, assembled it on a Miro and decided that the lightest weight version of it was a stream to share (and a learning lesson on audio levels for Eric's first time being the host).

I hope you'll enjoy joining us on the learning journey as much as we're enjoying learning together.

In memory of Martin Burns, sorely missed and never forgotten!

Release Train Engineers (RTEs) - The Power or the Passion

Foreword

The Release Train Engineer (RTE) is a (arguably THE) pivotal role in the success of a SAFe implementation, so over the course of my book research in 2019 I interviewed RTEs at every organization I visited.  Whilst this was a great way to learn the “true state and current pain points of the implementation at the coal-face” it had the side-effect of challenging my beliefs about the characteristics of a great RTE.   As I processed my notes from the study trip I formed the idea of writing a post on identifying and selecting great RTEs but it went onto my writing backlog to collect dust during COVID.

Last week in Prague I bumped into one of the truly inspiring RTEs from my study and as we caught up on her journey since then I shared with her the concept of this post and she challenged me – “why didn’t you write it”.  Em Sperring – this one’s for you!

Emerging from COVID Seclusion: Revitalizing the Blog and New Endeavors

 Introduction: 

Over the past few months, I have gradually emerged from my COVID-induced seclusion. I embarked on collaborations, traveled to teach in Germany and speak at the SAFe Summit in Prague, visited clients and old friends in London, and currently find myself in Punta de Mita, Mexico, where I'm writing this blog post. As I reconnect with people, I am often asked about the whereabouts of my book and my dormant blog. With a lot of writing ahead of me in the coming weeks, I've decided to dust off the blog and explain the reasons behind its silence.

In 2019 I took a semi-sabbatical year to dedicate myself to the book I had been contemplating for years. Its working title was "The ART of SAFe: The Secret to Creating and Sustaining High Performing Agile Release Trains." I believed that I had already written more than half of the book through my blog posts, but it needed refreshing, organization into a coherent narrative, and some content gaps filled. Consequently, I decided to pause the blog temporarily to focus my energy on the book and determine the distinction between content for the blog and content for the book.

A Shift in Perspective: 

However, I made the mistake of undertaking a study trip. I sought to validate the beliefs I had formed while working with my own clients by studying other large SAFe implementations. Through the generous help of friends and contacts, I had the opportunity to observe their worlds and exchange some free consulting for a glimpse "under the covers" of their organizations.

While my initial belief was that the true purpose of the Agile Release Train (ART) was to activate and equip ART-level leaders and stakeholders in creating an ecosystem for their teams to thrive and align with high-performing agile teams, my perspective changed. I realised that ARTs were not the primary challenge – truth be told they’re the “recipe part of SAFe”. Instead, it became evident that what we truly needed was an organization-wide ecosystem capable of fostering an environment (or as Dr. Deming would say, a "System of Work") where ARTs could flourish.

Everywhere I looked, I encountered organizations that had been on their SAFe journey for a couple of years, most with over 20 ARTs in place. However, they were hampered by complexity, politics, difficulties in organizing around value, and challenges in evolving their funding, assurance, and other enterprise-level processes.

Shifting Focus and the "Wrong Book": 

Consequently, I decided not to write the "wrong book." In truth, my former customer and later colleague, Em Campbell Pretty, published an excellent book on that topic ("The ART of Avoiding a Train Wreck") while I was conducting my research. 

I went back to the drawing board, realizing that this was a much more complex problem. Although I had written a small amount on the subject and gained numerous insights that were yet to be synthesized, I needed an overarching strategy. While grappling with this challenge, I taught Luke Hohmann's Agile Product Management course, which led to an "aha" moment. I realized that I could approach an organization's path to enterprise agility through the lens of Moore's Product Management theory. Organizations either struggled to cross the chasm due to gaps in their agile approach's "whole product" hindering adoption by the pragmatists in the Early Majority, or they successfully crossed the chasm based on executive mandate only to become stuck in the Early Majority Tornado due to the same gaps.

The Metaphor and Writing Struggles: 

I had found a metaphor for the book, but there was a tiny problem. I had always written about "things I'd applied enough times to synthesize into patterns," and I had never coached a SAFe implementation using a Product Management metaphor. Additionally, the advent of COVID and lockdowns had a profound personal impact on me. My creative energy waned, and my focus shifted toward simply surviving the circumstances and supporting my clients. 

Despite the challenges, I continued experimenting and learning, engaging in user testing. I quickly realized that while the Product Management metaphor provided a strong framework for my thinking and resonated with other thought leaders like Eric Willeke, it was not suitable for my clients. This should have been obvious, considering that effective Product Management is a key challenge for most enterprises.

Regaining Momentum: 

Fast forward to 2023, and I have conducted enough experiments to have a wealth of new material ready to write about. Along the way, I also gathered a substantial amount of ART-level content that belongs in the blog rather than the book. However, I had yet to regain my writing mojo, despite theoretically living in an "after-COVID" world.

Then, luck came in the form of Wolfgang Brandhuber. We spent 2 hours in a hallway at the 2022 Denver SAFe Summit delving into how his theories on "Large Solution" intersected with my concepts of "Agile Release Trams" and "Loosely Coupled ARTs." Wolfgang reached out to me in early February, suggesting that we continue our conversation, which led to weekly calls and idea-sharing sessions. Soon after, Saahil Panikar joined our collaboration, and our weekly two-hour sessions became the highlight of my week. We began exploring the possibility of merging our work and creating a two-day course to teach in Germany, just before the Prague SAFe Summit.

My creativity started flowing again out of necessity, as I needed to synthesize concepts in order to teach them. Simultaneously, I worked with the incredible Rebecca Davis to prepare my talk on leveraging the power of change managers in pursuit of the flow of value for the Prague Summit.

Looking Ahead:

I’m writing and creating again and loving it.  And the lessons COVID forced me to learn about virtual collaboration are bearing fruit as we start to extend the conversation around creative collaboration in the community. You can expect to see a few things from me in the rest of 2023:

• Quite a few blog posts
• Some very different stuff as our “creative collaboration community” takes shape
• Material Progress on the book (finally)

My visit to the birthplace of Lean

As I write, I’m sitting on the Shinkansen Bullet train from Kyoto to Tokyo, my head full of insight and inspiration from a week spent ticking a big item off my bucket list – a lean study tour of Japan.  It was wonderful to share this experience with my entire leadership team, and I cannot recommend it highly enough to anyone who is or aspires to be a Lean|Agile change agent.  My hope in the following article is to share enough about the experience to inspire you to make the pilgrimage, and just a couple of the many ways in which it has challenged and changed me.

After a great deal of Googling, we elected to join a tour run by Shinka Management, an Australian company who specialises in assisting the exchange of knowledge of Lean and TPS between Japan and the rest of the world both through hosting Japanese visits and delivering consulting and training services abroad. 

Our week began in Tokyo on Sunday afternoon, where we were delighted to discover we were the only Australian members of the tour group of 20 and meet our core hosts Paul, Eri and Dave.  After some introductions, we were taken through a detailed look at the week ahead and treated to an introduction to Japanese business etiquette before heading off to continue the conversation over dinner (the trip includes all meals, travel and accommodation). 

Monday morning began with a series of trains and buses efficiently moving us towards our first destination in Gifu prefecture and accompanied by highlights of the pervasiveness of visual management in Japan demonstrated in the public transport system.  The learning then began in earnest at Shinka’s training centre where we were introduced to Hattori Sensai, a 30-year Toyota Veteran who delivered the bulk of our classroom training for the week. 

Less than 5 minutes into the introduction I had my first new Toyota insight as we came to understand that Hattori Sensai was a “Jishuken” leader, one of a handful of TPS experts that moved from plant to plant within Toyota implementing rapid and concentrated kaizen improvements (humorously translated to us as “Kaizen ninja”).  This was not a term I’d read in any Lean book, and as I came to understand their role I struggled to understand how we’d missed it.  Those who demonstrate early aptitude for Kaizen are enrolled in the Jishuken development program, and then play a key role both as “those sent to solve the hardest problems” and also to act as “kaizen sharing agents” bridging the company boundaries within Toyota (My previous view of “Toyota as one company” was dismantled as I learnt they were actually many companies under one umbrella with distinct differences).  Dave provided superb translation as Hattori Sensai shared numerous insights about the TPS way of thinking and his experience consulting with non-Japanese companies attempting to adopt lean.  I very quickly discovered that the many “Lean books” I had read tended to talk about the author’s insights into “a part of Toyota at a given point in time”, and gaining understanding of cultural and historical context was critical particularly when it came to adaptation.

Hattori Sensai illustrating transport oriented supply chain optimisation

We then proceeded to our first factory visit for the tour – Gifu Auto Body which did final body assembly for the HiAce line and some larger vehicles.  This was the plant where Hattori Sensai had spent the majority of his working life, and his intimate working knowledge enriched the insights immensely as well as providing numerous moments of humour as he “felt the pulse on the gemba” and collared people on the floor who had worked for him to give them a bit of stick over issues he was seeing.  Here I had my second real insight into Toyota.  I had a picture in my head of a factory that felt like a hugely automated laboratory.  I came to understand that Toyota valued ingenuity over infrastructure investment, and the vast majority of their kaizen was about stretching what they had (some advice they offered Elon Musk which he ignored and learnt the hard way).  We then returned for a little more training before concluding the day with more chat over dinner.

Tuesday was again a mix of classroom training and site visits.   We visited Metal One Isuzu, an incredibly impressive steel-processing plant.  They run a model of “Factory as a showroom”.  Salespeople invite prospective clients to the factory, then shut up and allow the factory itself and the operators (all of whom are trained in customer service) to inspire confidence.  At this point, we were starting to understand how much “attention to every detail, no matter how minor” pervaded the way of working.  There was a huge amount of stress on safety, and my favourite moment of the tour involved the “operator-designed and made” safety awareness experiences and the follow-up story from our host Paul.  The factory uses different coloured helmets to indicate role on the floor (as visitors we were in light green).  Each staff helmet has three small safety cross stickers on the side.  As part of Isuzu’s safety culture, if a staff member observed a colleague violating a safety standard or taking an unsafe action they were required to talk to their colleague about it and remove a sticker from their helmet.  The loss of all three stickers would result in the helmet being traded for a pink helmet and safety bib, which was to be worn for a period until the unsafe behaviour had stopped.

Visual Management Boards, the factory floor and the dreaded Pink Helmet at Metal One Isuzu

Tuesday also gave us a session with another of Shinka’s ex-Toyota people, Hyoda Sensai (who had managed the Gifu Auto Body plant and had also served as a Jishuken leader).  The session with him flew by, focusing on leadership and the role of management.  At this point, “a constant sense of danger” at last became crystal clear for me.  Hyoda Sensei stressed how easy it was to allow waste in the good times, which tended to result in crises during bad times.  Balancing a water bottle on the edge of a table, he asked us to imagine that we were the bottle and the drop from the table to the floor was a cliff.  We were then asked how hard we would fight to maintain our balance and find inventive ways to avoid the drop.  After a moment he then moved the bottle back to the middle of the table and repeated the question.  Of course, the urgency had disappeared.  The moral of the story was that a key responsibility of management was to create challenging situations for their teams to maintain that constant sense of danger.

Hyoda Sensai illustrates the "constant sense of danger"

Wednesday brought a visit to Suzaki Industries in the morning.   As well as other clients, Suzaki is a tier 2/3 supplier to Toyota.  Our connection to supply-chain thinking began with a view of a truckload of steel from Isuzu being unloaded, and proceeded to be led by Chairman Suzaki.  His introductory speech contrasted the joy of working with Toyota as a pull-based customer to the challenges of his push-based customers before proceeding with a fascinating walk through the plant and incredible insights into their use of Kanban and endless kaizen-based ingenuity.  We concluded the tour with an hour in a team-room where Mr Suzaki explained how when the bubble burst in Japan in the late 80’s his company was on the brink of disaster.  Until then, the view in Japan had been that manufacturing demand would continue to grow endlessly and many companies had allowed themselves to “grow fat” and let waste creep in.   He had massively overinvested in automation to support production expansion, and when demand shrank overnight due to a massive exchange rate shift he had a factory full of machinery that would never pay for itself.  He described his “Rescue” by Toyota – not in the form of a financial bail-out, but through mentoring.  They informed him they relied on him as a quality supplier and wanted to ensure he succeeded and proceeded to invite him for intensive mentoring at Gifu Auto Body (one of those mentors being Hyoda Sensai).  Yet again the resounding message was “ingenuity over automation” as he described how much less automation was present in his factory today then 30 years ago.

Chairman Suzaki explains production scheduling (left), kanban tickets (centre) and standard work definitions (right)

The afternoon provided an incredible simulation humorously led by Hattori Sensai to help us put the notion of standard work and kaizen problem-solving into practice, in particular highlighting the risk of attempting to improve before you understand the outcome you’re trying to achieve.  By this stage, I’d come to another of my paradigm shifts in understanding.  After years of believing that Kaizen was “about the 1%”, both of our sensai had stressed the belief among the Jishuken leaders that “you could always get at least 30% improvement in a kaizen initiative” (notwithstanding that this is usually achieved by adding up many 1%’ers).

The Coactivation team experiences a rather different type of Kaizen

Thursday commenced with a phenomenal simulation illustrating the operation of Kanban across the supply-chain before we boarded a bus for some welcome downtime on the 3 hour journey to Kyoto for what I personally found to be the most inspiring visit of the tour to Omron Taiyo, a joint venture between Omron corporation and Japan Sun Industries aimed at integrating people with disabilities into the workforce. 120 of 134 staff had some form of disability (physical, intellectual or emotional) – sustainably and profitably producing healthcare equipment, power supplies, switches and other components.  By this stage, the metaphor of “the cliff edge” was front-of-mind on every visit and Omron Taiyo exemplified it as the relentless ingenuity required to support paraplegics, people with one arm, and those with other less visible disabilities in the workplace.  The endless hunt for any edge of improvement was tangible walking the floor, right down to spreading panoramic pictures on the back of binders in filing cabinets to encourage them being placed back in the right position and save 3-4 seconds for people looking for a binder. 

Briefing at Omron Taiyo

After a “night off” in Kyoto, Friday began with a visit to Takatsuki General Hospital to explore Lean in healthcare.   The hospital proudly informed us of the 3000+ improvement initiatives they had implemented under TQM and their use of Quality Circles to build the improvement mindset along with explaining some of the challenges of adapting from the manufacturing to healthcare context.  Their cliff-edge, a rapidly growing percentage of elderly population (65+) living longer and longer stressing the healthcare system.  As we toured behind-the-scenes in the most startling hospital environment I have ever seen, I found myself wishing my wife (who is a nurse) was with me and looking forward to sharing what I had seen with her and enriching my layman’s view of the differentiation.

Kaizen outcomes, therapy innovation, & the masked Coactivation team (plus honorary teammate from Belgium)

Friday afternoon brought a final debrief followed by a celebratory closing dinner and some late-night Kyoto bar-hopping.  I have a number of blog posts I’d been holding off on until after Japan, and look forward to delving more deeply into some of the insights of the trip in those.  If there was one thing that was reinforced every day as a contrast between the Agile world and TPS it was an obsession with data.  We tend to be far too “fluffy and fuzzy”, and the usefulness of hard data whether it be for optimising workflow based on effective demand forecasting, optimising the deployment of your workforce, scheduling work, identifying waste, or steering improvement was amazing to see in action.  

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!

Practical Finance and Cost Allocation in SAFe

SAFe provides some wonderful yet daunting guidance when it comes to funding and the application of Lean Budgets.   As of SAFe 4.6, we have 3 key tenets of Lean Budgeting:

1. Fund Value Streams, not projects
2. Guide Investments by horizon
3. Participatory Budgeting

My purpose in this article is not to restate the SAFe recommendations.  They’re well documented at in the Lean Budget article.  As always, however, I’d rather talk practice than theory – in this case in the area of “Fund Value Streams, not projects”.

In summary, the theory is that we provide guaranteed funding to establish a standing capacity (in the form of an Agile Release Train), then use a combination of “guardrails”, Epic level governance and Product Management accountability to ensure that this funded capacity is well used (building valuable features) and tune it over time based on results achieved.

When I take a room of leadership through this approach its usually pretty confronting, and often provokes strong reactions.  Then I share a story from an early SAFe implementation.  It was with an organization that didn’t have Lean or Agile friendly funding, we just had a stable ART with stable teams that were fed by projects.  And we built a record for “100% on time/on budget”.  We did it in a very simple way.  When something was delivered under budget, we still charged the quoted price, and as such we were able to build up a buffer fund.  When something ran over budget, we drew down on the buffer fund.  It was closely managed, and it all came out in the wash!  By the conclusion of the story, that same room who was reacting strongly a few minutes earlier is suddenly grinning (in some cases rather nervously).  I’m pretty sure every organization I’ve worked with in the past 10 years has survived historically using some variation of this technique.

Some SAFe implementations are lucky enough to start with capacity funded ARTs fully following the framework guidance, but in most cases they’re still realistically project funded.  It’s either a really big amorphous project being used as a masking umbrella to the standing funding model, or quite literally the single ART is being funded by numerous projects and needing to charge back.

And to take it a bit further, even if we are capacity funded we usually need more granular data on how the money is spent.  At minimum, we generally have some work which is Opex funded and some Capex funded.  We also want some data on how much our features are costing.   Hopefully we’re not falling into the trap of funding feature by feature, but when your ART is costing $3-5M per PI the organization will require us to be able to break down where those millions are going.

About now, the timesheet police come out!  Somebody somewhere figures out a set of WBS codes the ART should be charging against (I recently heard an example where a theoretically capacity funded ART had up to 15 WBS codes per Feature), and everyone on the ART spends some time every week trying to break up the 40 hours they worked across a bewildering array of WBS codes that will then be massaged, hounded and reconciled by a small army in a PMO.

There’s a much simpler, less wasteful way.  We’ve used it time and again, blessed by Finance department after Finance department – once they understand the SAFe framework.  I’m going to start at the team level, then build it up to the ART.

Team Level Actuals

We usually work this on a “per Sprint” basis, and need to know two things:

• What did the team cost?
• What did they work on?

What did the team cost?

Figuring out what the team cost should be straightforward.  Given that we know if you’re part of an Agile team you’re 100% dedicated, all we need is your daily rate and the days you worked.  Specifics of how this daily rate is calculated for permanent employees versus contract/outsource vary too much to provide specifics, but for each of your agile teams you should know your “burn rate per sprint”.  You then need a way of dealing with leave and (hopefully not) overtime.  We’re not trying to totally kill timesheeting here, but we can be much more simplistic about it.  Each team member should only have one WBS code to allocate their time against – the one that says “I worked a day as a member of this team”.  Thus, using your knowledge of burn rates and actual days worked you have total cost for the team for the sprint.

What did they work on?

If you’re part of an Agile team, the only thing you could possibly work on is your backlog!  So, we know that the entire team cost should be allocated against their backlog.  From  a funding perspective, aggregating this is based on effective categorization of backlog items: by parent Feature, item type or both.  Consider the following example:

The Sprint in Aggregate

Velocity: 28

Based on a team burn rate of $100K/sprint, we then have:

• Feature A: $36,000
• Feature B: $46,000
• Production Defects: $11,000
• BAU: $7,000

If your world can’t cope with ragged hierarchies, you can create “Fake Features” for the purpose of aggregation.  I quite commonly see features like:

• Feature C: “PI 3.1 Production Defect Fixes”
• Feature D: “PI 3.1 BAU Work”

The richness and detail of your aggregation basically depends on your “Story Type” classifications.  For example, typically work done on exploration/discovery can't be capitalized, which would lead you to introduce a story type of “Exploration”.

Applying the results

At this point, we have all the costs against the temporary WBS associated with their team.  All that remains is to journal the costs across from the temporary WBS to the real WBS based on your aggregates.

If you’re clever, you’ll automate the entire process.  Extract the timesheet data, extract the backlog data, calculate the journals and submit!

Dealing with the naysayers

At this point, some people get worried.  The size of the stories was estimated, not actual.  What happens if Story 1 was estimated as 3 points and was actually 5?  What about stories that didn’t get accepted?  Can Fibonacci sizing really be accurate enough?  Our old timesheets recorded their time spent against different activities in minutes!

It’s time for a reality check.  I’m going to illustrate with a story.  I was recently facilitating some improvement OKR setting with the folks responsible for timesheets in a large division (still mostly waterfall).  One of the objectives they wanted to set involved reducing the number of timesheet resets.  I asked what a timesheet reset was and why it was important to reduce them.  Turned out it was when a timesheet had been submitted and was some way through the approval process when they realized there was an error and it needed to be reset to be fixed and resubmitted.  Obviously, this was a pain.  I asked them how often it happened and why?  The response: “Usually when there’s a public holiday we get a lot of them.  Everyone enters 8, 8, 8, 8, 8 (hours worked) and the approver approves on autopilot then half way through their approval run remembers the public holiday!”

Everyone (and most especially finance) knows timesheet data is approximate at best.  The person filling it out knows they worked 8 hours, guesses their way through how much they spent on what, and finds whatever hours are left unaccounted for and chooses something to attach them to!  And the person approving it does little review, knowing they have no meaningful way to validate the accuracy.

While the backlog aggregation will always have a level of inaccuracy, few will argue that it is any less accurate than the practices employed by their timesheet submitters (unless you’re a law firm steeped in the 6-minute charging increment).  And at this level, your CFO should realize that any variation is not material to the overall investment and is accepted under GAAP (General Accepted Accounting Principles).

Moving from Team to Train

On the surface, life gets a little more complex moving from team to train.  You have lots of people in supporting roles not necessarily working on specific features.  Again, however, it’s not all doom and gloom when you look at prevailing practices.

In many an IT organization, pre-Agile daily rates attract a “tax” used to cover the costs of those less directly attributable such as management, governance, QA teams and the like.  Every project they’ve ever estimated has attracted a percentage surcharge (or a series thereof).

In the same vein, we can calculate a “burdened run rate” for the teams.  We do this by taking the burn rate for every member of the ART not associated with a delivery team, summing them, then distributing them across the team burn rates.  In theory, they exist because the teams couldn’t be delivering value without them – so they must be contributing in some fashion.  Consider the following example:

Support costs can either be distributed proportionally to burn rate or on a flat per team rate (usually based on discussion with Finance).  Assuming a flat per team rate, we can restate the example above as:

This becomes more nuanced in the case of a support team who does directly cost attributable work.  The classic example is the System Team.  They should be spending a certain percentage of their capacity in general support and the rest building enabler features (hopefully DevOps enabler features).  In this case, we can use the team-level backlog aggregation approach illustrated above provided we can see their support work clearly categorized so we know which percentage of their cost to distribute to burdened burn rates and which percentage to attribute directly to features.

All that remains is for our supporting staff to timesheet against a temporary “I worked on this ART WBS”, and we have the means to attribute our costs at the ART level just as we did for the team.

We get one other thing for free.  I like the word "Burdened" when it comes to burn rates.  There's usually a world of potential waste to be eradicated in burden costs.  Calculating some heuristics allows your CFO to start asking some rather pointed questions about whether ARTs are really "running lean".

Conclusion

I work with one small client who has none of the “enterprise fiscal responsibilities” of most SAFe implementations.  In theory, they have no need for any of the above discipline and in fact ran their early implementation without it.  But then they wanted to start analyzing cost/benefit on the features they were building.  In fact, it was the delivery folks who wanted to know the answers so they could change up the cost/benefit conversations when feature requests came in.

I don’t think it matters how “ideally Lean or Agile” you are, if you’re in the type of enterprise using SAFe you will need to be able to allocate your costs across Opex and Capex, and need to analyze your Feature costs to tune your investment strategy and provide data to your improvement initiatives.  The techniques illustrated in this article require good backlog discipline and some walking through to get blessing from your Finance departments, but they’re far from rocket science.  And best of all, they work regardless of whether you’re project funded, capacity funded, or some combination of the two!

Because, in the end, I have one experience with Leaning up governance.  Until you have a viable alternative that enables the organization to fulfil its fiscal and governance responsibilities you’ll never dislodge the onerous, wasteful practices of the past.