Saturday, October 27, 2018

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.


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.


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.


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.

Monday, January 8, 2018

Effective Feature Templates for SAFe


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.


Friday, July 7, 2017

Facilitating Release Train Design with the ART Canvas Part 3 - Launch Planning

Following a hectic couple of  months launching four new ARTS, its time to conclude my three-part series on facilitating Release Train design with the ART Canvas.  Covering the facilitation of a 1-day workshop, the previous posts dealt with creation of a shared ART Vision accompanied by a supporting design.  In this conclusion, I tackle the closing session of the day: the preparation of a launch plan.

Before commencing the launch planning, we generally shrink the audience.  We release the stakeholders who were critical to establishing a shared vision and design, and bring our focus in to the leadership team who will be executing the launch preparation activities.

Agile is a team sport, and the ART is intended to be a self-organizing team of agile teams.  So, your leadership team needs to work as an agile team too!   The vision workshop is essentially a team formation activity for the leaders, who then have the chance to operate as an agile team as they prepare for the launch.

Since our final objective for the workshop is to generate a launch plan, the metaphor that makes most sense is that of a short “enablement PI” which is executed by the leadership team with the support of the product owners.  Thus, the final segment of the workshop is a mini PI Planning.  I open with the following challenge objective for their enablement PI:

“Your product is an Agile Release Train that can fulfil the vision we’ve defined here today.  8 weeks from now (or whatever launch date we’ve set), 150 people are going to walk into a room to spend 2 days in their first PI Planning.  What will make this a success?”
To assist them in their planning, I then distribute the following Features before sending them into breakouts to create a set of stories and objectives that will realize the objective:

The depth to which the plan is developed depends on our time-boxing.  I’ve generally run this workshop over the course of a single day, which means their set of stories and backlog will be very rudimentary given the constrained time-box they will have for breakouts.  I have increasingly become tempted to extend it to a second day, allowing time to create a more effective plan, establish PI objectives, identify dependencies and create a Program Board.  This would also allow some time on the 2nd day to work through some team formation activities with the Leadership Team such as:

  • Development of a social contract
  • Design of the team Kanban
  • Planning of team demo approach (the team should be demonstrating back to stakeholders on launch preparation progress)
  • Agreement on standup timing
  • Iteration planning for the first iteration

Closing the session

In closing, we should have the following outcomes:

  • A name and launch date for the ART
  • A completed ART canvas, ready to be hung on a wall (and eventually digitised)
  • An agreement for the newly formed ART leadership team to function as an agile team during the launch preparation
  • An appropriately scary launch preparation backlog that motivates movement by the leadership team and is accompanied by an agreed “Agile monitoring” process using Team Demos to enable progress transparency and feedback. 

I like to close out with a final check-in.  I love the definition of consensus Jean Tabaka taught me: “I can live with that, and support it”.  It’s a great way to bring a day of very hard work to a close, perhaps using a roman vote.  “We’ve formed a vision, an ART design and a plan today.  There’s a lot of hard work ahead of us but I’d like to check that we have achieved consensus before we leave this room.”

Sunday, June 11, 2017

Reflecting on the 2017 SAFe Leadership Retreat

Earlier this week, I spent a few days at the very picturesque Dalmahoy Hotel in Edinburgh attending the 2017 SAFe Leadership Retreat.  This was our 3rd gathering, having travelled to Banff (Canada) in 2016 and Crieff (Scotland) in 2015.

If I had to describe the retreat in one word, it would be “community”.  Given the general application of SAFe in large enterprise and the prevailing “partner consultancy” based model, creation of an environment where both consultants and practitioners come together to transcend boundaries and share is no mean feat.  Full credit must go to +Martin Burns and his better half Lucy for their tireless efforts in this regard.

As always, the retreat was attended by +Dean Leffingwell  along with a number of other representatives from SAI.  Also in attendance were a mix of SAFe Fellows, SPCTs, consultants and practitioners along with a “chaos monkey” in the form of +Simon Wardley.

Having now had a few days to reflect on the experience, I’d like to share some of the key themes that emerged.

SAFe “next”

In the opening session, Dean spent a couple of hours running us through the soon-to-be-released next version of SAFe.  Whilst we’re under NDA when it comes to specifics,  I can say that the changes were enthusiastically received – with much improved guidance in some critical areas and best of all for the first time ever a simpler big picture!

