Bias From The Bottom: A Different Way to Bootup a SAFe Train

About this Publication

Many agile transformations, and most SAFe rollouts start with executive leadership sessions, and then creation of training and coaching to move changes down and across the org. In this report, we’ll share a different approach taken by two coaches – Curtis Michelson and Steve Adolph – who got the blessing from leadership to try a different bottom up approach. The coaches offered to work with teams just where they were, and help them chart their own path towards scaling agile but with clear executive oversight and team accountability.


This report is a case study based of events spanning 4 weeks in August of 2018. We were engaged to provide training to a struggling enterprise IT group of 48 people, roughly 5-6 teams. Our client was a North American business unit (based in Portland, OR) of a larger multinational conglomerate in the vehicle design and manufacturing sector. The teams we were training were all part of the company’s telematics [1] effort.


Curtis Michelson had previously conducted training for some teams at the firm that were outside the telematics group. When he inquired about which teams were yet to be trained, he was told the telematics folks needing re-training and that Curtis would be the one to do it. Digging a little further, he learned that despite learning basic Scrum the year prior, the telematics group had to date executed 21 two-week sprints with no real product or delivery to show for all their effort. Leadership was concerned and frustrated. Upon some further inquiry, it surfaced that these struggling teams were made up of software groups, hardware and firmware specialists, and other related disciplines with roughly 5-6 specialty areas (we say ‘roughly 5-6’ because they had not formally defined a team of teams structure and many people wore multiple specialty hats). “Sounds like a scaling problem to me” said Curtis to his corporate handler. “What’s that?” she asked.

Thus began an important early set of conversations which signaled to management that this group was not like the others and some special training on organizing teams of teams was required. In these early calls with management, Curtis offered to be framework agnostic and suggested DaD, LeSS or SAFe as valid starting points. Local management chose SAFe because it had been employed at the company’s headquarters in Europe. Curtis, not being a SAFe certified trainer reached out to a peer Steve Adolph to help. And thus the two of them were engaged to not only re-baseline agile terms and techniques but also to stand-up a coordination layer for the team using SAFe. We were given 3 weeks to prepare and 1 week to deliver the training.

SAFe offers superb guidance for rolling out SAFe in an organization. Once an organization reaches the point where they realize they need to do things differently – sometimes referred to as the tipping point – the implementation roadmap recommends intense leadership training. After all it is the leaders who need to champion and lead the change. No matter how we want to beautify the language with terms like “servant-leader” this is still very much a top down approach where “leadership” sells the approach to the teams. Our client being both more egalitarian, and fiscally prudent, opted to forego the weeks of leadership training and just start with a week in the trenches with the teams. Thus, this became a bottom-up approach where the teams would sell the approach up to leadership. This meant the people who the change would affect most, needed to buy into the process.


All good training, coaching, or consulting begins with listening to the client to truly understand their current state of pain. Over the course of a couple weeks, Curtis ran a survey using to probe mainly for qualitative data and to hear what was happening in the team member’s own voices. This was followed up by seven one-on-one 45 minutes interviews with team members, dev managers and senior leaders. The survey questions themselves probed for ‘where it hurts’ and sought to understand the organizational impediments and to show the underlying dependencies and coordination issues.

The results from these two rounds, especially the 1-on-1s, were a treasure trove that gave us just enough early insight to feel confident we didn’t need elaborate SAFe training decks, and that these Portland-based engineers and managers were up for something a little more creative and different. This was mainly signaled to us by their extraordinary candor. Very upfront about the real issues and pains, like the CIO getting publicly embarrassed when a full press demo event went off the rails because the latency in their system prevented the telematics from working. Ouch. These kinds of private conversations are leading indicators to coaches and consultants of a client’s willingness to be real and to meet you in the arena of empiricism, not just following a plan or program because others have done it. The last pre-work artifact we created was a document called “The Gap” which was a series of short answers to the question “What do you believe limits Telematics’ ability to get the right features to the market in a reasonable time?” This early feedback is in Appendices “Qualitative Surveys” and “The Gaps” below.

Probably the best anchoring graphic, which we plastered on front of each day’s handouts, was this word cloud (generated from our survey data) and the most important word popping out “alignment”.

