Pacific Express - Alex Yakyma - Scaled Agile

Alex
Yakyma

PACIFIC EXPRESS

ABOUT THE AUTHOR

Alex Yakyma is a methodologist, trainer, and consultant
who has been applying Lean and Agile practices in the
software industry for over a decade.

Alex joined Dean Leffingwell in 2006 and since then has
been actively working on Scaled Agile Framework and its
numerous implementations in the field. Alexs broad prior
experience as a program manager in highly distributed,
multi-cultural environments allows him to perfect his
clients operational capabilities at the program level, cross program coordination,
and portfolio strategy.

Contact Alex at alex.yakyma@scaledagile.com

Follow on Twitter: http://twitter.com/AlexYakyma

ISBN 978-1-4951-2790-8

2014 Scaled Agile, Inc.
FOREWORD BY DEAN LEFFINGWELL

Building really big software systems is one of the most
challenging intellectual endeavors facing todays businesses.
To help address this challenge, weve created the Scaled
Agile Framework, (SAFe), a knowledge base of proven best
practices that you can use to help bring the benefits of Lean
and Agile development to your business, and also better the
livesnot just of the users for whom we build these
systemsbut also of the millions of software practitioners
who create them. We do this, most simply, because better software makes the world
a better place.

That scales.

To accomplish this, SAFe is based on three primary knowledge pools, Lean, Systems
Thinking and Agile development. These values and principles power SAFe and
provide the bedrock that make it safe and effective. SAFe is freely-revealed and
publicly-facing, so that you can begin to apply it immediately in your business
context.

Freely revealed-yes, magic-no. Implementing SAFe is hard work. New values, new
ways of working, and a willingness to engage and fully empower the people who do
this important work are all required. And there is no hidden, or proprietary, secret
sauce that unlocks the magic. If there is any magic to be found, it comes from the
hearts and minds of those dedicated people for whom the status quo is not ok; those
who face the burden of change, some positively, some negatively. SAFe is a
documented system, but it is people who do the work.

To that end, Alex, has put together this work of semi-fiction, focused on one key
element of SAFe, the Agile Release Train. Semi-fiction because the business and
characters are fictional, but the challenges, vignettes, opinions and behaviors
expressed were real. His goal is to help you understand SAFe, inside out, from the
standpoint of the people doing the work. He has chosen this novella as an
experiment to see if we can better communicate why and how it works.

So lets leave the SAFe website, with its practices, figures, artifacts, activities and
references, and enter this fictional world, even if just for an hour or two. Lets see if
we can find an even better understanding of why SAFe works the way it does, and
perhaps find a little fictional enjoyment in the process. I know I did, and I expect
you will too.

I. THE BLACK HOLE

A hundred and ten approximately. All full time. This program grew rapidly
during the last year from some forty people to almost three times that size. I wish
our processes were evolving along with our growth, but sometimes it seems to me
that we are only getting worse and worse. The lady in the gray elegant suit put
some numbers on the whiteboard and paused for a few moments. A lot depends on
these people, she gestured to the board, and yet this program is like a black hole
requirements are fed in but nothing gets out. Our key stakeholders are becoming
impatient especially because she got stuck for a few more moments, perhaps
struggling to frame her statement, because we are Agile at least so we
advertise.

Some people in the room grimaced at these words, others smiled and some chose
not to burden themselves with any reaction just yet, probably anticipating more fun
to come. Even though I dont particularly enjoy other peoples awkward moments,
these can actually be quite useful they tell you what your customer really feels
more accurately than a thousands words. For a consultant paying attention to such
things is absolutely vital. We just got started and things are already popping up.
Stephanie seems to be straightforward enough thats going to make this easier for
all of us. Whether its increasing executive pressure shes under (it was noticeable
even during our first phone call) or just her personality, I think I like the direction
this is heading. She doesnt seem to be overly invested in their current methods and
tools either. Maybe shes just one of those heads of PMO that are deeply critical
about the results, despite all the politics and organizational inertia. So far, so good,
but I need more detail:

And could you please describe in more detail what exactly Agile means to your
teams?

We work in Sprints, we use story points, we do all that Sprint planning stuff We
just dont get anything out of it in the end, a gentleman that was sitting the furthest
from the whiteboard interjected.

Ryan, this is Josh, one of the product managers working with this program, said
Stephanie apologetically. We used to call this role business analyst but with the
adoption of Agile, we decided to make a switch, because she rolled her eyes
desperately trying to remember, Well, I guess nobody remembers exactly why.

Meanwhile, Josh went on

While I told you what is happening process-wise, I didnt say that I see any value in
that process, he clicked his pen a couple of times and added: as she said stuff gets
in but never gets out.

This is getting more and more interesting. Josh, if they are Sprinting, dont they also
do Sprint demo in the end? I asked.

Josh only chuckled in response, grabbed his pen again and got back to clicking it.

Im Saheli, Im a product manager within this group, like Josh, a lady next to Josh
introduced herself with a light charming accent. Yes, teams do demos and Josh and
I were attending those for quite a while, but all they show is mostly unfinished
stuff Just some functionality that makes little sense without the other
components.

Eventually I said Im not going to waste any more time on those demos and we
stopped attending, Josh jumped in again. If things keep going like this, I think we
will all have to start looking at updating our rsums. Personally I will include a year
of hyper-Agile experience based on this, he said and laughed. Nobody else in the
room, however, seemed to find it as funny.

Thats why we contacted you, Ryan. We read about this concept of the Agile Release
Train and we thought we could apply it to this program. I talked to my former
colleagues who are now running local Agile community and one of them strongly
recommended you. She actually said that youve been through some really tough
cases in your consulting career, which makes me believe that you could help us too.
She mentioned that she met you when you both attended a conference in Orlando
last year.

I cant figure out to whom she could possibly be referring, but thats not whats
important right at this moment.

I bet those other cases werent as tough as our own private hell, Josh noted
sarcastically, now busily fidgeting with his pen.

My understanding is that the whole notion of the Train revolves around delivering
visible, tangible value; and I think thats exactly what we need, said Stephanie
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 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, thats 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.

How long does the preparation stage take? wondered Stephanie.

Typically a few weeks. We need to ensure that we are all aligned on key priorities
and that we can actually implement them. And lets not forget all the logistics for the
Program Increment planning.

Logistics? Like what? she asked.

Well, its a two-day planning session. Fully collocated, highly collaborative and
exclusively focused on exploring the next PI scope

We always plan releases collocated. We are kind of lucky that way. The whole
program is located in the same building

Thats great. But who participates in it? I asked.

Well, our product management, who you already know. Engineering management
for the program, she pointed towards four guys sitting right next to me, and the
Product Owners, who arent with us today. That makes nine more people.

How about developers, testers?...

What do you mean?

Do you include them too?

Stephanie looked surprised and puzzled. No What do you mean, include them?
We cant include the entire program into the planning

Of course you can. Not only can you, but you should. How else do you think they are
going to find out what they are supposed to build within the next observable time
frame?

The Product Owners will tell them.

Josh burst out in laughter. Thats the telephone game for sure

Are you serious? Stephanie stared at me, still puzzled and clearly ignoring further
comments from Josh. Are you seriously suggesting that we put everyone in the
same room and have them plan together? All hundred and ten people?

May I ask you, Stephanie, how do those 110 people understand and manage
dependencies today?

Well

They dont, interrupted Josh. They pretend that dependencies dont exist. They
each iterate in a complete vacuum, every single team. And thats why when the time
comes to show Saheli and me their current progress, all they have is a bunch of
disjointed, esoteric stuff.

That was rough but helpful. Actually, despite his tremendously sarcastic attitude,
Josh seems to understand the real problem here. Stephanie begins looking
increasingly puzzled.

I outlined the plan: We will invite all the teams and have Product Management
speak directly to them, presenting the vision and key program priorities. We will
then let the teams figure out how much of that they can realistically deliver within
the Program Increment. They will sort out the dependencies and ensure that they
can provide what they need for each other. They will address significant risks
together to clear the way for realistic release commitment. Then they will present
their plans back to the stakeholders, to make sure that the intent is right, and the
program is ready to go full speed in the right direction for the next PI.

Josh stopped his clicking. Stephanie, be open-minded Itll work like a charm.

It was really hard to say whether he was teasing or being completely serious, but it
did not matter to Stephanie. She was silently processing all she had heard. It was
obvious that she had begun connecting the dots.

So, thats why the article I read about the Agile Release Train was talking about
alignment in almost every other sentence she said.

Of course. Think about it. If a group of 110 people are busily building something,
but never able to produce a really meaningful increment of value end-to-end, how
much of their work is a waste?

Stephanie silently nodded.

I continued: Think about developers and testers in particular people that directly
create value in this program. They are supposed to make an enormous number of
decisions at the micro level every day. For example, how to write this IF statement
or what parameters to use in a test scenario, or what interface to select between two
components these are the questions for which they badly need meaningful
context. They need to hear from the business owners, the product management, the
architects, and the infrastructure people which direction the Train is moving. They
need to figure out between themselves the teams what and how to build. Yes,
you are right, alignment is a key driver behind the notion of the Agile Release Train.
Global alignment is favored over local team excellence, and the release planning
session is a key first step in that direction.

You know, Ryan, even though I agree with all of this, she sighed, I cant imagine
how we sell it to the business stakeholders or even to the teams. There will be a lot
of resistance. Weve already lost the trust of the business stakeholders and now we
are asking for two more days of their time? Not to mention that the teams would be
distracted for four days? Thats a tall order.

I understand, but Ill tell you, Stephanie, this is a pretty simple cost-benefit
conversation.

Stephanie quickly sat down next to me, ready to take notes.

Well, first and foremost, in order to justify the investment of time, effort and
money, we need to understand what the company can expect to get out of it, I said.

At least some end-to-end functionality, interrupted Josh. We need to start
building stuff. If we can deliver, we can capitalize on that and the sooner we do it the
better

Fair enough. Now, Agile Release Train is designed to enable you to build
production-ready increments of value at least every ten weeks, as well as produce
end-to-end working software as a measure of progress at least once every two
weeks.

Stephanie was taking notes in complete silence. I let her finish theres more to
come.

Over time, Trains normally manage to deliver value more and more frequently,
therefore detaching development cadence from delivery schedule. In other words,
you deliver when the business needs it rather than only at the Program Increment
boundaries, which is usually eight to twelve weeks. I picked ten as a typical
example.

That sounds really good. Stephanie finished writing and turned to me again
ready, obviously, for more ideas.