SAFe beyond technology

Whilst the framework is squarely focused on the HW/FW/SW side of “Lean Product Development”, those with a truly lean mindset know that there’s a lot more than technology involved in the creation of a Lean Enterprise and optimization of the flow from Idea to Value.  I’ve long held the belief that great ARTs extend beyond technology into Sales, Marketing, Business Enablement and Business Change Management and it was great to see many others not just talking about this but doing it.

HR as an enabler rather than an impediment in a Lean-Agile transformation

We were lucky to have a number of attendees who were either practicing HR professionals or came from an HR background, and numerous open-space sessions devoted considerable attention to Lean|Agile and the world of HR.  Whilst Fabiola Eyholzer’s guidance article last year made a great start on this front, many are grappling with the practical realities of such questions as how to address career progression in the ScrumMaster/RTE and Product Manager/Owner spaces.  Hopefully in the coming months we’ll see some of the outcomes of those discussions synthesized and in the public domain.

SAFe for Systems of Record

When it comes to true Business Agility, there are always Systems of Record involved.  A number of sessions and discussions focused on this, with a particularly robust session on SAP.   The general conclusion was that whilst it’s a lot more convoluted than digital, many are doing it successfully and common patterns are emerging.

Active Learning in SAFe courses

Many of the attendees were passionate believers in experiential and/or active learning who have struggled with the orientation of the SAFe courseware towards “lecture-style” training.  The great news for all of us is that this is becoming a significant focus area for SAI.  The newly introduced RTE course is a radical departure from the past, and the preview we were given of the new Leading SAFe course shows marked improvement in this direction.

SAFe is taking off in Europe

I’ve been coming to Europe every few months in a SAFe context for a couple of years now (starting with Crieff in 2015), and it has clearly been lagging the US and Australian markets in enterprise adoption.   But it appears the time has come.  Of the roughly 50 attendees at this year’s summit, perhaps 40 were European based and the vast majority were actively involved in significant SAFe implementations – a radical departure from 2015.

Closing Thoughts

Great agile is all about collaboration, relationship and learning.  The manifesto expressed it beautifully with the words “We are uncovering better ways of developing software by doing it and helping others do it”.   This year’s retreat lived the philosophy, and I enjoyed deepening existing relationships, forming new ones, sharing my experiences and learning from others’.  Bring on 2018!

Sunday, April 23, 2017

Facilitating Release Train Design with the ART Canvas Part 2 - Design


In my last article, I introduced the concept of facilitating a 1-day launch planning workshop for an Agile Release Train using the ART Canvas.  The workshop covers the generation of a vision for the ART, preparing an initial design and generating a launch plan.

The more ARTs I launch, the greater the time I devote in the workshop to developing a clear, aligned vision using the approach described in the preceding article.  With this in hand, we are well equipped to move forward with designing the ART itself – the focus of this article.