To satisfy the client needs we drew from our personal content libraries and created customer specific on-site training. The initial agenda was planned with a Monday kick-off session with all teams and upper level leadership. Each day we had specific training goals and exercises. This led up to a scheduled playback session for upper leadership on Friday afternoon. The intention of the Friday afternoon session was for the team to “pitch” the scaled agile approach they wanted back to leadership. This last part, having a playback session created just the right pressure cooker for learning because everyone knew that come Friday, the bosses wanted to know what they learned and how the team wanted to (or not to) implement SAFe. It was as if Friday would be the sprint demo and the customer was coming. More of that beautiful outcome from Friday below.

Here is what we anticipated we would deliver:


To paraphrase military thinker Helmut von Moltke, “no plan survives first contact with the enemy”, or this case no agenda survives its first contact with the class. With our focus on our Friday goal, each day we would inspect and adapt the agenda based on our learning from the day. What did the class really need to learn to advise their management on how they wanted to move forward with a scaling strategy and if SAFe would be the foundation for their scaling strategy. Here is what really happened over each of the five days:

4.1        Monday

Monday Morning . Monday morning we reflected back to our audience what we learned during the pre-interviews and validate our conclusions with them. This created alignment on what the problem we were trying to solve was.

This was presented to the upper level executive who attended Monday morning. We then invited the upper level executive to align everyone by explaining the business context for this business unit. Finally, we “dismissed” the executive team and invited them to return Friday afternoon for a debrief on the approach we wanted to take to resolve the issues. In short, SAFe adoption was not a slam dunk. The team would advise the executive on the approach they wanted.

A superbly powerful and eye-opening use of information radiators was asking the teams to create a clear visual map of their dependency problems. We simply wanted to know who really depended on whom. We had them model their current project teams and then asked individuals to:

  1. Write their name on each project they were on, and
  2. Connect each instance of their name with a piece of red string to show how tangled the inter project personal dependencies were. It was not a pretty site and quite an eye opener… people now really understood what BVIRs were.

We demonstrated fundamental Lean and Agile economics using two classic exercises, “We’re having a party”, and “the Penny game.” We heavily modified both games to demonstrate the economic points, small batch, rapid delivery of value, and the importance of rapid feedback and learning to creating value. We received extremely positive and useful feedback from these modified games.

Monday Afternoon. The afternoon was all SAFe. We only used content either from the SAFe website or SAI’s “Introducing SAFe” course which is open for all to use. Whatever your opinion of SAFe is, the “big picture” makes it quite easy to walk people through the framework. We actually discarded the “introduce SAFe” deck and just spent the afternoon walking through the big picture together. It was an awesome interactive conversation. This is where SAFe’s website really shines because it makes it very easy to do this sort of interactive dialog. We used this interactive dialog also to inform the executive leadership how we would work through the week using SAFe to help resolve the issues surfaced by the assessment.

4.2        Tuesday

We were planning to spend half the day on the SAFe content model (Epics->Features->stories) and then the afternoon as a Scrum/Kanban refresher. What really happened is we spent 90% of the day on Portfolio management – Embrace Change! The participants just grabbed onto the Portfolio Kanban, the whole intake process. We took their live “Epics” (initiatives) and rewrote them using the SAFe Epic Hypothesis format. An epiphany for the participants came with the concepts of the Minimal Viable Product – MVP. innovation accounting, and leading indicators.

On the fly, we dynamically created a portfolio meeting exercise where participants evaluated Epics in the “funnel”, “review”, and “analysis” stages of the canonical SAFe Portfolio Kanban. Real life was happening then and there. Another epiphany came with WIP limits on the stages – don’t start all the work at one time. In other words, stop starting things and work to get something done.

We also introduced the concept Weighted Shortest Job First (WSJF) – pick the low hanging fruit as a tool for ranking Epics (initiatives). As we discovered later, this part of the course brought super high value for the participants. The ability to start thinking about initiatives in terms of their economics and value constituted something of a mental turning point for them.

We did manage to spend a couple of hours on Scrum and Kanban… that was what we were originally supposed to do for the team. But we took a page from Sharon Bowman’s “training from the back of the room” and conducted it using a “fact or myth” game to review facts and myths about Scrum. This little game engaged everyone and forced people to really think about what did they really know about Scrum and Kanban. What we discovered is there really are a lot of myths floating around both Scrum and Kanban. We also made Scrum and Kanban videos available to the teams.

4.3        Wednesday