Collocated planning every ten weeks drives alignment of the entire Train to a
common vision. Backed by frequent end-to-end system integration and fortnightly
system demos, it will allow this group to build more value. Its simple logic: there
will be much less rework because teams never get out of synch.

Nice Give me one more, said Stephanie.

Emphasis on code quality and architectural concerns will help us sustain high
program velocity in the long term, and will prevent technical, design and quality
debt from accumulating. This means that our ability to add value will be sustained
over time, which is not a typical picture across the industry unfortunately.

It will be fortunate for us, said Saheli. If we manage to implement all you are
saying.

Josh made a funny face, clearly suggesting that it would not be an easy journey.
Those of us, he quickly added to the gesture, Who survive this transformation,
will never be the same While the development managers and Saheli were
cracking up at Joshs joke, Stephanie stayed right on topic.

On the other hand, she acknowledged sadly, Most of our teams are quite
demotivated by the way things are now. I doubt that they will be very supportive of
these changes or of any changes at all. Forcing them is something I would like us to
avoid at all cost. Last month we lost two of our Scrum Masters and a bunch of
developers people dont feel happy about their work; group morale is very low

I understand. We will address that too. This model creates benefit not only for the
business, but is built on a strong foundation of respect for the people who actually
create value.

Tell me more, said Stephanie, busily writing more notes on a new sheet.

Teams will no longer plan blindly. They will now hear program priorities directly
from the key stakeholders. And they wont just hear, its a two-way conversation
where teams can and should ask questions directly of the stakeholders to figure out
what and how they are building in this PI.

Okay

Next their focus will be on that which really matters end-to-end value delivery.
They will score every two weeks. Their ultimate goal every Sprint will be to deliver
a slice of value together: something they can proudly demonstrate to the
stakeholders. But even more importantly, they will now know themselves that they
are making real progress. That will bring back esprit de corps and make the
workplace an enjoyable place to be.

Beautiful said Stephanie, expecting at least one more item.

We will foster software craftsmanship and make sure that we, as a program, take
pride in delivering quality code. No more just doing it. Every increment we will
build quality in. We will therefore understand our real velocity as a group and be
able to sustain it over a long period of time.

I like it. Whether or not it will be an easy sell only time will tell. I personally think
itll be a tough sell. Nor, Im afraid, will the implementation be easy in our
environment. But I actually have authority to approve the budget for this
Quickstart. She paused a moment. Last question, Ryan. When can we get started?
II. LAND OF THE SLUMBERING SUN

San Diego is an amazing place, especially in the fall. Nature begins to cut its ties with
summer in preparation to what passes for winter around here. The temperature is
perfect, although the water is a bit colder than comfortable. The ocean seems a little
grimmer, but I suspect Im the only one who cares to notice that. Even having visited
just a few times, I feel I know this place quite well and really enjoy it here. It would
be nice to have more Quickstarts on the West Coast, but if one could make that
happen every time wouldnt that be a super power? Like magic, almost on par with
making software development really efficient at large scale.

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.

The first thing we did was to agree on the cadence. From the start, Stephanie
managed to quickly gather key people and initiate a good discussion. They agreed
on a ten-week duration for program increment, even though it took some nerve to
do so. Some Scrum Masters were overzealous in defending their existing three-week
Sprint cadence, which in no way adds up to a ten-week PI. But even apart from that
arithmetical glitch, by insisting on three week Sprints, they would really complicate
synchronization across the entire Train, as lots of teams were running in shorter,
two-week cycles. Aligning the Sprint cadence makes synchronization substantially
simpler. And since most of the teams were used to operating in two-week
timeboxes, we finally managed to convince the rest of the program to do the same.
In cases like this you need a clear, strong argument and such an argument was
presented to the teams. When they fail to deliver end-to-end value, sometimes one
wonders, what can be more important than synchronization across teams? When
key stakeholders claim that they see no output from the program, it is hard to argue
and defend a local team caprice. Stephanie did a lot of selling during this session,
strengthening my faith that there is a future for Pacific Express (she came up with
this name for the Train). With this basic input we were cleared to move on to other
things.

The next big problem was frequent integration. We had a very painful discussion
involving technical experts from different teams, as well as architects and some test
engineers. The way that process had evolved was less than ideal teams were each
working in their own, isolated branch of code. Did they have a common program
branch? Yes, and the teams actually worked under the assumption that they were
regularly synchronizing with the program branch. The resulting problem was that
they would check out code from that common branch into their own, but almost
never check anything back in. So, when nobody pushes anything into a shared
branch of code, guess whats in it? Sprint after Sprint, almost no changes occurred in
10
the shared codebase. No wonder synchronizing this way was shockingly easy:
nothing was happening! As soon as we instituted a different experiment agreed-
upon mandatory daily check-in of code the flawless Happy Land turned suddenly
into a world of pain and suffering.

Luckily, though, Saheli provided tremendous support. She emphasized the
importance of the end-to-end increments from the teams every two weeks. And how
could they produce those without frequently integrating? I couldnt even begin to
imagine, she said. Eventually the thread was resolved. It was decided to integrate
across the entire Train at least three times per Sprint. These integration points
would be coordinated carefully on a Sprint-by-Sprint basis, assisted by a newly
created System Team. Their primary responsibilities were to maintain the
integration and testing environments and assist the rest of the program with the
integration process. Despite the fact that such a team was created, Stephanie made it
clear to everyone that the primary responsibility for end-to-end integration lies
with Agile teams. After a few days of experimenting, the teams also agreed on a
critical rule the Green Build Policy. Stated briefly: if integration isnt successful (i.e.
not green), then everybody on the Train stops and swarms around the problem
until it is resolved. The implication is that no new functionality is being built on top
of an incorrect one, which would cause a much bigger problem later. Instead, every
new step is laid on top of fully integrated revision of code.

The organizational structure did change a little. It was decided to reorganize the
maintenance work such that the maintenance team would dissolve and in its place,
maintenance engineers would join other Agile teams. This change, proposed by
Stephanie, was a smart move, in my opinion. There had always been a big gap in
knowledge between the maintenance team and the rest of the program, because the
other teams never had an opportunity to do an efficient knowledge transfer. On the
other hand, maintenance guys were complaining all the time about system design
that did not foster maintainability of code. This was due to poor handling of
dependencies between classes, bloated methods and functions almost impossible to
comprehend, and very tight coupling throughout the codebase. Meanwhile, the
eleven-member Argonauts team was split in two. These two changes left the Train
with the same number of teams fourteen.

The next big undertaking during the preparation was agreeing on program
priorities. This process was particularly ugly in the very beginning. It turned out
that Josh and Saheli didnt actually maintain a single program backlog, but instead
worked with teams directly, providing some scope of work to the product owners.
The first time we brought things together in the same backlog, it spawned a flurry of
emotional arguments between the two about whose stuff was more valuable. At
some point, I realized that they were simply shouting at one another. Stephanie had
to calm them down, which she turns out to be quite good at. Eventually, after the
introduction of economic prioritization with Weighted Shortest Job First (WSJF), the
conversation shifted into a more productive phase. The core idea here is simple:
every feature in the program backlog has a certain Cost of Delay, or CoD for short.
11
CoD stands for the amount of unfulfilled benefit when delivery is not made to the
customer. The Cost of Delay of the feature, divided by the duration it takes to
implement, provides a good numerical expression of economic priority. This is quite
intuitive, because the higher the cost of delay, the sooner you want to get started
with that feature. And conversely, the more time it takes to implement a feature, the
later you start with it. Otherwise, other features, even smaller ones, will have to wait
a long time to be delivered. We used a very specific expression for Cost of Delay that
reflects different aspects of a feature and uses feature size as a proxy for duration:

WSJF = (Business Value + Opportunity Enablement + Time Criticality) / Size

We then gave Saheli and Josh a chance to rank each of these four parameters for
every feature, in relative numbers, using Fibonacci sequence (just like the one
Scrum teams use to estimate the size of their stories: 0, 1, 2, 3, 5, 8, 13, ). The result
was staggering: they managed to reach reasonable agreement on almost all features
except one. Enter Stephanies negotiation skills mixed with the Lean economics. So,
we ended up with a shared understanding and agreement on key priorities. And
perhaps most importantly, a unified program backlog, prioritized by economic
value. With that accomplished, the Train was ready to pick some top priorities for
implementation.

The preparation for the remainder of the areas, including the logistics, went
relatively smoothly. Nevertheless, Stephanie and I were clearly sensing an uneasy
atmosphere across the board. Key program stakeholders, who Josh and Saheli de
facto report to, agreed to participate, but did so very reluctantly. They were visibly
distant in all conversations regarding the transformation. It is hard to establish trust
when theres nothing to deliver I can understand that. One of the stakeholders,
John, even said that he would let us play with the planning and other things like that,
but that he had no faith in it. Thats embarrassing, but Stephanie and I are going to
prove that its the real deal, or fail and fail big tomorrow.

But thats tomorrow. Today I feel a need to simply give my mind a break from all
these thoughts that have piled up over the last few days. Right after finishing the last
session with Stephanie, I slipped out on my escape route La Jolla Village Drive,
which seems to take me to another world in a matter of minutes. I hastened to
disappear in the evening traffic for I know the reward. Under the spell of the
comforting whisper of the ocean, I can finally stop thinking and worrying and fully
fuse with the tremendous vastness of the sea, as it prepares to shelter the sun for
the night. The day finally surrenders to the magnificent closure ceremony and the
waters darken, as does the whisper of incomprehensibly mysterious tongues. No
day repeats itself tomorrow will be another stream of unique moments, most of
which the world will carelessly forget.

12
III. GETTING THEM BACK

Town Hall is filled with the humming sound of over a hundred people getting their
morning coffee, pulling laptops out of backpacks, and checking smart phones all
the usual a.m. procedures which you can do half-asleep. At 7:50 a.m., most of the
chairs in the room are already occupied. Fourteen tables, one per team, take up most
of the room, leaving some space around the walls. A few more tables have been
brought in to handle stakeholders and other participants that arent among the Agile
Teams. Stephanie is busily explaining something to the IT folks in the back of the
room, pointing at the projectors and large speakers in the front.

A few stragglers appear in the doorway and quickly join their teams. Stephanie is
ready to kick this off. She takes a quick sip of coffee and taps the microphone with
her fingernail a couple times, which apart from a sound check function, signals to
everyone on the Train that we are about to get started.

