Launching your Agile Release Train - Preparing for the first Release Planning Event

You've decided to adopt SAFe, found your first Agile Release Train and are embarking on the launch journey.  You have a bunch of Safe Agilists who have completed "Leading SAFe", and an SPC who has done the certification but never actually launched a train.  What comes next?

If you're like most, you're now feeling a mixture of excitement and trepidation.  The maths most people do looks like this:

• 100 people in a room for 2 days = $150-$200K
• A bunch of senior stakeholders present = a huge opportunity for a very public embarrassment

You've been over the agenda in depth in your SAFe course.  You've read some case studies or talked to some people and been convinced it works.  The question running around and around in your head is "how do we make it work for us?"

One answer might be to go and guest at somebody else's event to glean experiential learning.  As a fresh SPC, it was certainly high on my wish list.  But I had two problems.  The first was that I was in Australia and the only people I knew doing it were overseas.  The second, of course, was that these events often deal with very sensitive information and it's hard to get an invite.  Despite my repeatedly offering to fly myself anywhere in the world to get first-hand learning, I eventually just had to learn by doing.

This is the first of a series of posts in which I'm going to share some of the lessons I've learnt along the way.  It's a mix of the things I wish I'd known, and the things I knew in theory which were emphatically reinforced in practice.

The first insight I'd offer is this:

It really is magical how much energy and alignment happens when  100 people with a common purpose collaborate for 2 days.

To be brutally honest, I'd lived on the trepidation side for a long time.  The first train I helped launch (documented extensively in previous posts) frustrated Dean no end by not adopting PSI's until well after I had moved on from coaching them.  There were lots of very good reasons.  They got an immense amount of value from "SAFe without PSI's".  But I still hadn't seen the "magic event" :)

In the meantime, I researched it, talked to people about it, and taught SAFe to hundreds of people - and the release planning component was always theoretical.  I believed emphatically in the theory.  But when I actually facilitated my first one, I staggered out at the end of it completely and utterly blown away by how powerful it was.  I have facilitated hundreds if not thousands of groups and workshops over the years, and I have never felt such a powerful movement into alignment.  A comment from the Commercial Manager footing the bill for the event sums it up pretty well:

Mark, I reckon we've just saved about 8 weeks

What's Next?

Eventually, the series should cover about 10-15 posts.  Following is the series to-date:

• Tip #1 - Execute your launch as an Agile Project for the Leadership team of the Train
• Tip #2 - Avoid "Death by Powerpoint" on the first morning
• Tip #3 - Apply Lean Principles to the Planning Event - Plan with Flow
• Tip #4 - Consider Feature Breakouts as well as Team Breakouts
• Tip #5 - Know your Capacity Constraints
• Tip #6 - Scaled Planning needs Scaled Facilitation

SAFe, Safety and Conversations

For the last couple of years, I have primarily been training and consulting to clients interested in employing Dean Leffingwell's Scaled Agile Framework (SAFe).  In recent months, it has increasingly come under fire from the broader Agile community -the favourite theme being "Is SAFe really safe?".  Whilst in some cases I've felt the critiques simply to be ill-informed rhetoric, in others the criticism has emanated from people I deeply respect.

I've struggled with this, not least because I empathise with many of the concerns about it appearing heavyweight and prescriptive.  To be brutally honest, the scaling model I most admire is that of Spotify.  Every article I read or speech I hear about what they have done fills me with awe.

And yet, I feel SAFe has a very important part to play in the ecosystem.  This feeling is based in the fact that there are two completely different types of organisation considering "scaling agile".  The first has started small, nurtured amazing teams and is working to preserve that culture as they grow organically (with that growth most likely being driven by the success of the amazing teams).

The second, however, is already large.  They live in a heavyweight, heavily governed world.  They offshore, they outsource, they rely on enterprise-grade COTS such as Siebel, Peoplesoft and SAP.  Any real problem demands the involvement of hundreds of people.

This second group wants to change, but the "agile conversation" leaves so many questions unanswered that it fails to penetrate to middle and senior management.  Agile teams which get launched are slowly strangled by the inertia of the apparatus within which they are constrained.  The amazing creation that is something like Spotify just seems unattainable.  Glenda Eoyang puts it well in her book Facilitating Organisation Change:

Unless the vision of the future is grounded in current reality, it will not be helpful.  Vision statements that are disconnected from current reality create a gap that is too large to cross.

