SAFe Release Planning Tip 4 - Consider "Feature Breakouts" as well as "Team Breakouts" if you have component teams

SAFe proposes a number of team flavours.  All are cross-functional insofar as they are able to "Define, Build and Test a thing of interest".  The suggested "things of interest" are:

• Features
• Products
• Components
• Subsystems
• Interfaces

Realistically, the flavours can be further condensed into either  "Feature" or "Component".  A "Feature team" can fully deliver a "Business Feature", whereas a component team can typically only deliver "technical components of a Business Feature".  On the other hand, component teams can quite often fully deliver "Architectural Features".

Countless books, articles and speeches have been devoted to the benefits of Feature teams, but the reality is many if not most trains will launch without them.  Most will contain a mix of "psuedo-Feature teams" which can nearly deliver a business feature and supporting component teams.  Typically, 3 factors contribute to the presence of component teams:

1. Insufficient people with a given specialisation to provide one for each team
2. Technical and environmental constraints 
3. Lack of conviction of the benefit to aligning at the team level around valued outcomes rather than technical proficiency

The net result is that the vast bulk of features will require contribution from more than one team.  Typically, the "pseudo-Feature" teams will take ownership of business features and look for contributions from the component teams.  The component teams, on the other hand, will often take ownership of architectural features and expect to provide contributions to the business features.

In the context of SAFe release planning, this can all too easily create the following scenario when the Team breakouts start on the afternoon of day 1:

• From 1:00-3:00 the "psuedo-Feature" teams work with their product owners and managers to understand the business features they are tackling and break them down into stories.  As they work, they identify needs they'll have from the component teams and assumptions as to what form they'll take and they place these in a pile ready to hand over.  They may visit the component teams during this time, but are likely to be given short shrift as the component teams are deep inside "their own features".
• From 1:00-3:00 the "Component" teams work with the architects on the architecture features in the program backlog and break them down into stories.
• From 3:00-4:00 the feature teams land on the component teams with a pile of stories they need estimated and scheduled.  The component teams, with little understanding of the context, look at the stories and say "they're wrong, we're going to need to rewrite them" .. while the feature teams say "but we need you to estimate and schedule them so we can lock in our plan".
• At 4:00, the draft plan review exposes a litany of unvalidated assumptions and bottlenecks around interactions between the feature teams and the component teams.
• On Day 2, the feature teams and the component teams work together to translate the feature team needs into technical stories for the component teams to deliver .. with the product managers and owners relying on the feature teams to represent their needs as they've "already conveyed the business context and don't understand the geek-speak".

What I suggest is to both leverage flow-based planning as described in Tip #3 and different types of breakouts.  As part of your program backlog preparation, identify the features which are heavily interdependent across teams.  When choosing the priority order for planning, consider planning these features first.  Inevitably, you will wind up with a plan where the scheduling of these features dominates and the more contained features are scheduled opportunistically into the gaps left.

When breakouts commence, rather than going directly to team breakouts go to feature breakouts.   Your "pseudo-feature" teams pull features, and collect representatives from each component team to join them for the initial breakout.  The focus of the feature breakout is then:

• Establish shared understanding of the feature
• Elaborate any further feature acceptance criteria as necessary
• Break the feature down into team-based stories with high-level acceptance criteria
• Identify key dependencies between stories that cross team boundaries.

Once the heavily interdependent features have each been through their feature breakout, return to team breakouts - with team members taking their stories with them.  Once back in the team breakouts:

• For each feature from a feature breakout:
• Members share the stories created during the feature breakout with the rest of the team, obtaining further clarifications as necessary
• Estimate as a team
• Load stories into sprints in-line with inter-team dependencies
• Close the feature out on the program board
• Progress through feature breakdown and planning for remaining features team owns. (Those with little or no dependencies on other teams).

Personally, my experience with trains containing a mix of feature and component teams has been that you wind up with features which are "rocks" and "pebbles".  Those features which span multiple teams for delivery tend to be the rocks that dominate your PSI plan.  Once you have these, you find the more contained "single team features" become the pebbles that are slipped through the gaps in your PSI left after the rocks.  Making sure you bring a mix of "rock and pebble features" into the PSI priority list is the first enabler, and adjusting your breakout structure can become a huge time saver both within PSI planning and execution.