Good morning guys, she says in a very cheerful voice, causing an avalanche of
good mornings in response. Earlier today, when putting team name tents all
those Wolverines and Argonauts and Spartans and what not on every table, she
smiled and paused for a second, I realized that we were missing the most important
team name. We are all one team. We are all here together today, on our first
Program Increment planning, because as we learned, we are not just a bunch of
isolated small teams. The only way we can deliver value is by working together.
Therefore, I would like us all to remember that we are first and foremost the
members of a much bigger team Early in the morning Stephanie had carefully
done her homework. She turned now to the easel and tore off the top page of the flip
chart, revealing the name for the whole program Pacific Express.

Stephanie clearly had the audiences attention. She went on:

Today we will do our first big thing as a larger team as an Agile Release Train.
She pointed at me: We have Ryan with us for the two days of planning. Many of you
already know him from the preparation workshops and the team training on
Monday and Tuesday. Just to remind you all, Ryan is a consultant, trainer and
enterprise coach who is helping us implement Scaled Agile Framework in our
organization. This program is our initial foray into Agile at scale and is extremely
critical to the success of our business. Our program will soon begin operating as an
Agile Release Train and will gradually learn how to deliver meaningful value
together, step by step. At this point I would like Ryan to take the stage

Thank you, Stephanie. I am a little nervous. No matter how many times I go
through the PI planning, its always a big deal. Yes, Stephanies right. Each of you is
a member of two teams your Agile team and the Train. The notion of the Agile
Release Train is one of the cornerstone concepts of the Scaled Agile Framework (or
SAFe for short). Many of you have already heard about SAFe, but lets make sure we
13
all clearly understand what it is and why we care. SAFe is a model of a Lean-Agile
enterprise. Agility had proved to be extremely efficient for small teams, but as soon
as large businesses began implementing the method, it became apparent that Agility
itself was not inherently suited to scale. Out of this disconnect the need grew for a
thinking tool to operate in a large-scale environment. And such a tool was already
out there Lean thinking a flow-oriented systems thinking approach that
originated from Toyota Production System, which many of you have heard of. Lean
allows us to abstract for a moment from how to develop software in an iterative and
incremental manner, and instead concentrate solely on the flow of value. This
radical emphasis on the flow allows us to apply this thinking paradigm to the
organization as a whole. It serves as guidance when we want to scale agility. It also
governs the work of Agile teams so that they can understand and deliver value in a
larger context. Lean suggests a couple of simple ideas, that nevertheless
substantially facilitate the flow of value: operating at low levels of work-in-process,
minimizing the queues in the flow, and constantly optimizing the system as a whole
all to achieve the shortest sustainable cycle time throughout the organization.
SAFe utilizes Lean thinking to scale Agile best practices. And the first such level we
scale to is program. Just as the Agile team is the smallest group of people that can
define-build-test work, there is another level Agile Release Train, which is capable
of delivering solutions. This is a key building block for organizations that depend on
software development for their success. If you would ask me how to define Agile
Release Train in a single, short sentence, I would suggest that it is simply a
continuous flow program. All we do as a Train is to accelerate value delivery to the
business. Lean thinking applied to scaling agility at this level leads us to the
following rules for the Agile Release Train:

Train is a self-organized team of Agile teams (50125 individuals) that plans,
commits, and executes together.
Program Increment is a fixed timebox a major planning and alignment
horizon for the Train typically four to six Sprints.
Teams have synchronized Sprint boundaries within the PI.
Everyone on the Train is aligned to a common mission via a single program
backlog, consisting of features sequenced in order of economic priorities.
The Train operates under architectural and UX guidance.
Every two weeks, the Train produces fully integrated valuable increment of
the solution.

If we do everything right during this planning session, we will indeed witness an
amazing metamorphosis in this room a bunch of disjointed teams will turn into a
qualitatively distinct construct an Agile Release Train. It was important to set the
context and explain to them what Train and SAFe are, but they will really
understand it only by experiencing it. The planning session is the magic wand It is
time to introduce the agenda for it.

14
PI planning is a two-day process. The goal is simple to get aligned on key program
priorities and understand what we, as a Train, can realistically deliver within the
next ten weeks. When we say realistically, we mean that dependencies are
identified and resolved, risks managed and objectives for each team agreed upon by
the business owners. Here is how we are going to do this

Sorry, I have a question, a lady from the Argonauts team raised her hand. Is this
process similar to the Sprint planning?

Yes and no. Yes, in the sense that PI planning is to the Train what Sprint planning is
to the Agile team. At the same, time it has many additional steps and process
requirements that differentiate it from the Sprint planning. The exact difference we
will be able to experience in just a little bit.

The first half of the day today will consist of various briefings. Business owners will
present the overall direction for the business. Product Management will then
present the solution vision and the top features to be built in the PI. Some of the
Product Owners already have some seeded stories we did initial breakdown of
features into stories a few days ago. It was a useful exercise, but please keep in mind
that you may change the breakdown as you see fit as long as your product owner is
onboard with it. The goal is to drive maximum value rather than stick to the initial
breakdown of features.

Next we will have the overview of architecture and engineering practices.
Development infrastructure will also be discussed as part of this briefing. We need
to know not only what we are supposed to implement as a Train, but also how we
are going to do that implementation. Again, this is not a detailed system design; its a
high-level guidance. This concludes the set of briefings that provide the required
planning context for us.

Next up will be the Team Breakout session. This is where the teams actually plan
the PI. You guys will have to break down features into stories and put them in your
PI plan. While we will discuss in detail what those planning artifacts are and how to
effectively use them, let me make it clear from the beginning the key output of the
planning for each team will be a set of Team PI Objectives concise statements that
are meaningful and valuable to the business owners. Everything else, even stories,
are just tools to arrive at a succinct, executable set of objectives lets remember
this throughout the course of the planning

A young guy from the A-Team raised his hand: How are objectives different from
features? Or they are the same thing?

Good question. In many cases, objectives will actually be features. But thats not
always the case. Think of some milestones like supporting user-testing event, for
instance. Its not a feature per se, but makes for a meaningful PI objective that has
business value. Another example could be a significant research effort. The
15
functionality itself, for which the research is being planned, will be part of future
PIs; or it may not be committed at all if the research proves to be negative. But the
research itself is a valuable objective within the PI. Furthermore, many features
require more than one teams participation. In this case, each team will have some
objectives that may contribute to the feature but not entirely complete it. You may
discover more examples later today just by walking around the room and reading
what other teams have on their objective sheets.

But to summarize, I can say that features are the initial input to the planning, while
team PI objectives represent the output. The purpose of the PI planning session is to
conduct some sort of reality check and to understand what the ideal set of top
features means from the team perspective. This is possible once they thoroughly
comprehend the implementation and possible risks. It now becomes obvious why
we break down features into stories. It is an analysis-synthesis process. First
(analysis) teams break it down into smaller, actionable and more understandable
items. Then they try to understand each others dependencies, identify impediments
and risks, re-scope, if needed, and plan for supporting activities like research,
maintenance, etc. Once reality has set in, they integrate it back to the same level of
abstraction, basically by summarizing those detailed plans via the team PI objectives
(synthesis). Thats how we should view this process.

I therefore ask you to do the following: every team must at all cost get to the draft
PI objectives by the end of the day today, otherwise neither the teams nor the
business owners will be able to understand where we are with respect to the
planning process. It is better to have a very rough plan of all five Sprints in the PI,
and thus be able to derive the PI objectives, than to have only two or three Sprints
planned very accurately, and still have no understanding of the overall PI outcomes.
In other words, dont get stuck on too much detail today. I especially encourage
Scrum Master to very carefully facilitate the process. Identify planning impediments
as early as possible and make sure the teams make a shallow pass over the entire PI
scope, rather than get lost in the detail and end up with nothing today. Lets keep in
mind, that we will have the entire day tomorrow to get deeper into the nuances of
the functionality and other concerns. To help teams stay on track, we will have
Scrum Master check-in every 45 minutes. I will be facilitating those meetings while
the rest of the team members continue working on their plans.

Up next will be the Draft Plan Review, where every team will present their PI
objectives, as well as rough description of the flow of the Sprints: what gets done
and when. This is a short and focused presentation, typically two-to-three minutes,
immediately followed by a Q&A from the business owners and other teams. This will
conclude the day for most of us, while program stakeholders, Scrum Masters and
Product Owners will stay for the Management Review and Problem Solving meeting.
We will go through what we learned from the team plans and if any corrective
actions are required, this is the time to make such decisions. Scope trade-offs and
even changes to the team composition can be made at this point.

16
We will begin the next day by presenting these adjustments to the rest of the Train,
after which there will be another three hours for team breakout. This is the time
when PI plans are further refined and business owners assign business value to the
objectives for each team. Once teams are finished planning PI scope, they will
present final plans to the business owners. After this we will have a joint session for
risk management and, finally, teams will have an opportunity to do a confidence
vote.

After my introduction to the process, Stephanie invited the first presenters: John
Head of Retail Automation, and Tanya VP Development. The impact this
presentation made on the audience was tremendous. In fact, it was the first time
most of the team members had ever heard from someone on the business side and
the information John presented provided invaluable context for the whole Train.

He discussed the current state of the retail business. Then he talked about the
companys substantial dilemma of brick-and-mortar versus ecommerce as well as
business automation trade-offs associated with both paths. John also talked about
the key strategic theme of expanding the number of ways our customers can select
products, buy them, and have them delivered. Customer base segmentation and
better, more focused outreach to the segments with a particular value proposition
was another big theme. Although he was using a microphone, the audience was so
quiet you could hear a pin drop. After he finished, Stephanie asked if there were any
questions the audience remained silent, still digesting a boatload of valuable
information.

You may wonder how it is that the teams, working in the same organization as John,
were unaware of the most basic business context for their priorities? It should come
17
as no surprise, given that the methods we used for software development for
decades were built for anything but alignment. Disjointed activities in a largely
siloed organizational structure had historically fostered sub-optimization of the
functions, but not the flow as a whole. A simple thing that accomplishes miracles
face-to-face communication was unimaginably far off, replaced instead by tons of
documentation and a plethora of isolated business analysis methods and tools. With
the advent of Agility, the industry got a glimpse of hope as the Manifesto clearly
called for face-to-face communication and business and development working
together. But something else happened in most large organizations: for many of
them, even with the adoption of the new roles and rules, both Product Owners and
their teams still stood far off from any real business context, or the user.