This, to me, is the world of SAFe.  It provides something recognisable enough to be be "safe" for the organisation to step into.  It begins a conversation, and most importantly it is a shared conversation.  Time after time, I teach courses where the room contains a mix of senior stakeholders, PMO representatives, middle management, senior architects, operations and infrastructure leads.  The framework provides a platform for a shared conversation about how they will change together.

The responsibility, of course, lies in my hands to focus on the principles.  It looks like a recipe, it carries a very real risk of being treated like a recipe (and being destined for a horrible failure).  But, if the principles can shine through and the energy for change can be built the journey of Kaizen can begin .. taking them towards that future world in which they can peel away the structure of SAFe.

My most recent course involved the IT leadership group of an organisation.  They started the course interested in Agile, but struggling to understand how to apply it to their world.  SAFe had looked recognisable enough to motivate them to invest 2 days in learning it.  As the course progressed, it became clear that SAFe would help with some of their challenges .. but equally clear that it was not a "one stop recipe shop".  We closed the course with 10 minutes for each table to summarise their key actionable insights.  My favourite was a graphic rendition on post-its .. presented here with a couple of annotations to augment a slightly out of focus picture.

I don't think I will ever help a client implement SAFe exactly as Dean describes it.  I've never yet met a client or seen a context where it fits perfectly.  But I love it as a starting point - and will close with the immortal words of George Box:

All models are wrong, but some are useful.

NPS and Collective Ownership

As a coach, there are two primary outcomes I'm trying to help my clients achieve - optimal value flow and great teams.  To optimise value flow, of course, one must first have a way of measuring it.  Lead time is easy to quantify, but value often not so easy.

A year ago, one of my clients was struggling with measuring value.  Their organisation was heavily focussed on customer advocacy and was transitioning from traditional customer satisfaction measures to Net Promoter Score (NPS).  Curious to see if that might provide us with a new lens to examine value in the customer's eyes, I decided to find out how NPS worked.  So, I picked up a copy of The Ultimate Question 2.0 and found it hard to put down.

A decent explanation of Net Promoter Score can be found here, but the summary version is this.  You want your customers to be so happy with you that they tell others.  Traditional complex questionnaires are replaced with 2 questions:

• On a scale of 0 to 10, how likely are you to recommend us to a friend or colleague?
• What were the primary factors in the score you gave us? (or "What would we have to do to get a 10?")

Responses are then divided into 3 categories:

• Promoter - 9 or 10.  Highly loyal, certain to promote you to others
• Passive - 7 or 8.  Satisfied ... for now.
• Detractor - 0 to 6.  Unhappy, likely to defect and spread negative word-of-mouth feedback.

A final score is then calculated by subtracting the percentage of detractors from the percentage of promoters.  For example, you receive 15 responses:

• 6 promoters (40%)
• 8 passive (53%)
• 1 detractor (7%)

Final NPS score is then +33 (40% - 7%).

The other thing that came through in the book was that most companies who measure customer NPS also measure employee NPS.  The question in this case is formed on the line "How likely are you to recommend working here to a friend or colleague?"  I was sold!  Customer advocacy is surely a good indicator of value delivered, and employee advocacy of your journey to creating good teams.

These instantly became my two favourite system level measures.  My client also bought in and was very happy with the insights generated, and they went straight my coaching toolkit.

I found out yesterday that I'd missed something vital in the implications.  As well as coaching, I train.  I've probably delivered over 200 courses over the years.  Until this year, they were always for someone else.  They provided the materials, the venue and the students and I turned up to deliver.  Every course finishes with a feedback questionnaire.  Most have 5 or 6 questions, each asking for a rating and a comment.  They generally cover the venue, the material, the knowledge and style of the teacher and so forth.  I always looked forward to the last student leaving the room so I could check out responses. And, of course, I ignored every rating except the ones about my training :)  I didn't care if they gave the venue a 1, that was out of my control!

This year, I started to run my own SAFe courses.  I was still using someone else's material, but all of a sudden I was responsible for producing the workbooks, finding the students and choosing the venue.  And I paid attention to new things.  I discovered students cared if I put tabs in the workbooks (I never had!).  I found out how important natural lighting in the room was.  Ownership bred attention.