Of course, things were going way too well for us, and on Wednesday like a Greek tragedy the storms rolled in. It was a tough day. Our original agenda called for PI planning readiness on Wednesday but we had poorly defined teams. Many people were on multiple teams as was so dramatically demonstrated by Monday’s red string information radiator exercise. They were mostly organized as “component” teams. We explained the concept of ‘feature teams’ and offered them trade-offs between the two. Then the teams were asked to experiment with new team configurations, and walk some work through them.

This got, shall we say, a bit emotional as many sacred cows were gored including some team leaders suddenly discovering themselves “teamless”. While there was a lot of frustration, the workshop provided a safe (no pun intended) place for people to say what they were feeling on this issue. This was everything constructive healthy conflict should be, hard, messy, and productive. We made some progress on team organization even to the point of being able to pick a naming theme for the teams – Snakes….and of course no one could resist the idea of “Snakes on a Train”. Their manager was not happy with the naming convention because he is terrified of snakes.

While the team organization issue consume most of Wednesday, we managed to cover story writing – especially the theme of “putting the story back into user stories” This is something of a personal hobby horse for Steve after observing how often user stories at many of his clients have deteriorated in some cases to 30 page tomes that are thrown over the fence to a dev team. We also went through story points which we explained using the “Dog Points” exercise.

Wednesday is often referred to as “hump day” because it’s the middle of the week, everyone has been consuming their mental energy they gained from the weekend, and now after nearly 3 days of intense workshop, participant energy levels were really beginning to flag. Curtis helped pick up the energy that day with a wild rock-paper-scissors activity which we took outside as it was probably one of the few Portland days with clear skies and sunshine and cool temps.

While seemingly simple, the purpose of the Rock, Paper, Scissors exercise was to demonstrate teams as autonomous, stable, intrinsically motivated units. All the while remembering to keep a certain amount of individual difference and even conflict in play. When disagreements are settled, they are settled, and we become an army of one again. To illustrate this, Curtis had 48 people start playing rock paper scissors (24 pairs). The 24 winners of the first round went to re-pair into 12 competitions. The process proceeded down to the final two. The twist is, after each round, the losers must become the cheerleaders and supporters of the one who beat them – and not just idle cheerleaders, real full-throated, rowdy and raucous ones. Half the corporate campus came over to see what the commotion was all about and became engaged in the cheering. The activity also underlined several other important social concepts, get out of the building, take breaks, and monitor energy. Team energy and morale after all is a leading indicator of success for product. No great product was ever created by a demoralized team. Monitor it, measure it, radiate it, build a board for it, was the takeaway.

4.4        Thursday

Thursday the teams began building their backlogs for a sample or simulated “PI planning” session Thursday afternoon. We managed to get a workable team organization (settling on component teams and one feature team), explained PI objectives and built a first Program board.

Thursday afternoon was intended to serve as our “first breakout session” of the PI planning agenda. We had gone through the business context, product vision steps earlier in the week. The session was very rough around the edges but people really understood the intention behind the program board, and the PI objectives. We had a good draft plans presentation.

People really grabbed onto the program board, because from their point of view it would be a huge solution to many of their alignment problems. Most importantly it would end what we often call the game of chase, that is chasing down the overworked people during the PI that you are dependent on, only to discover that your lack of planning is not their emergency. We also introduced the “Rule of 3” with which relates exponential increase in decision-making time to how far geographically the decision makers are separated (co-located, same building, same city, different country).

4.5        Friday

We decided there was no value to continuing with the second breakout for PI Planning. Rather we decided to bring the business conversation back and to spend the remainder of Friday developing our management “pitch”. Our approach therefore was for the participants to pitch what they had learned and their recommended next steps to their executive. It was for them to say whether they wanted to pursue this approach or not. They rose to the challenge brilliantly.

First we explained what a pitch is and even used Dean Leffingwell’s SAFe pitch video as an exemplar for constructing a SAFe pitch. The participants broke out into groups to construct their part of the pitch. Some created the overall pitch, the problem, the solution, and “the ask”. Others dove into how what we learned during the workshop would help solve the problems we identified Monday – how Epics/Portfolio Kanban, PI Planning, Team organization, Flow, Fast feedback, and system demos, would create the alignment and visibility we needed. The ultimate was when several groups performed “before and after skits” acting out examples of how work does not flow now, and how it could potentially flow in future. This was a sort of live action version of a “postcard from the future”. One of the execs in the audience was actually one of the characters getting skewered! And laughed about it! Needless to say, Friday afternoon was the highlight that capped the week.