We as an industry had failed again because of our natural propensity to value
methods and practices over process goals and systems thinking. Picking a developer
and calling him a Product Owner does not help bridge the gap between
development and the business. Having daily standups does not create any face-to-
face communication between those who understand what needs to be built, and
those who are supposed to build it. PI planning in SAFe has a secret weapon, the
likes of which is hard to find probably because it took a genius to figure out that
simply putting people together in the same big room and having them talk to each
other helps them stay on the same page.

Tanyas presentation was also helpful. She provided good insight to the technology
advancements. She introduced an important theme: shrinking the technology stack
that had grown uncontrollably over the last three years, ending up in a hairy ball of
different tools, libraries, frameworks and platforms. Many of these duplicate each
other and came into existence as a matter of personal preferences of different
teams, as opposed to any rationale. The big theme for this PI, as she noted, would be
to move all existing VB.NET modules to C#, as they are much easier to maintain.
Reducing the number of different configuration management tools used for different
aspects of data management, deployment and production monitoring was another
vector for this PI.

I was surprised however, when after finishing their presentations, both John and
Tanya grabbed laptops and made their way towards the door. Puzzled, I glanced at
Stephanie but she didnt seem to share my bewilderment. As soon as she called for
Josh and Saheli to present the top priorities in the program backlog, I waited a
couple of moments and caught Stephanies eye, quietly pointing at the door. She
followed me out while Josh began his emotional speech about the features the Train
will take on in the next ten weeks.

Yes? asked Stephanie in her typically calm voice.

How come John and Tanya left? We are going to need them.

18
For what? Im sorry, I thought we needed them to present and that then they could
leave She realized that something was amiss. She sighed, Look, I told them it was
ok. Maybe that wasnt right.

It wasnt. Their thorough participation was something I emphasized when we were
discussing the agenda last week. The key stakeholders need to be with the program
for the two days of planning. Josh and Saheli are managing the backlog, but they are
not the ones that decide in principle what this Train is building. We need a full-
fledged business owner team, which in this case consists of John, Tanya, Saheli and
Josh.

I understand and Im sorry. Lets run over and grab them and see if we can talk
them into coming back. She sighed again. She was probably thinking about how
difficult it would be to convince them to come back, especially since they didnt like
the idea of this planning in the first place and now here she was asking for more

If that was her thinking, she was right on the money.

What? Are you kidding me? I cant spend any more time on that, said John when
Stephanie voiced the request. Tanya and I spent almost an hour there already. I
dont see any reason to spend more time. Tanya was sitting at the opposite side of
the table, nodding in agreement as John spoke.

This is bad. Without these two key people the program will drift in the wrong
direction. I have to do something right now or the whole thing is in danger. Teams
will plan something that these two guys will then claim is wrong in ten weeks and
that will be a sad fiasco for the whole initiative. A lot of the Trains effort will be
wasted as a result.

John, if I may John raised his eyebrows and stared at me. Look, I know you and
Tanya must be busy and have a lot of things going on. I wouldnt expect otherwise,
given your role in the company. But I wonder if you noticed what just happened
back there in Town Hall?

John looked at me suspiciously. It is important that I give him the facts and then let
him decide. Ill do what I can, but eventually it is his program, not mine, so who
should be more worried about the outcome here? John, your speech absolutely
riveted their attention. This could be a pretty noisy audience I can see that. But
there was no chatter or fidgeting or side conversation going on while you were
speaking. You know why?

Why?

Because they care There were many things that you and Tanya presented that
they heard for the first time today. That was an important piece of information that
19
they needed to hear from you. It is not something their product owners will tell
them. Nor will they figure that out on their own.

Things that are intuitive and obvious to you are only that way because that is your
world. You think and operate in terms of the strategic intent for the organization,
but they dont. They are stuck in their specific, narrow boundaries. But guess what?
Every one of them is making lots of little decisions every day and those decisions
add up to either good or not so good outcomes. When a developer decides how to
round a numeric value of the variable, or what response time is sufficient for a
screen, or which field to index a table by, there needs to be some meaning, some
context for those decisions. There must be some glue to make the parts adhere into
a broader vision, for a successful solution that will benefit the consumer, as well as
the business. If a developer chooses to create an index to slightly speed up search
queries in the table, and that table turns out to be write-intensive, then she has
done much more harm than good. You have a hundred and ten people in there that
need guidance. Imagine how many wrong decisions they will make within the next
ten weeks without appropriate context. Imagine how much waste and rework there
will be

John sat quietly for a few seconds and then said, Look, you are probably right. But I
gave them that just a few minutes ago. I gave them the context you are talking about.
For the rest of today and tomorrow, I have a hundred more things to get done and I
bet so does Tanya

I interjected: What you did was very valuable. But it was a one-way trip. You
delivered the message to the group great! But that doesnt mean that they properly
understand it yet. The only way you can confirm their understanding is by hearing
from them; when you see their plans, their PI objectives. They need to process your
message and provide some output that proves whether they got it right or not. And
trust me, based on prior experience, I know for sure that you will find some
significant inconsistencies with your initial vision. Would you choose not to know?

John looked at Tanya, a little puzzled. He opened his laptop and, it seemed,
completely tuned us out for a minute or two. He finally put it aside and looked at all
of us with a softened expression. Very busy two days, guys. I can probably shift
some things around but dont expect much. I can give you about an hour more today
and about the same amount of time tomorrow.

Thats far from perfect, but well have to live with it. Its certainly better than
nothing.

In that case, John, if you could come by today at four for the draft plan review and
then again tomorrow at one when the teams present their final plans, that would be
perfect.

John nodded and looked again at his monitor. How about you, Tanya? he asked.
20

I think I can make those time slots work as well, she answered.

Great! Stephanie jumped in. Thank you both so much for your flexibility on this.
We all really need you two to make this program successful.

The door closed and Stephanie and I hurried back to the Town Hall.

Ryan, Im sorry for this. I should have remembered what you asked for earlier.
Honestly, I just had too much to take care of with the logistics and other things I
just missed it.

Thats okay. At least we have them for two more hours now. Lets make sure we use
their time efficiently. I think Josh and Saheli must have finished their presentations
by now.

We entered Town Hall and witnessed just the opposite Josh and Saheli were being
bombarded with questions about functionality, nonfunctional concerns, and so
forth. The teams, realizing that they finally had a chance to resolve the questions
about scope, had quickly taken advantage of the opportunity. After four or five more
questions, Stephanie was able to usher Saheli and Josh away from the podium and
invite the architects up. This session went full length as teams wondered about
different aspects of design for new features, tooling, and other engineering
considerations. With just fifteen minutes left before lunch, I took over the meeting to
cover one last thing before the team breakout starts.

This is what your plan is going to look like, I pointed at the wall to the left of the
projector screen.

21

Every team will have seven big sheets. Five of the sheets will be for the five Sprints
in the PI. This is where you will put your stickies the stories that you will
formulate, once you start breaking down features into smaller, more manageable
chunks. Please keep in mind that every team will still have their regular Scrum
ceremonies (including Sprint planning) every Sprint. Thats when you will provide
an even deeper level of detail to those backlog items. But for now, go only as deep as
you need to, in order to roughly understand the size, dependencies and overall
significant risks. In fact, as I said before, it is important that you stay at a high level,
otherwise you will definitely get stuck in the details and never manage to get
through the entire PI scope. Each sticky will have a story size estimate, just like in
the sample stories that Ive created here. Each Sprint sheet will have two numbers:
Velocity which you will have to estimate for each Sprint in the PI, taking into
account time off or other distractions; and Load the overall amount of points on all
stories loaded into that Sprint. Please be realistic and dont expect miracles. Those
two numbers are designed to be a self-check for each team, in terms of reasonable
workload planning.

Backlog items will be color-coded: green for the new functionality, orange for
spikes or refactoring effort, purple for maintenance, and red for risks and
dependencies. Please use these colors consistently.

Another sheet actually the most important one is the list of your PI objectives.
No stickies on this one. Instead, each team will literally write the objectives on the
sheet in the form of a list, clear and legible.

The seventh and final sheet will be for risks and impediments that the team cannot
resolve on their own. These need to be brought to the programs attention.
22

We will adjourn for lunch until 1 p.m. But it would be helpful if you guys could set
up your team area the seven sheets so that we will have three full hours to
dedicate to planning. Please remember that your goal today is to provide a rough
plan of all five Sprints, enabling you to derive meaningful PI objectives and present
those to the business owners at four oclock. Lets meet here at one sharp for a quick
check-in and to kick-off the actual planning.

Some teams went directly to the kitchen area clearly processing too much input
during the briefings consumes a lot of energy. Others used the break to pick the
best parts of the wall, close to their team tables and smooth enough to attach the
sheets without worrying about switches, thermostats or windows. In just one hour,
the real action would kick off, and result in a meaningful plan that helps them
realize, through experience, that they are really one big team. I certainly want to
believe thats the case

23
IV. BITTER TRIUMPH

It is 1: 15 p.m., and most of the teams are busily circulating around their planning
areas. A few still sit at their tables with Product Owners trying to pull-up info on
their laptops. Josh and Saheli were hanging out with the Avengers, explaining
something to the team. Josh waived his hands in his typically expressive manner,
while Saheli made notes on the stickies and handed them to the team. Thats a very
good sign thats why they were brought in here to work with one another.

The whole room looks and sounds like a busy beehive. Hopefully the product will be
equally sweet .

Ryan, does everything look good so far? Stephanie had approached so silently, I
havent even noticed.

Are you kidding? They are only fifteen minutes into it, so how can I tell? However,
some good things are already happening. See Saheli and Josh?

Yes

Well, they are exactly where we need them to be during the breakout session
helping teams and addressing their inquiries. Its too early to get real excited, but in
the meantime, the first Scrum Master check-in is going to happen in thirty minutes
lets go prep the area.

It is key for the entire group to stay focused, and in order to stay focused you need a
few key process goals that are easy to follow. Stephanie eagerly assisted me in
creating those and now its almost time to call for the first Scrum Master check-in.
The teams are so busy planning, that only three Scrum Masters come without being
prompted. We had to switch on the microphone again to call for the rest them. Once
all fourteen of them had gathered around the check-in board, we get started.

Guys, we have to make this quick and efficient. We only have a few questions to
check status on, but they are important ones. Its a matrix with questions as rows
and teams as columns. I will pick a question and go through all the teams and then
another question, and so on. All teams will have to tell me where they are and then
we will move to the next question. Once we complete this part, hopefully quickly, we
will have a meet-after, where you are welcome to bring up specific impediments
your teams have discovered.