Inspired by +Bernd Schiffer, this week I decided to eat my own dogfood and start collecting NPS responses on my courses.  And I learnt some things.  Firstly, the value of setting the bar high.  I wanted an NPS of at least +70 - I got +33.  Having to call a 6/10 a detractor made me cry.  And those 8's made me scream!  80% is an 'A' in highschool for goodness sake.  The comments were full of praise, why couldn't they have made it across the promoter bar?

I have to tell you, I pored over those passives obsessively.  I read them each 3 or 4 times.  And they gave me the subtle hints.  The hints were largely about stuff I viewed as outside my control.  But accepting that boundary wasn't going to create promoters for me.  To create not just happy but delighted customers I had to care about everything and challenge my constraints.

Which leads me back to what I missed about NPS - the value of making everybody care about everything.  Looking at that one number is gold!  When you stop measuring the parts and just look for the delighted customer and the passionate team member shared ownership can't help but follow.

When is a SAFe PSI not a PSI?

Over the last couple of months, I have delivered the Leading SAFe course half a dozen times to a diverse set of companies and audiences.  Whilst some groups had already been investigating SAFe and some were seeing it for the first time, common areas of confusion emerged.

The 'Big Picture' is both a blessing and a curse.  It is wonderful that the whole Scaled Agile Framework can be distilled down to one compelling graphic.  It's also evident from discussion after discussion both online and in the training room that this graphic anchors people's understanding.  Much of the underlying flexibility in the framework is not evident in the graphic and thus missed by those considering implementation.

There is no case where this is so evident as in the concept of the PSI.  It suffers not just from the preconceptions established by the graphic, but from an often misleading name.

The PSI, of course, is the "Potentially Shippable Increment" at the heart of the program layer of SAFe.  It is conceived as a fractal on the team-level sprint, replicating the sprint lifecycle of "prioritise, plan, commit, execute, demonstrate and retrspect" on a program-scale of 8-12 weeks rather than the typical team scale of 1-4 weeks.

What many miss, however, is the motto of "Develop on Cadence, Deliver on Demand".  The PSI is intended to provide a mid-range planning and alignment cadence, not a delivery cadence.  Whilst the principles driving the planning cadence are grist for another post, I'd like to delve here into the delivery cadence.

There are three core delivery models for the PSI:

• Deliver after multiple PSI's
• Deliver each PSI
• Deliver when ready

Deliver after multiple PSI's

Whilst every seasoned agilist shudders at the thought, the reality is that many scaled solutions run 12-18 month cycles prior to delivery.  I often encounter this with solutions involving multiple enterprise-grade COTS applications (eg Siebel, SAP, Amdocs).  Reaching the technical maturity required to economically deliver incrementally on such a technology stack is quite a journey.

In this context, the PSI serves three main purposes:

• Avoids the feedback delay inherent in deferring integration testing by ensuring the features developed in each PSI are fully integrated and collectively represent a "potentially shippable increment" of functionality
• Provides a cadence for mid-range plan re-alignment through the collection of objective, fact based metrics on the PSI boundary
• Provides teams with a middle ground for the size of their backlog.  More than 1 sprint worth and significantly less than 25-30 sprints worth :)

I saw one major project emerge from severe and protracted pain simply by introducing PSI's.  With over 200 people involved, all new to agile, they had run for over a year rarely able to see more than 1-2 iterations ahead and with a massive accrued integration debt.  Further, lack of alignment between team level priorities caused constant rework and delays.  The introduction of 10 week PSI's gave them a vehicle to achieve aligned mid-range planning and progressive integration testing.  Whilst it was still no panacea, the tension level within the program changed significantly, collaboration went up, and they successfully deployed 3 PSI's later.

Deliver each PSI

This is the initial interpretation I see people most commonly make of SAFe, although in reality I've never actually known a train that implemented it.  At this point, of course, the PSI acronym begins to break down.  It is no longer a "potentially shippable increment", because it is in fact a "shipped increment".

The 'big picture' translates perfectly to this paradigm.  I select the features for my next (perhaps quarterly) release, plan, execute, harden and ship.  This model could be quite useful as an alignment tool for companies running enterprise integrated release cycles.  For example, the final sprint of the PSI could be utilised to perform cross-train integration testing before final enterprise deployment.

Deliver when ready