What's next?

• Tip #5 - Normalised story points don't tell the whole story - know your capacity constraints
• Tip #6 - Every breakout deserves a good facilitator

SAFe Release Planning Tip 3 - Plan with Flow

In Tip 2, we covered the first morning of the SAFe release planning event - establishing the vision for the PSI and starting the whole train on the same page.  Our objective for the remainder of the day is to produce the draft plan.

I believe a crucial aspect of the release planning mindset is to view the event as an investment and execute with a view to maximising value delivered.  The primary value to be delivered by the draft plan is to reveal the challenges in the vision and support effective trade-off decision making in the management problem solving session.

We know from Reinertsen that the key to maximising value is flow, and that the key enablers for flow are:

• Reduce batch size
• Get fast feedback
• Actively manage queues
• Limit WIP

Now let's travel to reality.  You're at the first PSI planning for your new release train.  The following is almost certainly true:

• You have "newly formed" teams, which have not yet gelled
• You have an optimistic "wish list" of features to be delivered
• Your features are not particularly well elaborated
• Your teams are almost certainly a blend of "nearly feature" and "component" teams
• You have 100+ people in the room who are not entirely certain how it's all meant to work
• You've created a "program board", and everyone understands the theory of what it's meant to be but nobody is really sure how it's going to come into being

You're entering 3 hours of "team breakout" time.  The overwhelming temptation is going to be for each team to enter the "silo zone", nervously attempting to create their own plan.  They're going to be worrying about the herculean task of breaking out and estimating all their stories in the time box. Any attempt from other teams to interact with them will be viewed as a distraction killing their "planning velocity".   In essence, you have every possible ingredient for killing flow.  Minute by minute, the queue of unresolved "inter-team assumptions" will grow.  The "Batch size" for integration of planning outputs will become herculean.  Feedback will be measured in hours not minutes, despite the fact they're all in the same room.

The risk you run is that all plan integration will occur in the last 30 minutes before the draft plan review.  The review is in peril of becoming a litany of "we haven't yet validated our assumptions regarding our dependencies on component team x".  The reality is that this period is meant to reveal your integration bottlenecks.  If all your teams were capable of working independently, they wouldn't need the Release Train construct in the first place.  How can you facilitate effective management trade-off decision making if you don't understand the inputs to the tradeoffs?

The answer is to "apply flow".  Create a feature planning kanban with explicit WIP limits.  Support your teams in creating integrated plans "feature by feature".  Create a visible pull system.  As a team pulls a feature into active planning, they can summon the domain experts to their table to support the breakdown of the feature into stories.  Your plan will naturally evolve consuming train capacity to implement your highest priority features first.  Plan integration will become "small batch" as teams look to validate their dependency assumptions and populate the program board feature by feature rather than in a massive "end of day rush".

Below is a sample Feature Planning Kanban board.  As a feature is pulled into active planning, it enters the "Writing Stories" state.  Teams on the train each have avatars (indicated by the coloured circles on the diagram), and teams involved in the feature attach their avatars to it.  This provides a living view throughout the event on which features are where in the planning cycle and which teams are involved in planning each.  The "Adjusting" and "Finalising" states are utilised for Day 2 planning adjustments.

The result will almost certainly be that you haven't broken down all your features into stories at the end of the first day.  But you will have high quality integrated plans for your highest priority features.  You'll see where the bottlenecks are.  In essence, you will have planned the "big rocks".  Management problem solving can then focus on how to select the best value "pebbles" to fill the gaps.

Along the way, you will have limited the number of features being planned at once (Planning WIP).  Your queue of unvalidated integration assumptions will have been actively kept small by ensuring features are fully planned before pulling new ones.  Feedback will be fast.  And you'll have avoided the "end of day scramble" to populate your integrated plan.

What's Next?

• Tip #4 - Consider "Feature Breakouts" as well as "Team Breakouts" if you have component teams

SAFe Release Planning Tip 2 - Avoid "Death by Powerpoint" on the first morning

The suggested agenda for the SAFe Release Planning Event runs the first morning as follows:

• 08:00-09:00 Business Context
• 09:00-10:30 Vision and Prioritised Features
• 10:30-11:30 Architecture Vision and Development Practices