24

Lets get started. First entry: Are features broken down into stories? Id like to hear
from you guys, team by team now. Avengers?

No, not quite finished yet, said the Scrum Master of Avengers. Were still working
on it.

Good. Partial credit then, I said and drew my favorite half-dot sign in their cell on
the matrix.

Next Argonauts?

Done!

Very good. Solid dot for you guys.

Spartans?

Not done, but close.

We are moving really fast with this. The rest of the teams Scrum Masters provide
their progress quickly and we move to the next question:

How many Sprints planned? Guys, I need to warn you to be careful with this one.
Planned means a very specific thing for the Sprint. It means it has stories loaded on
the Sprint sheet and it has two numbers on it velocity and load. Then it counts. Im
not trying to be overly formal here, but with fourteen teams in the room we need to
be disciplined about the process to avoid unproductive chaos. I will be putting as
many dots in a cell as the number of Sprints you have planned. Once you have five
dots its going to be a check mark simple! So, Avengers?
25

None yet.

Okay. Next. Argonauts?

One done, their Scrum Master proudly pointed to their team area. It had
everything in place, including velocity and load for the first Sprint.

Good job, guys. One dot out of the way

The rest of the process went quickly. Partly because not too many Scrum Masters
had much to share. This is a good exercise to show them where they are, relative to
the goal for the day to have a plan ready to present to the business owners.

Guys, please look carefully at our check-in sheet. Your big next goal is to finish
loading scope into the Sprints and formulate your draft PI objectives. Meanwhile,
make sure you start effectively identifying risks, impediments, and dependencies
with other teams. Thats it for the main part. We finished in nine minutes not bad
at all for the first time. Next, is the meet-after if we need one. Are their any problems
you see so far?

Yes, said the Avengers Scrum Master. Just before coming here my guys asked a
very good question that made me rethink the way we are planning the PI.

Who do we need for this discussion, do you think?

Im afraid well need all Scrum Masters because it is going to affect the entire Train.
I also need Sunil a developer from my team

26
Stephanie quickly went in search of Sunil, to bring him into the conversation. In the
meantime, the Scrum Master went on:

We actually almost finished planning Sprint one and had started working on Sprint
two, when Sunil told us that most of the stories, he thinks, are considerably
underestimated. Here he is actually, so Ill let him speak

All the stories we have on those sheets, except for spikes, will take much longer,
Sunil quickly jumped in. I realized that we did not account for end-to-end system
integration. During the last few weeks, we were experimenting with it because Ryan
raised the issue of full system integration and we had agreed to integrate at least
three times per Sprint. Unfortunately, we never bothered to determine how much
more time it takes. But we know how painful it was during our initial experiment.
The other guys and I believe that it will take ten to thirty percent for each story,
depending on the complexity and the number of teams involved.

Some of the Scrum Masters nodded in agreement. Stephanie glanced at me and then
proposed an idea: Why dont we all simply assume an average of 20% to be added
to the current estimates. Every team will have dozens of backlog items for this PI
and I think the law of large numbers will make it work.

Shes right. We need to communicate this to the teams ASAP.

We will need every Scrum Master to communicate this to their team. The message
is simple account for roughly 20% more to cover integration effort for each story,
except for spikes, other research or anything that does not need to be integrated
into the mainline. Are we clear on this guys?

All the Scrum Masters agreed and now were ready for action again.

Wait! Another Scrum Master raised his hand. My team has a serious problem. It
affects only us and Spartans and we had better bring in architects for this one.

Stephanie rushed to get Bill and Todd, the system architects working with this
group, who were sitting idle at their table in the back of the room.

Guys, why dont you all quickly go back to your teams and notify them about the
change in the estimation of stories. I will need Ninjas and Spartans Scrum Masters
back here immediately afterward for the session with the architects. Feel free to
bring other team members as you see fit.

In less than five minutes, the entire group of seven people was discussing the issue
that Ninjas had uncovered. It turned out that this was the first time they had to
apply a series of changes to the database structure that would affect a number of
tables with high transaction intensity. The tables are basically responsible for
storing data for the major part of the purchasing process. Data transformation and
27
transfer to the new structure was estimated to take at least thirty minutes in the
production environment. With an average rate of three hundred transactions per
second, they needed a smart way to handle this. Luckily, Todd was at hand and
suggested creating a temporary table to capture all the transactions while the main
data transfer process was running in the background. The maintenance window can
be then reduced to less than a minute just enough time to flush all the data from
the temporary transaction tables into the main tables, once the main data transfer
process is complete.

We are looking at three minutes though, including the time to restore indices.

That was a good catch by Ninjas. Now they will have to add additional items to the
plan to create data transformation scripts that would automatically handle the
process, and test it very thoroughly for any errors in transaction processing that
could be fatal to the business.

The architecture session ended there. Stephanie and I finally got a few minutes to
silently observe the movement in the room without arranging any sessions or
helping teams exchange thoughts, or what not. It appears that after the initial check-
in, there is more and more action in every team area. Josh and Saheli split up and are
working with different teams, busily clarifying and moving things around on the
sheets. Both Bill and Todd were helping Spartans with estimation.

I could sit and watch something like this forever, but there were other things to do.
The next check-ins introduced more interesting questions, but teams seemed to be
able to move forward. Scoping decisions after the second check-in unblocked the
Samurais, who otherwise could not fit anything else in the PI. A few more
implementation nuances required Bills attention, but everything was resolved,
since Bill had moved to helping another team.

The last check-in looked really encouraging. All teams managed to get to the PI
objectives. And while there were small issues with some teams, it looked like the
Train was ready to present the plan.

28

John and Tanya showed up a few minutes before four oclock, both with curious
expressions as fourteen teams came into view in front of them. All were busily
discussing scope, walking around to other teams, and finalizing the plans for the
initial review. The walls looked like some sort of mosaic, tiled out of stickies. Red,
orange, purple, green they all harmonized into a peculiar ornament that was
nearly ready to tell the story of Pacific Express. For someone who had left the room
in the morning when the walls were entirely empty, this picture would indeed
appear quite shocking.

Now its time to wrap up and present plans. Most teams decided that the Product
Owners would be the ones presenting. Stephanie shared the presentation agenda
with the group. Each team will present the PI objectives and the overall flow of the
plan, including key impediments and dependencies if any have been identified so
far.

The Spartans will present first. John, Tanya, Saheli and Josh stand as close to the
Spartans team area as they can in order to follow the outline of their PI scope.

In this PI, the team is going to pursue the following objectives:
- Coupon entry at Point-of-Sale
- Mirrored real-time transaction data transfer scripts
- Support of different coupon types
- Research and prototyping of earned points algorithm
- Basic discount points for registered customers

Our estimated velocity in Sprint 1 is 45 and the load is 42. Velocity in the second
Sprint is 40 with the load of 39 story points

29

He spent another minute describing capacity matching and giving the audience a
rough idea of what gets done in each Sprint.

We have dependency on the Data Warehousing team, he said, finishing his talk.

Stephanie brought the second mic and stood closer to the business owners.

I have a question, said John. What is that Mirrored data transfer thing?

Basically, in order to be able to apply a coupon at the point of sale, we need to
change the database structure, where affected tables have very high transaction rate
per second. This requires us to use mirroring tricks to capture all transactions that
will occur in the system, while the main corpus of data is being reloaded into a new
structure of tables.

Okay, John said without too much confidence. Are you sure this has business
value to the organization? I definitely agree that it is a necessary step to manage the
data transfer once the functionality is ready, but is it useful enough to be called an
objective?

Stephanie quickly jumped into the conversation: John, let me describe whats
happening here. What he just explained is not a one-time process. They are creating
a set of scripts that, once developed, can be used repeatedly for purposes like this.
Also, the scripts can be used with other tables with a minimum of modification. So
30
we are really talking about a re-usable capability that will recurrently allow our
company to implement the new functionality and always have a way to reload the
data within an extremely tiny maintenance window.

John nodded. I see I actually agree that it has value. Thanks Stephanie.

Any questions from the teams? I turned to the rest of the tables where team
members were all sitting together, just like they had done in the morning. After
three hours of highly intensive planning effort, they are all curious to see what
others have to present.

I have a question, shouted a guy in a yellow t-shirt with code snippets on it. What
kind of dependency do you have on us?

As the Spartans Product Owner began to explain, it became apparent that the
dependency had not been communicated to the other team. Stephanie didnt miss
this opportunity to remind everyone that they are supposed to not only identify the
dependencies, but also to resolve them. Nevertheless, the team definitely deserved
applause and the entire room exploded in cheers. We are moving to the next team.

The next presentation seems to go quite well and John does not have any questions.
Saheli ponders aloud some details of the functionality, but that was it from the
business owners side. Surprisingly though, this team also mentioned a dependency
on data warehousing team. Unlike the previous case, it was communicated to that
team, but it was also much bigger and riskier in nature.

Team after team, we gradually managed to go through the entire group. Some good,
some not so good, but every team had their PI objectives. Some teams ended up with
an unrealistic ratio of velocity and load, which was pointed out and taken as an
action item. The story with data warehousing did not end up on the first two teams.
With growing focus on retail analytics as a strategic theme, the Train ended up with
nine teams requiring assistance of the data warehouse team, mostly for logging the
data that newly implemented user scenarios would imply. This substantial
dependency issue made Stephanie very uncomfortable with the plan.

In the meantime, John looked very puzzled. On one hand he had the opportunity for
the first time in his career to see what teams are really intended to do. On the other
hand, something was deeply troubling him about what he just seen. A few moments
later he grabbed the mic:

Guys, I have a serious concern here. I realized that we are missing a lot in terms of
the pre-order functionality. This is a strategic direction for us. Some chains have this
functionality already, while we havent been able to deliver much of anything lately.
To compete with the rest in the race, we need to make a really bold statement that
will differentiate us and make our customers eager to use that functionality, over
31
and over again. We need to give them control over the process and we need to
enhance the transparency for these deceptively obvious user scenarios.

John is apparently eager to discuss this further, but thats what the next session is
for. We need to let the teams go for the day.

You guys did a great job today, said Stephanie smiling, but obviously tired. She did
a good job as well today, thats for sure. Whether or not she will be a facilitator for
Pacific Express I cant say, but she definitely understands this process and is
capable of pushing things forward. Sleep well and see you all at eight tomorrow,
she said, adding: We are still going to need Scrum Masters and Product Owners for
another hour today for the Management Review and Problem Solving session.