Everybody I speak to at least aspires to this model, and it is certainly the closest to my heart.  The delivery cycle is completely detached from the planning cycle.  Features are released as and when my business/customers are ready.  Of course, at this point the PSI is no longer a PSI.  We are now simply running a planning increment.

Inherently, deployments are something we plan for as much as anything else.  PSI remains a vehicle whereby the top priority features for the train are planned across the teams.  The deployment hardening and packaging activities and their alignment to planned delivery dates simply form a part of the planning.

Your delivery scenario can then be as complex or simple as required.  I know numerous trains wherein some features can be deployed weeknights, some only as part of planned weekend outages, and some only through integrated enterprise releases.

Conclusion

I like to begin with the end in mind.  In this day and age, regardless of scale and technical platform continuous delivery should be the aspiration.  For most scaled scenarios, however, the majority of companies cannot initially do so economically.

SAFe inherently provides the tools for all to move toward this model.  Every PSI, or every train, it should become more possible.  Start with "Deliver when Ready" as your mindset.  You may find another acronym interpretation for PSI helpful to reduce confusion with this - "Program Sprint Interval" has been a useful translation for many I train and coach :)

Coaching, Training and Change

I train, I coach and I facilitate.  At any time all three skillsets are at play, but the blend and balance varies.  Over the past year, I have become increasingly focused on mindful selection of that balance to suit the context.

In 2011, I delivered roughly 70 agile courses for an organisation embarking on an agile transformation.  Whilst it was rewarding to help so many embark on their agile journey, I became increasingly frustrated with being unable to accompany them.

Eventually, one of the groups I had trained engaged me as a coach.  It was amazingly fulfilling to journey with people, but I started to gain a new appreciation for the training room.  Whilst coaching enriches insight through context, breakthrough thinking occurs at a very different pace and magnitude.

In recent months, I've been balancing both training and coaching.  I've realised that I enjoy both and want to pursue an ongoing balance, but it's also provoked much thought about their respective roles in learning and change.  The recurrent themes are questions, answers and context.

For me, coaching is all about questions.  My coaching motto is drawn from Jerry Weinberg's "Secrets of Consulting":

"Your ideal form of influence is first to help people see their world more clearly, then let them decide what to do next"

This leads to a life of questions.  Questions for myself regarding the best models and visualisations to reveal new insights for my customers.  Questions for my customers provoking new perspectives as they seek answers.  Questions from my customers about when I'm going to start providing answers instead of questions :)

Training, on the other hand, is generally about answers.  My focus is providing answers and helping my customers internalise them.  The goal is to provoke questions about how they will take these new insights back to their own context.

As a coach, I constantly have to remind myself that no matter how clearly I believe I can see "the answer", the only answer that matters is the one my customer can see and believe in.  My hunt must inexorably be for the right question to which they can provide their own answer.  Being able to just pour new thoughts out in the training room is almost cathartic, but it can feel like a guilty pleasure as you know that most students are just not ready for all those answers.

This duality felt quite incongruent for a time, but Jerry Weinberg's experiential learning series helped me come to grips with it.  Repeatedly, he expounds on the fact that your goal is not to teach "the twenty things you believe your students must learn".  Instead, by providing a rich learning environment you give each with the opportunity to deeply comprehend the three or four ideas that are most relevant to them.  

Whether coaching or training, the innate goal is to provoke meaningful change.  All change, however, involves loss.  To take hold of something new, I must let go of something old - in many cases something I created and felt pride in.  Part of the magic of the training room is the change of context.  Solving a problem through the application of new techniques requires only the loss of the belief that I can copy my existing practices into the new setting.  I thus learn something more easily, and can then choose to bring that new insight (or some portion thereof) back into my own context.

A secret to learning, then, seems to be a simple cycle.  Step out of context, gather new insights, then select which to bring back into context. The change of context often also provides greater safety for shared learning.  A team will generally find it much easier to discuss how they might have worked together to solve a jigsaw puzzle than how they might have collaborated better in a stressful work situation.

This cycle can be utilised either training or coaching.  The difference lies in the depth of the step out of context.  As a coach, you tend to purchase an hour at a time as opposed to the two days you typically have in the training room.  My observation has been that the longer you are out of context the deeper you can journey into new territory.

In the excellent "Switch: How to change when change is hard", Chip & Dan Heath suggest that it is "essential .. to marry your long-term goal with your short term critical moves".  They go on to say "When you're at the beginning, don't worry about the middle, because the middle is going to look different when you get there.  Just look for a strong beginning and a strong ending and get moving".

