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.