While the teams packed their backpacks and left, the rest of us swarmed around the
whiteboard. I explained the process to the group that is staying for this meeting:

We need to go though all outstanding issues and come up with the suggestions that
we will communicate to the teams first thing tomorrow morning. Lets list all the
topics

Pre-order functionality. Theres such a gap here that I cant believe it! said John in
a very emotional tone. Im also changing my schedule and canceling most of my
meetings for tomorrow. I dont want to come just to the final presentation and find
out that the teams planned something way out of alignment with the key themes. I
want to be here during the process itself, not only for the final review!

Stephanie gave me a funny look. This is a perfect development. John realizes that the
teams need him. He probably does not remember what happened less than five
hours ago in his office, when he explained to us how busy a person he is in this
company Ultimately, who cares? What matters is that hes here now, and he wants
to have even more interaction with the teams.

Another topic on the list was multiple dependencies on data warehousing. John,
however, quickly got us back to the previous topic:

We need them to add more pre-order functionality. I want to see options for user
pick-up and delivery, as well as for curb pick-up. I also want order status tracking
and status updates over SMS. We need to show our customers that this is a fast and
transparent process with multiple options. I also want automatic selection of closest
store location, and selection of an arbitrary store on the map. We need to make a
strong impression, guys.

Saheli and Josh promised to work with the teams the next day to add all of this to
the plan. It means that we will have to pull something out of the plan, said Saheli.
But since you are going to be here most of tomorrow, we can probably choose the
items to de-scope together.
32

John agreed to that plan of action and we moved to the second topic data
warehousing.

I dont think any of this will execute well during the PI if one team has almost every
other team on the Train depending on them, said Stephanie, looking to the others
for more opinions.

Guys, I had to help move this topic in the right direction, It is quite obvious that
the Data Warehousing team is going to end up with a pretty random backlog across
all the Sprints with that many dependencies in flight. It is impossible to realistically
plan and even worse to execute. This is not going to fly, Im afraid

Maybe we need to make sure we invite other Scrum Masters to this teams Sprint
planning every time just to make sure they are synchronously handling it, offered
Saheli.

Maybe we just need to split them up like we did with the maintenance team and
have those people join the teams that have the highest number of dependencies on
data warehousing, said Josh as he approached the board. How many developers
are on the team now?

Six, said their Scrum Master. And one tester

See? Josh smiled widely. They dont even have enough testers to make sure they
are doing the right thing. If wed move those six guys to other teams, their
functionality could at least be tested in the context of other important scenarios
those teams are working on. Well, this is the smartest thing Ive heard today! he
concluded, breaking into laughter, along with the rest of the group. Also, they didnt
even have a proud name, like Spartans or some other team of heroes What a
shame.

People are still chuckling, but Josh obviously has a point even though it was
delivered in his typically pompous manner. As Stephanie had noted in one of our
private conversations, Josh is usually in one of the three states: sarcastic, cocky or
simultaneously both. But regardless of that, he really gets it and this time he again
advised the correct course. As it turned out, the team didnt even have a Product
Owner, and the Scrum Master can be efficiently used with the newly formed System
Team that needs one very badly, but doesnt have one. The decision was supported
by everyone and would be announced the next day.

* * *

An hour later I was on the trail, running my 5k down the beautiful shores of Del Mar.
The ocean looked like a huge, live mirror, breathing and spitting out splashes of the
pure, late evening tides. My brain was slowly getting back to normal and my GPS
33
watch was still giving me hope that I could cover the distance in twenty-five minutes
today. My running belt pouch rhythmically scratched my back in time with my
pace

Wait it is actually my phone vibrating. Someone is calling. I quickly rotate the belt
180 degrees moving the pouch to the front Im trying to grab my phone without
slowing my pace. Its Stephanie Oh Not now! Now I have to stop

Ryan, we have a problem. Do you remember some guys, the development
managers, that you met quite a while time ago at one of our first discussions?

Yes, I think so my brain busily scans for a picture.

Well, I wonder if you noticed them in Town Hall today?

No, I dont think so

Turns out they were there.

But wait I dont remember them at our last session. We only had like twenty five
people total I would have noticed them.

See, thats the problem, Stephanies voice sounded even more worried. They
stayed during the breakout session and then for the plan review, but left right
afterwards. In fact, they did not leave the office. Do you remember seeing Tanya at
the problem solving session?

No. I remember her and John during draft plan review, but she wasnt participating
much.

Right. So after that session she and her development managers conspired in her
office, complaining about this whole initiative and the planning process.

What?!

Yes. They complained to her that with the new process, they feel like they are not
needed anymore. With teams planning on their own, they feel nobody cares about
their opinion.

Crap

Yep. Tanya called me and voiced the seriousness of her concerns, saying that she is
going to talk to our CIO and express them to him. We need to do something ASAP.
Ryan, you and I need to meet at the office tomorrow at seven and think through the
next steps. Can you do that for me please?

34
She sounded totally desperate. But it was depressing indeed. We had had a pretty
good day, but with an unexpected, bitter ending.

Listen, Stephanie, I have an idea. We will need to talk to all of them tomorrow,
including Tanya. I have something to present to them. Im sure we have a chance to
fix this misunderstanding.

We better have a chance, she said in a very depressed voice. Thank you, Ryan.
Thanks for helping with this. Im really worried about it all. Thank you and lets do
all we can tomorrow, okay? Thank you.

She hung up, but her deeply disturbed voice still echoed in my mind. This is a very
unnecessary complication, but we will give it our best shot. We will delve into the
heart of the problem, instead of running from it. Tomorrow she and I will win big
or lose big, but tonight I dont even want to think about it.

35
V. TROJAN HORSE

I feel like Im sending a sheep down among the wolves, Ryan. Im sorry. But, you are
right, the Train needs me in Town Hall.

Stephanie, have you ever heard of a sheep that can bite? A sheep that hunts to kill?

Very funny. I talked with Tanya this morning. She agreed to at least listen to you
first, and then decide what to do. That means that shes not going to go to the CIO
and bitch about us right away, shell give it a chance she probably wants to savor
it Stephanie smiled, but the smile was pretty pathetic.

Dont worry about me. Ill do what I have to do. Please make sure the changes to the
team composition and scope of work are properly communicated before you kick off
the breakout session today. And remember, they have to get to the stretch objectives
and John must assign business value to all PI objectives the teams have.

Stephanie nodded and smiled without saying a word. Only now did I realize how
different our positions are and whats at stake for her. I certainly want this
implementation to be successful and will do all I can to make it happen, but shes
probably putting her whole career at stake here. Whats the worst that can possibly
happen to a consultant whose method is not adopted? They never invite me again?
Big deal. But Stephanie could easily lose her job in a political fight like this. I cant let
that happen

Guys, you all know Ryan. Hes here with us today to address our current concerns
with the process. Feel free to ask questions thats why we set up this session.
Right, Ryan?

Thats right. Thank you, Tanya. Actually, before we get started with questions, I
want to present some initial thoughts to you guys. Some things to think about, some
things to chew on.

Tanya and her crew were sitting at the same table, their body language saying more
than a thousand words possibly could. Some had their arms folded across their
chests, others were settled deep in their chairs all of them sported pretty annoyed
expressions. Awesome Should be piece of cake to melt this iceberg. I can admit it
to myself now Im really, really worried. But I move forward:

We are here because of a fundamental question: what is the role of the leader in a
Lean-Agile enterprise? Many of you have operated in an environment that employed
some team-level Agility. All teams were using Scrum as their basic process. But do
you know what Scrum says about management?

36
The awkward silence drives me crazy. I need them to participate, instead of showing
how disconnected they are.

Guys?..

A few more moments pass in complete silence.

Nothing? The guy sitting closest to me guesses. It says nothing?

Oh, thank goodness for any answer at this point, because the right answers up-front
is not what matters in our little Socratic experiment here. I just need them to
abandon all bias and start thinking.

Close. But its actually a little worse than that. Have any of you heard the story of
the Chicken and the Pig?

One person nodded: It says were chickens, because we are not committed to the
successful outcome for the team. At least it doesnt call us pigs.

The others chuckled.

You have probably also heard that Scrum Master is the one who removes all
impediments for the team

They all nodded.

So, how many real impediments in this program did they remove so far?

Again, they chuckled.

Unfortunately, at scale this turns into a rhetorical question. But please dont think
that this is because your Scrum Masters are bad, or Scrum per se is misleading.
Scrum is a great method that undoubtedly revolutionized the way teams work. At
scale, however, different forces come into play. For that reason, leadership is a
whole separate domain in Scaled Agile Framework. It provides critical guidance to
those who actually can eliminate systemic impediments in large programs like
Pacific Express managers that have sufficient authority to change things for the
better.

The posture and the expressions on their faces began to change from challenging to
confused. I proceeded:

Teams always try to do their best. But they are the hostages to the system they are
part of. We know this from our own decades of experience. If you put people into
functional silos, no matter how hard they work the value will flow very slowly
through the system, and the resulting quality will be unacceptable. Do you think
37
those departments could themselves re-organize into cross-functional teams in any

of those organizations? Did it happen on its own in yours?

Now it looks like they have started paying even more attention. I have to proceed
down this path. This problem has to crack.

I doubt it. Im sure management made the decision and assisted in identifying the
new team composition for Agile teams

The guy right next to me the one so familiar with the Scrum folklore nodded and
looked around the room: Hes right. We actually did the transformation, although it
only affected a few teams. The rest of the program was hired afterwards, and we
already knew how to package them into Scrum teams.

Good. Now, are you aware of the concerns product people have with respect to the
program?

We are, he nodded again.

Would you agree that given current structure and process, the teams are ideally
suited to continue producing their own chunks of value independently and,
conversely, not driven at all to synchronize and integrate across the board.

Yes

If you folks will not support them in the adoption of practices that foster alignment
and incremental development of the whole solution, they will fail, but through no
fault of their own. Stephanie said that you were concerned that teams are planning
without you; that you have nothing to do now with the advent of the new process?

The looks on their faces shifted from puzzlement to shock. We will either resolve
this once and for all, or I will be thrown out of this room. Tanya remained very
suspicious.

Last night I prepared some bullet points for you guys, I hooked up the HDMI cable
to my laptop and the title slide gradually showed up on the projector screen: What
Do I Do as Lean-Agile Leader. I hit the clicker and moved to the first slide:

Help the teams advance Scrum practices
Help with Scalable engineering practices, namely: frequent integration and
automation
Help remove organizational impediments that impede the flow of value
Teach the teams vertically slicing business value
Engage the business and upper management in active alignment with teams