Through providing many new answers in a new context (the community of the room), I believe training provokes the questions that establish the vision of the future that might be - the strong ending.  Coaching then begins where training leaves off, providing the "in-context" questions that help to find each strong beginning.

Scaled Agile Framework Applied 5/5 - Conclusion

What you see is all there is

I've just finished reading a book called "Thinking Fast and Slow" by Daniel Kahneman.  Set in the world of psychology and behavioural economics, it delves deeply into the role of cognitive bias in decision making.  The driving theme in the book is the division and interplay between intuitive response and deliberate reasoning, with a particular focus on the fact that the influence of intuitive response on our reasoning is far more pervasive than we realise.

A concept Kahneman returns to repeatedly is WYSIATI - "what you see is all there is".  In short, the vast majority of our reasoning is based on what is immediately apparent - unless something signals a warning sign that we should look deeper.

As I've been thinking through how to wrap this series up, one of the things I've been looking for is a "key takeaway" from my SAFE journey to-date - and as I finished the book a few days ago it struck me.

For me, the single most powerful aspect of SAFe is visibility.  Of course, lean and kanban practitioners will quite rightly suggest that this is not something SAFe contributes as the power of visualisation of work in progress (WIP) and flow has been central to lean for many years.  What I feel SAFe gives us, however, is a structure and an approach to providing both strategic and tactical visibility:

• At the portfolio level, I can visualise the WIP and flow of multi-million dollar initiatives, the application and ratification of my investment prioritisation and the distribution of these initiatives (or parts thereof) across my programs of work.
• At the program level, I can visualise the WIP and flow of significant features as they travel through my gating and funding cycles and are eventually implemented and deployed.
• At the team level, I can understand my flow in the context of the teams surrounding me.

At each level, I'm looking for different insights to support different decisions and generate different feedback.  What I need is an ability to provide a simple and clear enough depiction of the state of my world to enable solid intuitive decision making and ring the warning bells that will trigger deliberate reasoning at the right times.

Achieving this has without doubt been the most significant contribution of SAFe to the BI COE.

Does structure kill agility?

When I speak to agilists about SAFe (or read their blogs), there is a prevailing concern that it looks far too structured and formal and will kill off the empowerment, collaboration and innovation that Agile seeks.

The simplest response to this is to resort to complexity theory.  To quote Jurgen Appelo's Management 3.0 - "Without a boundary a system lacks the drive and constraints to organise itself".  Or in Glenda Eoyang's Facilitating Organization Change ... "Just as a person needs time and space to incubate thoughts before a new idea can emerge, a system needs a bounded space for the emergence of new patterns."

For a single Scrum or Kanban team, the principal is "just enough structure to enable innovation and feedback".  When you start to consider hundreds or thousands of people in hundreds of teams, "just enough structure" is a little more complex.  

I would contend that SAFe provides a structure and a set of constraints and boundaries that facilitates growth and change.  As the growth occurs, the formality and structure can be gradually peeled back to the bare essentials necessary to support effective participation in the enterprise lifecycle.

The challenge for the SAFe coach, of course, is guiding the tuning of the formality - recognising when it is both over and under constrained and assisting the group in selecting the right adjustments and collecting feedback on their impact.

What about the results?

At this point, it is too early to provide quantitative assessment on the impact of SAFe at the portfolio level for the BI COE.  It has triggered many changes which have removed waste and improved flow for the demand management group.  Two months in, the manager of the group felt he had recouped roughly two full-time employees' work by eliminating administrative waste.  This was supporting a shift of focus from "keeping up with admin" to "pursuing insight and improving strategic foresight".

For the Strategic Delivery release train, however, there are some hard numbers.  When she presents on their SAFe journey, one of the opening lines the general manager regularly uses is a quote an executive director issued about their group a few years ago - "they're the laughing stock of [enterprise] IT".

Following are her current metrics on improvements achieved in the past 12 months:

Average delivery cycle time down from 12 months to 3 months

Frequency of delivery increased from quarterly to fortnightly

Cost to deliver down 50%

100% of projects delivered on time and on budget

Happy project sponsors (NPS 29)

Happy teams (Team NPS 43)