Workshop Agenda

  • Vision (Details in last article
  • Design
    • What is the Development Value Stream and to what extent will the ART cover it?
    • Who will fill the key Leadership roles for the ART?
    • What supporting leadership roles will the ART need?
    • Which technical assets will the ART impact?
    • What is our Team Design strategy for the ART?
    • What is the Name and Launch Date for the ART?
  • Planning (Details in next article)

What is the Development Value Stream and to what extent will the ART cover it?

I was torn between calling this section of the canvas “Development Value Stream” or “Solution Context”.  Introduced in SAFe 4.0, the Solution Context “identifies critical aspects of the target solution environment” and “is often driven by factors that are outside the control of the organisation that develops the solution”.  I settled on the Development Value Stream because this tends to be how I facilitate the conversation.

Our focus here is really to delineate the difference between “the ART we want” and “the ART we can have”.  The “ART we want” can take an “Idea” directly from the Operational Value Stream and perform all activities necessary to carry that Idea through the life cycle until it ends in realized “Value”.  However, reality tends to intervene.  Perhaps the ART is not capacity funded and “Ideas” need to be routed through some type of PMO function before reaching the Product Manager.  A particular supporting system may not able to be worked on by the ART due to the nature of the contract with a vendor or its ownership by an entrenched organisational silo.  Further, many ARTs cannot deploy independently and must participate in an enterprise release process.

Lack of awareness of the pragmatic compromises in your ART design can and will derail you.  In Good to Great, Jim Collins summarized it beautifully: “You must maintain unwavering faith that you can and will prevail in the end, regardless of difficulties, AND, at the same time, have the discipline to confront the most brutal facts about your current reality, whatever they may be”.

My favorite way to represent this is to depict a Development Value Stream running from “Idea to Value”, and represent using shading or call-outs those components of the Value Stream which fall outside the boundaries of the ART.   There will be some obvious exclusions we can use to frame the following discussions, and as design progresses we will find ourselves adding some fine details.  By the end of the workshop, we should have highlighted all of the ART’s key external dependencies in fulfilling its mission.

Who will fill the key Leadership Roles for the ART?

If you have been comparing my canvas to the one Dean documented, you will notice a couple of differences.  One of these is that I define 4 key leadership roles, whilst Dean sticks to the “classic troika”:

  • Release Train Engineer
  • Product Manager
  • System Architect
  • UX Lead (My addition)

The reason for my extension is simple: experience and scars.  The vast majority of ARTs have at least some digital component to them, and if you have a digital component you will have a UX competency.  I have learnt a great deal about the field of UX in the last 5 years, and much of it I’ve learned the hard way.  Two critical lessons have emerged:

  • There is regularly significant confusion between the roles of UX and Product Management
  • When it comes to embracing iterative and incremental approaches, UX specialists are often the new architects in terms of mindset battleground.

My response is to embrace their critical leadership role in enabling effective digital outcomes by recognizing them formally as part of the ART Leadership team.

Facilitating the selection of candidates is generally a formality.  If we’ve prepared for the workshop at all well, the nominees are sitting in the room and putting their names in the boxes is simply putting the stamp of approval on the nomination.  If we walk out of the room with one of those boxes empty, we have a critical priority as all of them are going to be incredibly busy in the coming weeks executing on the launch plan and every day will count for each of them.

What supporting leadership roles will the ART need?

Large ARTs will often need some additional folks to support the key leaders.  Following are some sample questions I use to seed this discussion:

  • Will one Product Manager be enough?  (in the case of multiple Product Managers, I’m always looking to see one designated as “chief” but if we remember the SAFe guidance of 1 Product Manager per 2-4 Product Owners it will be far from uncommon to see 2-3 people in this role)
  • Will one Architect be enough? (Given that system architects are often tied to a limited set of technology assets, I often see 2-3 architects dedicated to large ARTs to provide adequate coverage to all assets)
  • Do we need a Release Manager? (If the ART is facing into an Enterprise Release process and has low or no Devops Maturity, liaising with the ITIL folks can be a full-time role)
  • Do we need a Test Manager?  (The concept of a Test Manager might be anathema in a mature agile implementation, but as we launch our ART we’re not yet mature.  Who is going to mentor the testers embedded in the teams and assist them with evolving their testing strategy whilst also meeting the organisation’s governance and quality articulation needs?)
  • Do we need a Change Manager? (Many of my ARTs have a full change management team, in which case of course we would tackle this in our team design, but in cases where we don’t have a full team I often see this role staffed for the ART to enable effective liaison with the Operational Value Stream with respect to operational readiness and go-to-market strategies).

Whilst on the one hand we want to “minimize management overhead by creating a self-organizing team of teams”, on the other this will not happen overnight.   Experience has taught me that for any significant ART people in these roles will exist – our choice is whether to make them a “part of the team” sharing ownership of our transformative change, or a part of “external governance functions”.

What technical assets will the ART impact?

Begin with the list of supporting systems from your Operational Value Stream outputs.  Then, because representation in the value stream is often in terms of “meta platforms”, add in more granularity as needed.  (For example, middleware is part of most ARTs but often considered to be implied during the value stream discussion).

Now examine the list through the lens of “Frequency/Extent of Impact”.  Framing the discussion in the context of the “typical Features” defined in the Solution section of the canvas, a simple mechanism such as “*” for frequently impacted and “**” for always impacted can be useful. Below is a simplified and de-sensitized example from a recent workshop:

  • Web**
  • SAP Bus Suite*
  • Mainframe*
  • Mobile*
  • Security
  • ESB*
  • ESS
  • WFM
  • Data Integration
  • MI/EDW*

What is our Team Design strategy for the ART?

It surprises me that there aren’t entire books devoted to the topic of agile team design and the trade-offs between feature and component teams.  My advice: "Be pragmatic yet ambitious".  

In brutal honesty, I’m a reformed “feature team purist”.  I love the theory, but I’ve lived the reality.  Your culture has to be ready for them.  Not just your management and silo owners, but most importantly your team members.  They just don’t work without open-ness to cross-skilling.  Have a conversation with an iOS dev about writing android code.  Try another conversation with a 20 year COBOL veteran about learning to write javascript.  Recognize that there are specializations within specializations – there is no better place to learn this than your middleware folks.  The naïve will think “surely I can put a middleware person in each team”, only to discover there are 6-7 discrete specializations within middleware.

Recognize that your ART has to start somewhere, and inspect and adapt itself to a better place.  I establish a “feature teams are the goal” mindset, then climb my way back to a decent starting place – generally a combination of “nearly feature teams” with 2-3 specialized component teams.  For example, for the asset stack above we wound up with “nearly Feature Teams” containing Web, SAP and Mainframe skills, a “Data and Analytics” team, a “specialized assets” team and a “Business Enablement” team focused on change management and operation readiness.  By the end of the first PI planning we’d also added a lawyer to the Business Enablement Team.  And .. don’t forget to define the flavor of your System Team while you’re here.  Nowhere will you tackle more organisational silos than in staffing a good system team, you want to seize the momentum you have established on vision to lock this in.

Do not attempt to match names to teams in this workshop.  Focus on defining “team templates” covering both technical and non-technical skills (eg BA, UX, Functional Analysts if you have an ERP, etc).  Working out the quantity of each team flavor and the match of names to teams can come later.  If you’ve put the right people in the room (line managers) you are reaching alignment on commitment to dedication and cross-functionality.

What is the Name and Launch Date for the ART?

Let me be brutally clear, if you leave the room without a launch date you’ve missed a huge opportunity.  A committed date is a forcing function.  You are laying the seeds of the “fix the date, float the scope” mindset the ART needs to have.   Look for something between 2 and 8 weeks, with a preference for 6-8 weeks.   Anything less than 4 weeks requires a lot of special circumstances, so if you’re new to the game don’t try it.  Anything more than 8 will hurt your sense of urgency and momentum.

On the Name function, I (and my colleagues) are huge believers in the power of a name in establishing a shared sense of identity.  All the data is on the table to find one, and the sooner this new creation has a name the sooner it will begin to take life.  Some recent examples for me:
  • SHERPA (Secure High value Engaged Reliable Payment Assurance)
  • DART (Digital Assurance Release Train)
  • START (Student Transformation Agile Release Train)


With an agreed vision and design for the ART, the final step is to generate the launch plan and supporting approach - the topic of my final article in this series.

Saturday, April 8, 2017

Facilitating Release Train design with the ART Canvas Part 1 - Vision

It became clear to me after I began to read the four hundred or so vision statements I received: they all read the same.  Every organisation cares about customers, values teamwork, exists for shareholders or the community, believes in excellence in all they do.  If we all threw our vision statements in a hat and then drew one out, we would think it was ours regardless of where it came from.  I finally realised that it was the act of creating a vision that matters, not so much the content of what it was.” – Peter Block, Flawless Consulting


In January 2014, I wrote my first article on launching an ART.   It focused on the concept of a launch planning workshop that formed a cross-functional Agile Leadership team and generated a vision and a backlog they could execute on over 6-8 weeks to launch their ART.

I’ve launched over 30 ARTs since then, and whilst my core approach has remained consistent it has benefited from a great deal of iteration.  The biggest change has been adjusting the proportion of time I spend on the ART vision and design as opposed to the launch preparation backlog.    Alignment is a key component of ART success, and if the leaders aren’t aligned on the vision there is little hope for the teams.

Walking out of a brilliant launch workshop last year, I sat down to reflect on the key conversations and capture some notes to feed forward into my next launch.  As I reviewed the photos, I had an aha moment.  Why not use a Lean Canvas to anchor the key conversations?   I could print it out as a big wall poster, structure an agenda around completing it and walk out of the workshop with a “Train on a Page” diagram.

I’ve used it a number of times since then to good  effect, and when I shared it with +Dean Leffingwell  on a visit to Boulder in January he was quick to ask about including it in his new Implementation Roadmap.  While he beat me to the publish button a few weeks ago with his Prepare for Art Launch article, I felt there would be value in sharing the approach I take to facilitating it.

All of my ART launches begin with what I call the “Launch Planning Workshop”.  Generally held within a week of the Leading SAFe, this is a one-day facilitated workshop attended by the Business Owners and ART Leadership team with the objective of clarifying the vision, boundary and key success measures for the ART and generating the launch preparation backlog.

The workshop progresses through 3 phases:
  • Define the vision
  • Design the ART
  • Generate the Launch Plan
This article will tackle opening the workshop and the most important phase: the Vision.  My next two articles will address ART design and generation of the launch plan.

Opening the Workshop

The workshop opens with a blank A0 copy of the Canvas pinned to the wall and a 2-part objective:
  • Complete the ART Canvas to define the Vision, Leadership and Design strategy for our ART
  • Generate a backlog detailing the activities necessary to bring it to life
The bulk of the attendees should have recently attended Leading SAFe, and key participants include:
  • ART Leadership Candidates (at minimum RTE, Product Manager, System Architect)
  • Key sponsors from both Business and IT
  • Relevant technology Line Management (those who are likely to be contributing staff to the ART)
As a general note, I do not directly populate the Canvas.  I operate on either 2 whiteboards or a combination of flip-charts.  At the completion of each section, a scribe will transcribe the outputs onto the canvas.

Workshop Agenda

  • Vision
    • Which Customers will be impacted by the ART?
    • Which Operational Value Stream(s) will the ART support?
    • Who are the Business Owners for the ART?
    • What kind of Features will the ART deliver?
    • How will we measure success for the ART?
    • What is the Vision statement for the ART?
  • Design (Details in next article)
  • Planning (Details in future article)


The first 6 topics on the agenda address the vision for the ART, culminating in the creation of a Vision Statement.  

Which Customers will be impacted by the ART?

Customer centricity is at the heart of Lean and Agile, so it is where we begin.  This should take no more than 5 minutes.  Personally, I use the “internal Customer” and “external Customer” metaphor to frame the conversation and ensure we are covering both internal users of the solution and true customers of the organisation.

Which Operational Value Stream(s) will the ART support? 

The mission for any ART involves improving business outcomes, and succeeding in that mission begins with understanding the flow of value in the areas of the business the ART is to support.  
If a Value Stream workshop has already been conducted, this is the moment to review the outputs from that workshop.  However, for most ARTs this is not the case and now is the moment to identify and map the relevant operational value stream(s).  Provided the right people are in the room, this can be generated at an appropriate level in 20-30 minutes.   Generally, we are concerned with a single value stream and we look to our business folks to generate the core flow and architects to map the underlying systems.  Note that we do not need a great deal of detail.  

Service Assurance Operational Value Stream for a Telco
For more information (and examples) on approaching this, see the excellent new guidance provided in the Identify Value Streams and ARTs article from the Implementation Roadmap.

Who are the Business Owners for the ART?

I have to confess that for a number of years, I wondered why Dean insisted on providing a new term instead of just talking about Stakeholders.  An embarrassingly short time ago, it finally hit me.  Every ART will have many stakeholders, but in general 3-5 of them will be critical.  These are your Business Owners.  SAFe calls out specific responsibilities for them, defining them as “a critical group of three to five stakeholders who have shared fiduciary, governance, efficacy and ROI responsibility for the value delivered by a specific Agile Release Train”.  

Having now lived through a number of ARTs where either the membership of this group was unclear or the identified members took little accountability, I am now very focused on identifying them early and ensuring they have been engaged and signed up for their responsibilities prior to the launch.

What kind of Features will the ART deliver (Solution)?

Over time, the ART will deliver many Features.  In general, by the time you are at launch there is a known seed.  Perhaps it is being triggered by a waterfall program with preexisting expectations “converting” to agile.  Perhaps a critical project, or an urgent set of priorities.  But we’re also looking to consider the future – if for no other reason than to assist in both communicating to the broader organisation and assist decision rules on work that should be routed to the ART.  Following is a sample from a recent workshop:
  • New, digitally enabled user experience on available technology
  • Process automation, improved data exchange with third parties
  • Remediation of current platform
In short, by this point we know which operational value stream we're supporting, who the customers and key stakeholders are - we just want to clarify "what kind of stuff" they can expect from the ART.

How will we measure success for the ART?

Given that 9 out of 10 of my last articles have focused on metrics, it should come as no surprise that I want to talk about them as part of our vision workshop.  There are many good reasons to do this, but the most important one lies in establishing the mindset that success for the ART involves business outcomes, not “delivering features on time and budget” or “improving velocity”.  It enables validation of the vision with the Business Owners, assists Product Managers in establishing their WSJF prioritization approach for the Program Backlog and frames the kind of benefit propositions that should be appearing in Features.  Further, it enables us to capture baselines during our pre-launch phase so we are positioned to understand the impact the ART is having.

For those who have followed my Metrics series , this area seeds the Fitness Function from the Business Impact quadrant.  Whilst you many not exit the room with a full set of quantifiable measures, you can at least define qualitative ones and a follow-up activity to establish quantitative approaches to them.  Below, you’ll find a (slightly desensitized) sample set from a recent workshop:
  • Staff
    • Automation of simple work
    • Able to add more value by focusing on complex work
    • Stable and trustworthy technical platform
  • Customers
    • Simple, intuitive, digitally enhanced experience
    • Increased accuracy and timeliness 
    • Tailored service offer based on individual circumstances
    • Seamless movement between channels (tell us once)
  • Organisation
    • Straight-through processing increased
    • Authenticated digital transactions increased
    • Accuracy increased in the areas of debt, outlays and fraud
    • Operational Costs reduced

What is the Vision Statement for the ART?

The discussion we have facilitated to this point has been focused on identifying “non-generic” components of the vision statement by exploring the following questions:
  • Who are our customers?
  • How do we interact with them? (the operational value stream)
  • Who are our critical stakeholders? (who have to bless the vision)
  • What kind of Features are we going to deliver?
  • What difference are we to make? (Success Measures)
Now we want to bring it all together.  I’m a big fan of the elevator pitch template popularized by Geoffrey Moore in Crossing the Chasm and leveraged by SAFe in the Epic Value Statement.   I will generally split the room into two sub-groups (ensuring a mix of backgrounds in each), and give each 20 minutes to create their pitch.   I then help them pick a favorite, and optionally spend another 10 minutes polishing it by incorporating key ideas from the discarded pitch.

For the brave, an alternative which can really get the creative juices flowing is the Pixar Pitch.  My colleague +Em Campbell-Pretty wrote an article on it a few years ago which includes a sample used as the vision for an ART in a higher education setting.  Whilst confidentiality precludes me from sharing a specific example here, I have included one written by a leadership team describing what success with their SAFe implementation would look like:


Getting this far will take at least until lunch, and probably a little further.   In all likelihood, the longer it takes the more value you are getting from the discussion as assumptions are flushed and clarity emerges both on “what the mission of the ART is” and just as importantly “what it is not”! 
The alignment and sense of mission achieved here will stand you in good stead as you progress into the ART Design agenda items addressed in my next article and begin to tackle some ivory towers and entrenched silos.

Sunday, March 26, 2017

Using OKRs to accelerate Relentless Improvement


In my last 2 articles, I first introduced the concept of Objectives and Key Results (OKRs) with an illustration based on personal goal-setting then explored applying them to improvement of Product Strategy.

After experimenting on myself with personal OKRs, my first applications of the concept in a coaching setting have been in the area of improvement objectives.  I was particularly excited about this idea as I encounter so many teams and ARTs who lose heart with their retrospectives and Inspect and Adapt sessions due to failure to follow through on their great ideas.

I’ve lost count of how many discussions I’ve had in either the training room or a coaching setting with people who drag themselves to retrospectives feeling they are a waste of time.   The common refrain is that “we just keep talking about the same issues and nothing ever changes”.  A little probing generally exposes the following:

  • Teams use the same format every time (my pet hate is the “What went well, what didn’t go well, what puzzles me” retro).
  • Teams spend 80-90% of our session examining the past
  • The (rushed) improvement idea generation yields concepts beyond their power to change or very fuzzy
  • Few teams retrospect on the effectiveness or application of the ideas they do generate 

I’ve gifted many a copy of Esther Derby and Diana Larsen’s classic “Agile Retrospectives” to ScrumMasters and RTE’s.  Likewise, I’ve facilitated countless sessions on time-boxing your retrospective or I&A to leave at least 50% of it for the “improvement” part of the discussion.

Good facilitation will at least get you to the point of emerging from the session with some good ideas.  However, in the words of Michael Josephson “Ideas without action are like beautifully gift-wrapped boxes with nothing inside”.

Crystallizing your great ideas with OKRs

A couple of years ago, I started experimenting with the Improvement Kata to assist teams with actioning their ideas.  As I researched it, I came across a great article describing an “Improvement Theme Canvas” by Crisp’s Jimmy Janlen.  The canvas was beautifully simple, taking teams on a great journey with 4 questions:

  • Where are we now?
  • Where do we dream of being (What does awesome look like?)
  • Where can we get to next? (And how would we measure it?)
  • What steps would start us moving?

I used it again and again, in settings ranging from team retrospectives to executive workshops.  And it helped.     But it was still missing something.  There was a recurring trend – a lack of measures.
As I started experimenting with OKRs, there was an obvious synergy.   I had found the Key Result setting to be the moment where I did my deepest thinking myself, so I tweaked the canvas a little:

My first opportunity to apply it was the second day of a management workshop.  The first day had been spent exploring challenge areas and selecting focus areas for improvement.  We had a fairly clear view of current state and definition of awesome (which represented 18 months+ of hard work), and the job on Day 2 was to address the right side of the canvas with a 3 month view. 

We began with some objectives, then the hard work began – how would we measure them?  The result was incredibly powerful.  We moved from some very fuzzy, amorphous objectives into real clarity on how to generate momentum.  When you start to talk about how to measure movement, something changes in the conversation.  On the one hand, it grounds you in reality but on the other the fact that you are looking for a measure ambitious enough to only have a 50% chance of success stretches you out again. 

As an illustration, I’ve developed a sample based on a commonly occurring theme in Inspect and Adapt sessions – struggles to develop momentum with Test Automation.

As a final hint on the canvas generation, the order in which you complete it is crucial.  There’s a great temptation to rush to “Enabling Activities” because people love to begin with solutions.  
  • Start with “Current state”: fishbone diagrams, 5 whys, and causal loop diagrams are all great tools for generating the data and shared understanding
  • Move to “Definition of Awesome”.  The word “Awesome” is incredibly powerful in helping move minds into the art of the possible, and also encourages alignment around desired direction.
  • Step 3 is to agree on your timebox (often 3 months or one Program Increment) and figure out how far you can move from your current state to the definition of awesome as you set your “Target State OKRs”.  You will start flushing assumptions, and more importantly discovering alignment challenges.  The movement to quantified measures with your Key Results will expose many an unvoiced insight.
  • Only now do you set the “Enabling activities”.  They will come very quickly.  If you’ve set your OKRs well, your key activities will be very obvious.

So far we only have an Idea, what about Action? 

I can recommend nothing so strongly as the weekly priority-setting cycle from Radical Focus I described in my first OKR article.  The reality is, despite many schemes people use for creating space for follow-up on improvement ideas it is amazing how often they stumble.  Life gets busy, delivery pressure is high, and the first thing that gets sacrificed is time to work on improvement ideas. 

The beauty of setting yourself a few priorities each week on moving towards your OKRs and spending a little time reflecting on them at the end of the week is that it helps you “find time”.  A few months into applying personal OKRs I can attest to this.  I live a very hectic life.  Most weeks involve 5 long days facilitating and coaching with clients, 2-3 flights, and lots of “after hours admin” whilst coming up for air to be a dad, husband and human 😊  Its very easy to find excuses.  But every week starts with “how can I move forward this week?”  And in the back of my head every day are my weekly goals.  To be brutally honest, my learning cycle at the end of the week often focuses on “how to find time”.   I’m not waiting 3 months to look back and find out I made no progress and lose heart.   

My final hint is this: Make them public.  If you’re applying the technique to Inspect and Adapt,  your improvement OKRs should appear in your PI Objectives and progress discussed  in your System Demos and PI Demo.  Include the Key Result evaluation in the metric portion of your Inspect and Adapt.  There is both power and motivation in transparency about improvement objectives.