It should be noted that not all of this variation and improvisation was a total goat rodeo. We were contractually required by the training company to create printed course handouts for each day. We accepted the fact right away that the handouts would get ‘out of synch’ with the materials we might pull in for any particular day, and we let the students know that upfront. Nobody seemed to mind. We were able to deliver what they really needed to get their job done rather than what they thought they wanted.


This approach required a coordinated just-in-time collaboration between the coaches and sometimes a bit improvisation. As coaches leading the workshop, we held nightly re-planning meetings, and frequent verbal check-ins with managers (how we doing here?, what’s the vibe?, why is that person’s body language so negative?, etc.). The nightly sessions let us make adjustments to the focus for the following day. It was classic ‘use agile to teach agile’. Our goal was to model the agile behaviors we were teaching, such as transparency, feedback, learning, and courage. A morning agenda conversation with the class was often in the form of “Hey guys, Curtis and I re-considered the plan and thought this would be better today, you agree?” We also consciously worked as a paired team, to model good collaborative behaviors and even demonstrated managing conflict by having friendly coaches disagreements in front of the class.


As the week progressed, some clear group leaders and design patterns began to emerge. The person who was voluntold to be the Release Train Engineer (RTE) went from terrified on Monday to more than willing to try and fail and learn by Friday. Team re-factoring (components vs services vs features, etc.) was the most touchy and conflict laden but by opting to not firmly settle the issue and just create an “experiment”, we kept momentum, rather than going down a rabbit hole.

7.     AND, THE RESULTS ….

Participants told us this was the best training they had ever received and that it was fun to watch the interplay between Steve and Curtis and exciting to know each day might go a new direction. Again, this is Portland, Oregon and this west coast group might be more chill about such things. But for this group, it was a good fit. The leadership purchased food and drinks for all on Friday afternoon to celebrate our plan for moving forward.

By last count they were well into their 3rd PI and still gaining traction and delivering product.


Bookending the training with executives keeps everyone on point: The decision to have leaders come in on Monday and Friday was key – this was analogous to a sprint planning session with the product owner on Monday and the sprint review on Friday. No question that this may or may not work in some companies where ‘what can be said in the free and clear air’ is constrained. But this company seemed to have a fairly open culture and we harnessed that to establish 2-way links of accountability between the teams, their managers and the upper leadership. Each had their role. Leaders to give the teams space to experiment and come up with their own SAFe implementation, and the teams to do the work and share it back, which they did with aplomb. This approach naturally made it possible to build a SAFe train up from the bottom, letting the teams themselves pull the elements that made sense for them.

Just-in-Time Resources Keep Things Fresh: Over the course of the full week, rather than running through our prescribed set of training decks, we moved on and off script and supplemented our teaching by offering a buffet of agile and scaled agile resources to meet the needs of our participants. To make this easy, before arriving on site, Steve and Curtis created a DropBox folder full of our favorite case studies, scrum and kanban games, movie clips, cartoons, juicy quotes and other resources that we can pull from as needed. For a sample of some the buffet items see Appendix “Training Buffet”.

MultiMedia (movies) makes great supplements: The David Marquet video around agile leadership and the “backwards bicycle” videos, as well as a few choice selections from Dean Leffingwell and Jeff Sutherland, interspersed throughout created a nice visual break from slides or just hearing from the two talking heads in the room – Curtis and Steve.


Steve and Curtis wish they could publicly thank the teams they worked with for this project but the company requested to remain anonymous. For all of you in Portland, and you know who you are, Keep Portland Weird! And keep rocking on. We also thank Rebecca Wirfs-Brock for her help with this piece and her patient understanding with these two coaches’ hectic schedules.


[1] Telematics,


APPENDIX – Qualitative Surveys





APPENDIX – Training Buffet

About the Author

No bio currently available.

If you remember Fortran, PDP-11s, and TTL then you've been in the industry as long as I have. Spent 20 years developing telephone switches, and railway signaling systems. Somewhere in the 1990s I crossed over to the dark side became an engineering manager and then a consultant....old engineers never die, they just become consultants. Humour aside, I became a consultant because I realized late in my career it did not matter how amazing my individual engineers were, if we did not know how to work together then we were completely hooped. I have seen too many groups of brilliant engineers fail simply because they could not work as a team to solve problems. This is when I became intently interested how people work together. By the way, non of this is new, coal miners in the 1930s knew about this long before we got all excited about it.