My favourites are the last two.  For those not familiar with NPS, it represents "Net Promoter Score" - a system achieving growing popularity as a measure of customer loyalty.  Customers are asked a question along the lines of "On a scale of 0 to 10, how likely are you to recommend us to a friend or colleague?"  Respondents are classified as either a promoter (9 or 10), passive (7 or 8) or detractor (0 to 6).  The NPS score is then calculated by deducing the percentage of detractors from the percentage of promoters (eg 20% promoters, 70% passive, 10% detractor would yield a score of 20% - 10% = 10).  In the employee context, the question becomes "How likely are you to recommend working as part of Strategic Delivery to a friend or colleague"?"

I believe that whether or not you are cheaper or faster is important but secondary - whether or not you are delighting your customers/stakeholders whilst building happy teams is the true measure of your success.  Whilst there is no baseline measure on the "Happy sponsors" front, as she characterises it the baseline probably would have been somewhere close to -100.  When it comes to happy teams the baseline was -20, showing a massive shift for the positive in just one year.

Conclusion

My time coaching the BI COE came to an end a couple of months ago.  I believe any good coach has two missions - enable your customer's success and make yourself redundant.  As 2012 came to an end it became apparent my time was done and I moved on to fresh challenges closer to the heart of the enterprise.  It was hard to let go, and in my ways writing this series has been cathartic for me as I relived the journey.

Of course, it continues without me.  The GM of Strategic Delivery has become such a passionate believer in scaled agile that she flew out to the USA in February to join the ranks of Dean's certified SAFe consultants, and she's decided that since I'm no longer writing about her world she'd better start.  To stay in touch with the continuing journey of the EDW Agile Release Train, please visit her blog.

Scaled Agile Framework Applied 4/5 - In-play work and the program level Feature wall

In Part 3, we covered the program backlog lifecycle.  This post will focus on implementation life and feature level visualisation.  We have found that the key ingredients are:

• Visualisation
• Communication
• Cadence
• Continuous Improvement

Visualisation

Since visualisation is the enabler of so much else, it's where we'll start.  Finding the right way to visualise 'in play features' involved a series of failed experiments.

The first of these failures began with us saying "well, everything else follows a kanban system for visualisation why don't we build a feature kanban wall?"  So, we identified a set of lifecycle states for the feature and built the wall.  It looked great, but achieved nothing.  No conversations triggered, no insights generated, simply maintenance overhead.  We learnt two things: firstly that at this level our interest was more in a sprint based view than a lifecycle view and secondly that we needed a finer grain.

The third incarnation delivered the answer.  In large part, it was a logical extension of the 'PSI planning board' utilised to construct the overall view of the PSI during PSI planning in the standard guidance materials.

The wall is sprint/iteration based, and represents a rolling 10-sprint view of committed work in the teams.  Whilst the full 10 sprints are rarely populated, it is necessary to cover the 'long tail' on enterprise deployments.  The enterprise release process takes 5 sprints to conduct enterprise level shakeout and integration testing, during which time the team which built the work must maintain a typical 5-10 point per sprint capacity reservation to support testing and deployment preparation activities.

This is representative of a recurring theme throughout the lifecycle.  The ideal is, of course, to minimize the number of features in flight and run a lifecycle of "start feature, build it fast, acceptance test it and leave it in a deployment-ready state before starting the next".  The practical reality is, however, that dependencies outside the release train drive the pace at which any given feature can be developed.  In particular, negotiation and implementation of interface contracts and provisioning of sample data is a key timing driver - particularly when the external dependency is to a part of the organisation that's running waterfall.

Overall wall structure

• The columns represent sprints/iterations.  They convey dates for the iteration and also denote any deployment or other significant dates which fall within it.  On the image above you'll notice there's a public holiday in iteration 32 (the pink post-it) and a gateway checkpoint for enterprise release "1304" on the 28th of Jan.  Iteration 33, on the other hand, has an independent deployment window (on the pink post-it for 17th Feb), a gateway checkpoint for enterprise release 1303, and a code-drop into enterprise release 1302.
• The rows represent feature teams.  The scrum-master of the team is responsible for keeping the content of the 'team row' up to date.
• The "cells" represent a given team for a given iteration.  In the top left corner of each, you'll see the "Planned Velocity" and "Committed Capacity" for the iteration for that team.

A note on capacity planning and budgetting