It's a sound 'scaled facilitation' approach.  Spend time as a large team establishing strategic motivation and context before fragmenting into smaller breakouts.  But there's a catch.  You're starting your high energy release planning event with three and a half hours of trying to keep 120 people awake through a series of powerpoint presentations!

Before tackling the temptation to sleep, let's sidestep for a moment to talk about this series of briefings.  The purpose of the release train is aligning a group of teams to a common vision.  The purpose of the PSI planning event is to produce an aligned plan.  The foundation of the House of Lean is Leadership, and the first morning is the opportunity for the leadership team to lead by example with an aligned vision.

By the time you work through the entire briefing, you probably have 6-8 people contributing.  It begins with the executive delivering the business context, progresses to the sponsor of the release train delivering the vision then travels through the various product managers, the system architect and the development manager.

When a team prepares a major presentation to a group of stakeholders like that, they prepare a skeleton, create individual contributions, come together for assembly and rehearsal, critique flow, polish and polish.  They're desperate to ensure a logical progression, cohesion, a clear start and a clean end.  On this morning, the stakeholders are the teams and it's the leadership group preparing the presentation.  The teams deserve no less care and attention from the leadership group than vice versa.  Don't fall for the temptation to divide up the time, work individually and delegate an executive assistant to stitch the submissions together into a single deck the day before the event!  Make sure you demonstrate your alignment in the briefing.  Don't overlap with each other. Don't give conflicting messages.  Don't follow context with context.  Make sure the briefing has flow!

Now let's talk about sleep.  The key here is to think about interaction.  Craft the briefing as an interactive event.  Build in question and answer time to each feature.  Think about how to bring it to life.  Just as a team preparing for a Sprint review does not simply want to demonstrate their software but create space for feedback and clarification, you should think of the briefing as a review of your strategy.  Think about how to bring in something other than powerpoint.  Can you capture videos from your user interviews?  Can you demonstrate competitor features?  Could you do it entirely without powerpoint?  Should you break it up at some point with an agile game?

Don't get me wrong - this tip is not "kill the briefing".  I know I've heard numerous people suggest just going straight to the breakouts, but that would sacrifice something essential.  If you want your release train to feel like a "self-organising program" rather than a bunch of "self-organising teams", you need collective ownership.  This is nigh on impossible to achieve if teams don't know what other teams are building and why.  It's also a chance for everyone to get feedback on how users/customers are responding to what the train is shipping.   Finally, surprising synergies may emerge, to seed great conversations once the smaller breakouts begin.

I'll close with one final hint.  If you have too many features to talk about each one in depth, you have too many features!!

What's Next?

• Tip #3 - Apply Lean Principles to the Planning Event - Plan with Flow

SAFe Release Planning Tip 1 - Execute your launch as an Agile Project for the Leadership team of the Train

When it comes to launching a train, the SAFe material talks a lot about the "Quick Start".  It's the 1 week "all in" launch process, which basically looks like this:

• Monday and Tuesday - all teams trained together in SAFe ScrumXP
• Wednesday and Thursday - Release Planning Event #1
• Friday - Specialised Breakout training for ScrumMasters and Product Owners.

This is the packaged, high energy launch week Dean and the guys at Scaled Agile have rolled out again and again over the years as they launch trains.

What's not really covered, however, is the pre-work that goes in to making sure that week will be successful.  At SPC training, a whole day is spent on the launch process .. but still, the material there is heavy on how to run the quick-start and light on how to prepare for it.  This, of course, is the space in which the experienced consultants are meant to shine :)

The pragmatic reality is that (in my experience at least), there is 6-10 weeks of solid work to prepare for this.  Whilst the first PSI planning event is really what gives birth to the ART, I think of this time as the gestation period.  Some people may do it faster, but the most recent train I helped launch did it in 6 weeks and they were very very hectic.

My personal belief is that this is the perfect time to start to lay the foundation for success, and the foundation of the Lean House is Leadership.   It's an ideal opportunity for the new train's leadership team to conceive and execute on the launch as an agile team delivering an agile project.  This post from a couple of years ago covered some of the fruits that emerged the first time a team I was coaching took this approach.  I believe the benefits are three-fold:

• The success of the launch is owned by the leadership team rather than the consultant
• The leadership team gets to learn Agile by doing it themselves
• The leadership team gets Fast Feedback on their project as challenges and triumphs emerge at the PSI Planning event

The approach is predicated on the following sequence of events once you have "found your train":

• The leadership team of the train does the Leading SAFe course together
• This is followed by an inception or visioning workshop where the launch backlog is created
• The leadership team executes on the launch backlog over 3 to 5 2-week sprints
• PSI Planning occurs

Leading SAFe

This is the 2-day SAFe course designed for the leadership group of a release train.  There are two ways of approaching it.  The temptation for many is to bring the IT leadership group in for training, then have them "evangelise to the business".  However, for me this misses a golden opportunity.

Agile success is predicated on strong cross-functional collaboration.  Traditionally, we look at cross-functional as "devs, testers and BA's" - at scale, our cross-functional leadership team involves sponsors, product management, architecture, operations, delivery and other stakeholders.  Learning together is a powerful kick-start to shared understanding, take the opportunity to bring your cross-functional leadership team together for the Leading SAFe course.  The discussions will be far richer, and early alignment far stronger.

I also make a slight variation to the course in this context.  I like to finish with 30-45 minutes where the group works together to generate a set of key insights and ways in which they are convicted change needs to start.

The Visioning/Inception Workshop

Ideally, this should occur within a week of the Leading SAFe course.  The objective is to create a vision and a backlog for the launch preparation activities.  Participants should be some or all of the leaders who attended Leading SAFe.

My first recommendation here is to live by the SAFe mantra "Fix the date, float the scope".  Set a Big Hairy Audacious Goal for the launch date.  If it doesn't feel slightly uncomfortable, it's not ambitious enough.  Whether you take 6 weeks or 6 months to launch, the train won't really start learning and growing together until they're all in the room for that first PSI planning event.

In terms of how to structure this workshop, it really depends on how you like to facilitate.  Every SPC gets a "PSI readiness checklist", and one approach would be to use this as a foundation.  Personally, I'd rather the team generates the plan themselves.  My latest (and favourite) structure for the workshop progresses through a series of questions:

• Where did we leave off?
• What will success look like?
• What could go wrong?
• What needs to be done?
• How will we do it?
• When will we do it?
• What are the next steps?
• What did we learn in this workshop?

The material for "Where we left off" is a recap of the final take-aways they generated in Leading SAFe.  For the rest of it, it's flip charts, post-its and your favourite facilitation techniques.  I keep a big picture of the PSI planning "inputs/outputs" visual on the wall, and inject 4 framing themes into "what needs to be done?"

• Program Backlog
• Team Formation/Preparation
• Operating Model
• Logistics

You should exit the room with a vision, a well-formed backlog prioritised into sprints, and an agreement for leadership team cadence executing on the backlog.

Executing on the launch backlog

You now have a backlog full of stories about booking venues, grooming the program backlog, forming and training teams.  Hopefully, you have a leadership group excited about working together as an Agile team to deliver those stories.  Most likely very few of them have ever actually done so.  Now it's time for them to learn Scrum by doing, ably served by the Release Train Engineer acting as the scrum-master.  Sprint planning, stand ups, backlog grooming, showcases (to the teams of course), retrospectives and a kanban wall are the order of the day.

Some of the things to look for:

• Shared understanding forming across leadership silos as they plan, execute and retrospect together
• The team understanding the way a backlog "responds to change" as they learn the flaws and gaps in their launch plan as they execute against it
• A real understanding of "MVP" emerging as the PSI planning date nears and the team makes hard priority calls about "what really has to be done to be ready" versus "what would have been ideal".
• The team understanding the value of dedicated teams as they struggle to make headway against the distractions of their "BAU work".  This is often demonstrated by a near zero velocity in the first sprint.
• Transparent lean leadership in evidence as the team showcases their results to the teams on the train-to-be.

PSI Planning

The event itself is the subject of many posts to come, but in the context of the "launch project", I have one extremely strong recommendation.  Very soon after the Release Planning occurs, the leadership team needs to run an "Inspect and Adapt" against their launch plan.  This sets the scene for the preparation for Release Planning #2.

What's Next?

• Tip #2 - Avoid "Death by Powerpoint" on the first morning

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.