Alex Yakyma‘s and Dean Leffingwell‘s PACIFIC EXPRESS is described as a “short story” of an “initial SAFe adoption” that focuses on the “courageous people that drive change” and offers a format to “see and feel the people and culture aspects of SAFe”.
Essentially, it hints or suggests that a Quickstart — including “preparation” to “work with teams to re-align them to a common process model,” plan a “first Program Increment” or “release planning session,” and an opportunity to “dig deeper into the advanced topics of how to operate at scale” — is a “transformation process” (emphasis added):
“My understanding is that the whole notion of the Train revolves around delivering visible, tangible value; and I think that’s exactly what we need,” said Stephanie [client in the story] getting us back on track. “Tell us what we need to do. What does the transformation process look like?”
“We call it a Quickstart,” I [Ryan, consultant, trainer and enterprise coach] said. “The primary action happens over the course of one week and is normally preceded by careful preparation and then some follow up. During that week, I will work with teams to re–‐align them to a common process model, that’s the first two days. Then, for the next two days, we will plan our first Program Increment: PI for short. Roughly speaking, you can think of it as a release planning session. And finally, the last day can be used for Product Owners and Scrum Masters to dig deeper into the advanced topics of how to operate at scale. The Quickstart is just a kick‐off for you guys, but should provide enough momentum to drive the transformation.”
The story starts with the “preparation”, which was quite minimized, both regarding actual duration and activities:
Tomorrow is a really big day — we start our two-day release planning session and much will depend on how that goes. The preparation took two weeks — a very busy two weeks — not an uncommon thing when a program initiates this process for the first time. And not everything went as smoothly as expected… as if it ever does at scale. [. . . agree on the cadence, frequent integration, organizational structure, program priorities, the remainder of the areas, etc.]
While the story focuses on Lean, Lean-Agile Leaders, and Leadership in Lean Software Development, it disappoints in suggesting or implying that a mere presentation of “What Do I Do as Lean-Agile Leader” (in the story) is enough to shift a culture from “managing to enabling teams”:
The principal force behind these dozens of bullet points is the switch from managing to enabling teams. And since enabling teams is what we are after, we naturally arrive at a gazillion aspects of the Leader role. As you shift your thinking and start looking for the bottlenecks that prevent the Train from fast delivery of value to the business, you arrive at more and more things like that. Take a look at these again…” I browsed through the presentation once again, pausing a few seconds on each slide. “Do you think teams can do any of these on their own?”
However, the story ultimately redeems itself somewhat by emphasizing that transformation is a journey and that a “quickstart” is not the whole journey (emphasis added):
Our initial sessions, including the PI planning, were not the transformation itself. There is a reason why it is called Quickstart. In fact, it is only the beginning of a learning journey that knows no end.
And the story further disappoints in not offering anything beyond itself regarding this “learning journey” and not exploring the distinction between Dynamics and Mechanics, for a more formidable and proven approach to transformation, see Scaling Agility with Conscious Agility & SAFe, DAD, LeSS, Agility Path, or ScrumPLoP as well as Constructively (rather than Destructively) Adopting and Sustaining the Scaled Agile Framework (SAFe).