The train runs on a "cost per point" model, derived by summing the run cost per iteration of the combination of APMS, Deployment Services and the feature teams and dividing by the combined velocity of the feature teams.  

Whilst this greatly simplifies the division of costs amongst active funding sources, it is reliant on confidence in velocity projections.  Thus, a particular velocity point is used for calculation.  As teams start to routinely exceed this velocity, a review cycle kicks in to determine whether the "planning velocity" can be uplifted.  When the train commenced operation, this velocity was 40.  3 months later, it was raised to 45, and most recently revised up to 55.  Shortfalls in individual teams are generally balanced out by overachievement in others, and by and large it works out with most epics coming in 10-20% under budget.

The other factor in planned velocity, of course, is planned leave and public holidays - which you'll see reflected in the planned velocities on the wall (quite varied with lots of annual leave during January in Australia).

Committed capacity (shown as "planned"), on the other hand, represents the "in-play" stories scheduled for the iteration.  Where this exceeds planned velocity, it is either a "red-flag" for risk or an indication that the team is expecting a good iteration.

What goes on the wall?

A card on the wall can be one of 4 things:

• A (green) "Discover card" representing discovery work on an epic (as described in Part 3).
• A (white) "Implementation card" representing implementation (or Evolve) work on a feature
• A (pink) "Defect card" representing a production defect
• A (blue) "Improvement card" representing implementation of an improvement

The Team/Iteration cell

The cards inside the cell represent the work the team has planned for the iteration.  They run at the feature level, and are tagged with a couple of extra pieces of information:

• How many points of work will be done on the feature that iteration (either on a post-it or in the top right corner on the card)
• A "completion flag" if that is the iteration when the feature will complete.

We experimented with numerous grains for this representation - both more detailed (ie what will be happening for the feature rather than just how many points) and less detailed (feature cards only go in the iteration where they will complete).  In the end, it was a tradeoff between how rich the information, how much maintenance overhead it required and how visually cluttered the space was (too much information obscuring what you really wanted to see).

Strategic Insights from the Feature Wall

Any wall is measured by the conversations it facilitates and the insights it generates.  We'll talk a little more about conversations in the next section, but some of the key strategic insights are:

• How far out is a team committed?  Where do they have capacity available and how much?  Very useful when looking at new demand and understanding the best team to take it on.
• What features are active in a given iteration and how much effort is planned against the feature?  One of the key uses of this is ensuring working agreements for availability of feature owners can be managed with good forewarning of the periods when they will be needed.
• When is a feature due to complete?  Very helpful again for ensuring feature level acceptance testing commitments have been established with feature owners.
• Where are we overcommitted?  Are teams confident or should we be looking at finding some stories from the feature that can be taken on by another team with capacity to make sure we hit our commitments?

Tactical Insights from the Feature Wall

The grain of the current iteration (shown in the photo above) is naturally more detailed than future iterations.  Expected information is:

• Iteration goal for the team (written on A4 at iteration planning, stuck on part of wall not depicted)
• Health-check for each feature (red/green/amber dots)
• Features where all planned work for the iteration has been completed (spanked tags)
• Features at risk ("Risky business" tag)
• Blocked Features ("Blocked by something" tag)
• Features where the feature owner is not living up to engagement expectations ("AWOL Feature Owner" tag)

Communication and Cadence

This may seem a strange combination, but in our experience very valid.  If you want a "self-organising program" rather than a group of teams, constant and effective communication is vital.  The trick is making it happen, and in particular helping people recognise the times when it's needed and the value of it.  What we have found is that the more we invest in "cadenced communication" the more we enable "constant communication".

At the time of writing, 2 primary forms of cadenced communication are well-established and 3 are in their formative stages:

• "Unity Day" - Train level sprint kickoff session described in Part 3.
• The "Daily Cocktail party" - extension of Scrum of Scrums
• Discipline Chapters
• Cadenced Backlog grooming
• Cadenced Retrospectives

Discipline Chapters

Inspired by this Spotify article, the chapters meet weekly with a mission of growing the maturity and consistency of practices in a particular discipline (eg ScrumMaster, data movement, testing etc).  For more detail, the referenced article is a great read.

Cadenced Backlog Grooming

I mentioned the trials and tribulations of backlog grooming maturity in part 3, and this is the most recent concept in growing maturity in the space.  The concept is to schedule synchronised backlog grooming sessions either once per week or once per iteration for each team followed by a review and update session with the train leadership group on the outputs.