I move to the next slide:
38
Understand role bottlenecks and provide better balance of force

Help teams eliminate long term dependencies through cross-discipline
orientation
Lead/establish/support communities of practice
Help the program in visualizing WIP, variability, and hidden dependencies
Coach teams in effective continuous improvement techniques

and the next one:

Help upper management and business understand and embrace Lean
thinking
Understand and exploit specific nuances of knowledge creation and sharing
in the program
Identify key factors that build trust between the teams and the business
Create a tangible improvement roadmap for the program and lead the teams
through the improvement journey
Foster team and program spirit of self-organization

The expressions on their faces began to change. So, does anybody still think there is
a deficit of involvement for a leader in a Lean-Agile enterprise? Oh, but wait, there is
more! I hit the clicker again:

Help teams engage into highly collaborative intra- and inter-team workshops
in identifying requirements, elaborating design, etc.
Provide necessary guidance on soft skills and collaborative techniques
Enable spontaneous situational leadership among the team members
Improve/influence/change outside (with respect to the teams) processes
such as deployment, compliance validation etc. Shorten external components
of the overall lead time in end-to-end value delivery
Create a balanced, decentralized decision making model that covers a
majority of the risky areas

And again:

Engage all necessary stakeholders in program backlog refinement and
economic prioritization
Foster collaborative culture within the teams (side-by-side work, rotation
over functionality, etc.)
Keep external teams and individuals aligned, motivated and capable of
collaborating with the program
Assist programs in exchanging practical knowledge

And certainly there are many more real life examples that I did not include. After
Stephanies call yesterday, I timeboxed myself to twenty minutes and came up with
these five dense slides.
39

The gentleman next to me rubbed his forehead and said: Thats a lot of things
indeed, Ryan.

It is a lot, youre right. But let me tell you the trick we use to get that many touch
points in a Lean-Agile environment. Did you notice a single item on that list that
would actually have anything to do with managing the teams per se?

No

Exactly. 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?

No, Ryan, I understand your point, the same gentleman said. I dont know about
you guys, he turned to the rest of the group, but I think we are in the wrong room
right now. Our teams need us in Town Hall. He rose from his chair and walked
towards the door. Other guys quickly jumped off their seats too, and followed him.
Tanya alone remained. She stayed in her chair for a little while, then finally sighed
and headed towards the doors without a single word. However, unlike the others
that had exited the room and moved quickly to the left, she turned to the right,
which clearly is not the way to Town Hall. Somehow I feel that this isnt over yet.
Not with Tanya, anyway.

However, one important battle was won today. Four of the development managers
returned back where they belong helping their teams. I took a few minutes to
decompress while disconnecting my laptop. Suddenly, Stephanie appeared in the
doorway all shiny and happy, like you are at your 12th birthday party.

Ryan, I dont know what you did to them, but they all ran into Town Hall, split up
and started discussions with their teams. Im staggered, Ryan. Thank you so much!

Yeah, but Tanya didnt seem to

Oh, dont worry about it thats business as usual for her. Shell stab us in the back
later thats her style. Lets go now. Saheli just texted me that something is going on
there. We need to go back.

She put her phone in her pocket and added: You know, John is absolutely rocking it
there. Hes running around the room and hes probably met with every team
already, some even twice. Hes assigned business value to basically all teams
objectives, as you said, just a relative number one through ten, and assisted many of
40
them in determining what they should set as a stretch objective. I even heard him
talking on the phone earlier today, canceling some of his meetings, saying something
like I need to be here today, I need to finish this first and so on And then he
simply hung up, Stephanie smiled.

I automatically smiled in return, but realized that for the last couple of days I hadnt
been smiling much. However, all this time Stephanie had been around and despite
all the hardships of this adventure, she was the one human being I was so
desperately glad to see every morning. We would talk through the plan for the day,
discuss problems and share concerns. Was that just a reflection on the fact that she
will probably make the best Release Train Engineer Ive ever known, or am I taking
the Lean tenet of Respect for People to a whole new, somewhat personal level?
Concentrate, Ryan, this adventure is not over yet. It will be over when the business
owners tell us they are happy with the plan, and the teams confirm they can deliver
the value.

Stephanie opened the door and the scene before us was absolutely stunning. It
appeared that team members had re-shuffled. Some of them joined two
development managers in the corner by the window, busily crafting something I
hadnt seen before.

Hmm Stephanie looked around and said: Looks like lots of the team members
are working now in their peer teams areas. Dependencies, I would guess. And what
is that? she pointed at the corner that had me completely puzzled.

Saheli approached us and pointed to the same corner: Guys, I dont know what
happened, but about thirty minutes ago Brian and some other development
managers literally ran into the room, circled a time or two, carefully observing the
team plans, and then started offering help to the teams that needed it. They quickly
noticed that the Wolverines had some dependencies on the Spartans, but that those
were actually based on false timing expectations. Something that was expected by
the Wolverines in Sprint two was actually to be delivered only in Sprint four by the
Spartans. Then Brian I quickly realized that he was the one leading the merry
company back to Town Hall Gathered the other managers and the Scrum Masters
and started mapping those dependencies for the Train.

Thats actually what they are doing there in the corner as we speak creating a
dependency board. Its a matrix with teams as rows and Sprints in the PI, as
columns. There are stickies of two colors: blue and red. Blue stands for a feature. If a
blue sticky is in a particular cell, it means that that feature will be finished by the
team in that particular Sprint. But other teams may also have inputs to that feature,
which are the red stickies connected to the blue ones with the string. I have no idea
where Brian found the string, but it seems like they know what they are doing.
Within the last ten minutes, they found four more dependencies between teams that
were not synchronized in time. Thats why the teams are now working with one
another they are re-planning for those dependencies.
41

Wow. I was certainly expecting Brian and his fellow managers to come and help
their teams, but I was not expecting miracles. Meanwhile, Brian was so busy there at
the board that he hadnt even noticed us.

But thats not why I texted you, Stephanie, Saheli went on. Team Moria has no
stretch objectives. They are saying they dont have any choice other than to commit
to 100% of the scope that they have on their sheets.

What are they working on? I have seen such things a couple times before, but
every time it was for a different reason.

They are basically working on legal and compliance backlog items. Lets go talk to
them.

We dont have any other choice, said the Scrum Master of Moria. If we dont finish
this whole scope, he waived his hand across the sheets with stickies, We will not
be able to even sell most of our perishable goods, nor will we be able to take debit
and credit cards. These are mandatory things to do and we just have to roll up our
sleeves and make it happen.

I moved a little closer to the Sprint sheets to see the numbers: But those Sprints are
fully loaded. Some are even over capacity.

Yeah, but there is nothing we can do
42

Look. The fact that this entire scope needs to be delivered doesnt automatically
make it possible. The urgency of this scope and your teams ability to deliver are
practically unrelated things. If we do that, if we simply accept this plan and assume
that the team will do miracles, that will surely lead to a much bigger problem later,
because you will simply fail to deliver.

Stephanie was carefully reading the teams objectives. Im sure that the Argonauts
can help you with this one, she pointed at Synchronized tracking of used-by date
through the supply chain. Lets get their Product Owner over here. And this one
In-memory encryption mechanisms Im sure it can be addressed too.

In the next twenty minutes, they adjusted the plan and the two teams that had
offered help pulled out some less important items from their backlogs. Team Moria,
in turn, picked some future research items as their stretch objectives, which they
would be able to get to once they got some breathing room.

The second breakout was approaching the finish line. Teams were still making
adjustments, but it seemed like they were finally ready to present decent plans to
the business owners. The last short break before the final plan review does not,
however, seem to distract the teams from their planning areas. Most kept discussing
various items, pointing at the Sprint sheets. Some walking to the dependency board
and back

43
VI. SAVED BY DISBELIEF

Accepted, said John merrily, glancing at Saheli and Josh. The guys nodded and gave
a big thumbs-up as the whole room applauded the product owner of the Spartans,
who had just finished presenting their final plan. The presentation went pretty fast,
generating very few questions from the business owners. Stephanie asked their
product owner to gather their objectives- and risk sheets and bring them to the
front wall, where the other four teams had already attached theirs after presenting
them to John. Team Erebor presented next, which took their product owner only
three minutes. Basically every team was trying to focus their presentation on the PI
objectives, and the business value assigned to those objectives by the business
owners. And at the end, explicitly going through the stretch goals for the PI, as this is
something that may or may not be delivered and thus needs to be called out. Finally,
John and the guys approved the last team plan and the front wall received the last
piece of the program plan.

What do we do now? asked John while rubbing his hands.

Risks. Program risks, I answered John, as I took the microphone and addressed the
whole group: Now, there is one more thing that lies between us and the
commitment risks. We will go through all the teams risk sheets one-by-one and
build a consolidated risk sheet for the program.

In the meantime Stephanie attached four new flipcharts to the windows and named
each one of them:

44
Resolved.
Owned.
Accepted.
Mitigated.

Lets ROAM, she said and picked the closest risk sticky from the Argonauts risk
sheet and read it out loud to the group: Class dependency mapping for VB.Net to C#
module translation. She raised the sticky up in the air and asked for someone to
comment on it. One of the Argonauts quickly jumped out of his seat: We have the
tool to assist us in the initial translation of the VB.NET module, but since we know
that such tools are not perfect, and we will still have to manually check a lot of real-
time dependencies between instances of classes, we would like to have some
automatic way to validate whether the dependencies were preserved in a translated
C# source code. Without such a thing, we could actually be slowed down quite
substantially

I know some tools, Todd, the architect, raised his hand. I can show you at least
two of the tools that I know, but you guys will have to take it from there.

Great, said Stephanie. She put Todds name on the sticky and moved it to the
Mitigated sheet of the consolidated program risk area.

She picked the next sticky and then the next More and more stickies appeared on
the program sheets. Some werent actually that risky, as clarified by other team
members. These went to the Resolved sheet. Others we could do nothing about and
those were put in Accepted. She finally pulled the last sticky from the last teams
risk sheet:

Heres the last one from Ninjas. Releasability. Stephanie looked on the other side
of the sticky but did not find any further detail. Very specific, she smiled and asked
for the author of that sticky to elaborate

We have an overly formal process with our release operations. We never know if a
release is going to happen smoothly or if we will have deployment issues, like we
have had multiple times before. If we keep doing it this way, we may not meet the
dates, said Ninjas Scrum Master.