Cadenced Retrospectives

This is targeted at improving the "Inspect and Adapt" feedback cycle.  A constant theme for the train is beating "siloed learning" and finding ways for teams to learn from each other.  In brief, all teams hold their retrospectives at the same time, then the iteration is closed out in a follow-up session facilitated by the "Release Train Engineer" where the scrum-masters bring the learnings generated from their team retrospectives and share with each other.

The Daily Cocktail Party

This is without doubt the key communication vehicle for the train.  On every morning other than the first day of the iteration, the first hour works like this:

• 8:45am - Leadership group standup at "release Train continuous improvement wall"
• 9:00am - Tech Lead standup (at A0 model of warehouse with tags indicating areas of activity).  Tech leads share on focus areas for the day, key technical challenges and inter-team dependencies
• 9:15am - All feature teams hold standups
• 9:30am - Scrum of Scrums at the Feature Wall.  Attending by Scrum Masters, entire leadership team, APMS, Deployment Services and other team members as required.  Scrum Masters speak to their current iteration cell on the feature wall and address the 3 questions for their team.  Leaders and project managers listen for blockers, issues and risks.
• 9:45am - APMS and Deployment Services standups.  Deployment Services include coverage of deployment related issues they heard at scrum of scrums while APMS balance their priorities for the day between moving card on the Program kanban and providing support for issues raised at the scrum of scrums.

There was considerable debate over the time commitment involved in this, in particular whether it should occur daily.  The investment has, however, reaped untold dividends. Not only does it provide superb visibility for senior leadership, but it triggers an immense amount of cross-team communication - "we've encountered that, we'll come visit and help" is a common catchcry.  

Continuous Improvement

From a continuous improvement perspective, you want three things:

• Teams figure out how to be become better teams
• The release train figures out how to become a better release train
• Teams benefit from other teams' learning and innovation.

The first is, of course, covered off by the team retrospective.  The other two, however, need attention.  Built into each team's capacity planning is a 10% reservation for "innovation and contingency".  Likewise, the leadership team builds into their time "10% for driving train-level improvement" through the function of team loco (introduced previously).

One of the keys here is treating improvement/innovation initiatives as first class citizens.  The leadership runs an entire wall dedicated to their initiatives, and innovations feature teams commit to appear as innovation features on the feature wall.

Examples of leadership team improvements might be:

• Introduce discipline chapters
• Introduce cadenced backlog grooming
• Engage with operations to negotiate simplification of the handover process and consolidation/simplification of support documentation

The most recent team level innovation initiative related to testing. Being a data warehouse, a significant proportion of the tests the teams wrote involved validating data integrity.  One of the teams looked at it and said "we build all those rules into our data model documentation, I wonder if we can automate it".  The result was to eliminate the need to implement basic tests that was consuming 30-40% of a team's test automation effort, freeing them to put more effort into feature level test automation and providing a roughly 3 point per team per iteration uplift across the entire train.

The trick, of course, is getting an innovation from one team in use by all the others - it takes time for the team that created it to educate/support others in implementing it.  So, we run an "innovation cup".  Inspired in part by looking at the trophy the Rally dev teams win for hackathons, we got Rally to sponsor a trophy to be held by the team with the most recent winning innovation.  To capture the trophy, a team not only needs to implement a good innovation but they need to have at least one other team who has implemented it successfully.

Conclusion

Prior to the introduction of the Release Train, the primary management vehicle for the program was a weekly 3 hour management meeting attended by program attended by program management, release management and project managers.  It was supported by a 40+ page status report, and was often entirely disconnected from what was actually happening in the teams.  It was followed 2 days later by a "senior management' program status meeting which ran another 2 hours dealing with escalations from the main meeting.

Both meetings are now entirely gone.  For archiving purposes, the status report is still produced (as a Rally extract) but the knowledge of "what is really happening" comes from the "cocktail party" on a daily basis and the standard sprint ceremonies.  Most importantly, the leadership group no longer have "managing the teams" as their primary mandate - instead they focus on finding the right way to support the teams in delighting their stakeholders.  Status and planning discussions simply look at the question to be answered and pick the wall with the right grain to support the discussion.

In Part 5, I'll wrap the series up with a look at some of the quantitative results and key learnings from this group's journey into SAFe.