Ill take it, said Brian. I hear what you guys are saying and Im not too crazy about
the brick wall between you and the deployment operations team. We are going to
change this and Im taking responsibility over this item, said Brian, proudly adding,
Please put my name on that one.

Looks like Brian is totally into his role as a leader an enabler.

Thank you Brian, that would make our life 2.5 times easier, said the Scrum Master.

45
Brian was absolutely shining: My pleasure

The ROAMing session was over. We decided to remove the Resolved sheet from
the window as tracking those items was of no value.

Stephanie handed me the microphone for the culmination of the PI planning session
the Team Confidence Vote.

Thank you Stephanie. You guys have probably noticed that the key to this planning
process is not to have the management plan for you, but to have you plan for
yourselves, to have you manage dependencies and risks. It is not enough that the
business owners approve your PI objectives. That only means that they have
confirmed to you your understanding of what they want you to build. You and only
you, can commit to that scope. So now Im going to ask every team to do a simple
confidence vote. Each team member will have to do fist-of-five to show your
confidence level in delivering this scope in ten weeks. If the average is three or
more, we take it as a sufficient confidence level. So, Ninjas, lets start with you.
Ready? Three, two, one, go!...

Five, four, five, five, four, three, four. Very good. I think that deserves some
applause.

The room erupts in cheerful applause. The next team vote count is almost all fives,
as is the next one.

Argonauts. Ready? Go
46

Wow. We have a one! What? A one?

We need to hear from you sir, Stephanie makes her way with the microphone to a
developer who, I hope, simply misunderstood the process. Hes the guy I had noticed
walking around the room during the risk management session. He had been staring
at other teams plans and taking notes. Well, lets see what hes got.

Im a developer that was previously on the maintenance team that was disbanded.
Now Im with Argonauts and I brought some backlog items with me from that team.
You can see those in our plan those purple stickies. He pointed to the far corner
where his new teams Sprint plans were hung. Then I realized that some routine
bug fixing that I used to do myself was not on my team plan. I wondered where it
went. I started walking across the room and looking at other teams purple stickies.
What I found was that not only is that bug fixing scope nowhere in the plan, but that
the overall amount of maintenance work across the teams seems to be considerably
below our prior workload, compared to when I was part of the maintenance team. It
was actually quite easy to figure out. Two days ago Ryan taught us Normalized
Estimation, which is basically about starting with the same basis for a story point
across the Train, in order to be able to compare different backlog items. Something
doesnt add up. I think we are missing a lot of critical maintenance work, guys.

Brian and Todd where already walking around the room. Other team members
stood up and started looking in their plans. Brian was making notes and when he
finished his first pass around the room, said:

Hes right. We missed a whole bunch of things that we used to do. We have to re-
plan.

In the next thirty minutes, Brian and all of the ex-maintenance team members made
a quick check and identified the missing areas. Meanwhile, the other teams product
owners worked with Saheli and Josh to determine what they could pull out, or at
least move to stretch, in order to make room for more maintenance effort. Finally,
when the adjustments where made, all the teams returned to their tables. The walls
blossomed with a comforting purple color.

Almost forty percent maintenance missed?! Brian took the microphone. Sergey,
thank you for voicing those concerns, he pointed to the developer who had spotted
the problem. I think if we all have courage and attention to detail like Sergey just
demonstrated, Pacific Express has a great chance to succeed.

After this change we obviously had to redo the confidence vote, but this time all the
teams voted quite quickly and all of them far exceeded the required minimum.

Now, guys, I took the mic again, we have dependencies on one another, and we
have to frequently synchronize and integrate our work. We have to operate as a
47
Train, not just as individual Agile teams. This means that we must have a final vote
as a Train all of us. If you have any concerns, if you think that some of those things
in the plans we, as a Train, will not be able to accomplish now is the time to say it
out loud.

Everyone raised their fist-of-five. And I can see that the votes are well above the
three-point average. Which means we are done.

Congratulations, Pacific Express. You got your plan. It was my pleasure to assist you
in this venture, but keep in mind that you essentially did all of this yourself.

John suddenly picked up a second microphone and joined me on the stage: Ryan, I
think we all owe you one. After going through these two days of planning, I now
realize how much we accomplished in terms of alignment and gaining a true
understanding of what we are building here. I think we all learned a lot in this
process. And, as the one and only true representative of the business here in this
room, I can tell you that I am really happy with the outcome. I think weve got a
plan

* * *

One hour later, Stephanie and I, tired but very happy with the result of the session,
were ordering appetizers at Tapenade restaurant in La Jolla. She said that the other
guys were not able to join us, which I absolutely believed to be the case. At least this
would let us have an honest conversation about the flow of value, limiting WIP and
controlling the queue length... And in the morning I will take off

48
EPILOGUE

It was a gentle afternoon rain, tapping softly on my porch and trying to seduce the
entire world into a nap. It may be the last rain of the season whatever falls next out
of the sky is likely to freeze before it touches the ground. The grass has all turned
yellow and my garden is withered almost ready for the harshness of winter.
Loaded with coffee, I was busily working on a presentation that would hopefully
expand into a brand new training course some day. I was taking a longer break from
traveling: being on the road all the time leaves no time to invent new things and also
leads to the desolation of my garden. Both require time to grow, both need attention
and effort to result in something pleasing to the eye. Theres not much growing
outside this time of the year only dry stems poking out of the ground. Only my
little spruce is full of resilience and life. This is the perfect time to rearrange the
flower-beds and re-pave those tiny little pathways between them.

I was finishing the current slide as well as my second cup of coffee when the phone
broke the silence with its rhythmic humming, slowly shifting on the table in random
directions. It was Stephanie calling.

Ryan, how are you? Is this good time to talk? Our first PI comes to conclusion in
about two weeks and we need you to help us with the program Inspect & Adapt
workshop. Sorry for such short notice, weve all been really, really busy

She told me how they had failed to integrate the system early on and how that led to
a failed system demo after Sprint one. Consequently, Tanya had come back almost
immediately with a lot of criticism and begun busily campaigning among the
executives to shut down SAFe adoption.

But heres what happened, Stephanie proceeded, She faced a relentless
resistance from her own development managers. I cant tell you how many conflicts
between Tanya and Brian I personally witnessed. And those were no fun to listen to,
trust me. But Brian and other development managers provided assistance to the
teams in every imaginable aspect. They all swarmed around the integration problem
and guess what? In Sprint two, we witnessed our first system demo. John attended
and was as happy as a kid in a candy store, asking guys to run this and to click that
and ended up taking over the keyboard. Certainly we had to de-scope a little to
recover from our sluggishness in Sprint one, but it was a good demo nonetheless.
Immediately after the demo, Brian ran around the entire building and personally
thanked every Agile team. Since then we have had a fully integrated increment every
Sprint. Yesterday was our last system demo and today we started Sprint five.

We need you very badly for the last couple days in this Sprint, where well do the
grand demo of the entire PI scope. This time not only will John be there, but other
guys from the business side said they would like to attend. Also, our CIO will be
there. Stephanie paused for a couple moments. You know, they actually redefined
49
Tanyas position. She still holds that job, but development managers no longer
report to her. Also, Brian was promoted to a director of development, which is a de
facto replacement for Tanya. Anyway, we see her less and less now which is a big
win for everyone, she chuckled. So Can you come?

Yes. I will.

Awesome sauce! She said, bursting into laughter. I have one other question for
you though.

Yes

We have only now begun to realize that we achieved a qualitative shift in progress
tracking by producing fully integrated increments of the solution every two weeks.
But we also realized that now, as we are ending the PI, we dont have a single metric
to show how successful it was for the Train as a whole, or to see how good we did as
individual teams. We will certainly have the grand PI demo, but that doesnt allow us
a finer perspective on our accomplishments. And it is a pity that we have only now
realized that we dont have a single metric at our disposal, here at the end

Oh, that is so not true. You guys have a metric already.

No we dont.

Sure you do. Whats on all those PI objective sheets the teams have?

Well, committed objectives, stretch objectives and business value for each one of
them.

There you go! But that is planned business value. Thats what business owners
ideally expect from the teams. Now is the time to let John and his guys fill out actual
business value, as they perceive it based on the upcoming PI demo. Imagine this.
You will have two columns on every sheet: planned and actual. Each team will then
add them up and get two numbers: total planned and total achieved business value.
Your metric is the ratio of the two. The numbers then can be consolidated and, voila,
youve got your metric for the Train. By the way, if you want to measure anything at
all for the Train, you want to measure this. And this metric has some magic: it gives
you an idea of productivity, but expressed in the most relevant currency possible
percentage of achieved business value. And who defines those numbers? Those in
the organization who ultimately determine value. You can never be wrong when you
directly ask the business instead of speculating on your own.

Ryan this is awesome. Im so looking forward to seeing you

Seems like the Train is acquiring momentum. Im actually glad they failed their first
system demo in Sprint one. At least now they clearly understand that our initial
50
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. But there is something different about Pacific Express
now. They have learned, although it was through much pain, how to deliver end-to-
end value. That should open their eyes to all other things. Most programs cant
improve because they are blind to the things that really matter they dont see the
system as a whole. Neither the one they are developing, nor the one they are
themselves part of. This Train, it seems, succeeded with this first, smallest but most
important step they acquired the bigger picture view.

The rain has almost stopped. A few drops can still be seen here and there, flaring in
the air, as the clouds start to give way to the magnificent azure sky. I cant sit and
stare out in my window any longer I need to go outside and feel the last touch of
the rain, the kindness of the sun and the playful breeze from the mountains that
wear their stunning white mitres quite prematurely this year.

51

Pacific Express - Alex Yakyma - Scaled Agile

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pacific Express - Alex Yakyma - Scaled Agile

Uploaded by

Copyright:

Available Formats

Alex

ABOUT THE AUTHOR

2014 Scaled Agile, Inc.

FOREWORD BY DEAN LEFFINGWELL

2014 Scaled Agile, Inc.

I. THE BLACK HOLE

2014 Scaled Agile, Inc.

How long does the preparation stage take? wondered Stephanie.

2014 Scaled Agile, Inc.

II. LAND OF THE SLUMBERING SUN

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

III. GETTING THEM BACK

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

IV. BITTER TRIUMPH

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

those departments could themselves re-organize into cross-functional teams in any

Understand role bottlenecks and provide better balance of force

2014 Scaled Agile, Inc.

VI. SAVED BY DISBELIEF

Brian was absolutely shining: My pleasure

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

2014 Scaled Agile, Inc.

You might also like