Pacific Express - rev 3 · © %2014%Scaled%Agile,%Inc.% 5...

Alex Yakyma

PACIFIC EXPRESS

© 2014 Scaled Agile, Inc. 2

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. Alex’s 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 [email protected] Follow on Twitter: http://twitter.com/AlexYakyma ISBN 978-‐1-‐4951-‐2790-‐8


FOREWORD BY DEAN LEFFINGWELL Building really big software systems is one of the most challenging intellectual endeavors facing today’s businesses. To help address this challenge, we’ve 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 lives—not just of the users for whom we build these systems—but 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 let’s 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. Let’s 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 don’t particularly enjoy other people’s 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 – that’s going to make this easier for all of us. Whether it’s increasing executive pressure she’s under (it was noticeable even during our first phone call) or just her personality, I think I like the direction this is heading. She doesn’t seem to be overly invested in their current methods and tools either. Maybe she’s 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 don’t 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 didn’t 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, don’t 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. “I’m Saheli, I’m 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 I’m 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 résumés. 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. “That’s 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 you’ve 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 can’t figure out to whom she could possibly be referring, but that’s not what’s important right at this moment. “I bet those other cases weren’t 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 that’s 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, that’s the first two days. Then, for the next two days, we will plan our first Program Increment: PI for short. Roughly speaking, you can think of it as a release planning session. And finally, the last day can be used for Product Owners and Scrum Masters to dig deeper into the advanced topics of how to operate at scale. The Quickstart is just a kick-‐off for you guys, but should provide enough momentum to drive the transformation.”


“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 let’s not forget all the logistics for the Program Increment planning.” “Logistics? Like what?” she asked. “Well, it’s 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…” “That’s 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 aren’t 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 can’t 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. “That’s 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 don’t,” interrupted Josh. “They pretend that dependencies don’t exist. They each iterate in a complete vacuum, every single team. And that’s 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… It’ll 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, that’s 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 can’t imagine how we sell it to the business stakeholders or even to the teams. There will be a lot of resistance. We’ve 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? That’s a tall order.” “I understand, but I’ll 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 – there’s 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. It’s 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 Josh’s 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 don’t 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 won’t just ‘hear’, it’s 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 it’ll be a tough sell. Nor, I’m 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 I’m 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 – wouldn’t 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 what’s in it? Sprint after Sprint, almost no changes occurred in


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 couldn’t 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 isn’t 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 didn’t 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.


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 Stephanie’s 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 there’s 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. That’s embarrassing, but Stephanie and I are going to prove that it’s the real deal, or fail and fail big tomorrow. But that’s 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.


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 aren’t 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 audience’s 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, it’s always a big deal. “Yes, Stephanie’s 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 let’s make sure we


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 (50–125 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.


“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; it’s 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 – let’s 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 that’s not always the case. Think of some milestones like supporting user-‐testing event, for instance. It’s 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


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 other’s 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). That’s 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, don’t 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. Let’s 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.


“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 company’s 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


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 silo’ed 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. Tanya’s 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 didn’t 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 Stephanie’s 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.”


“For what? I’m 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 wasn’t right.” “It wasn’t. 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 I’m sorry. Let’s 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 didn’t 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 can’t spend any more time on that,” said John when Stephanie voiced the request. “Tanya and I spent almost an hour there already. I don’t 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 Train’s 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 wouldn’t 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. I’ll 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


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 don’t. 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 doesn’t 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 don’t expect much. I can give you about an hour more today and about the same amount of time tomorrow.” That’s far from perfect, but we’ll have to live with it. It’s 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.


“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, I’m 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.” “That’s okay. At least we have them for two more hours now. Let’s 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.


“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. That’s 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 I’ve 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 don’t 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 program’s attention.


“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 o’clock. Let’s 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 that’s the case…


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. That’s a very good sign – that’s 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 haven’t 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. It’s too early to get real excited, but in the meantime, the first Scrum Master check-‐in is going to happen in thirty minutes – let’s 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 it’s 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. It’s 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.


Let’s get started. First entry: ‘Are features broken down into stories?’ I’d like to hear from you guys, team by team now. Avengers?” “No, not quite finished yet,” said the Scrum Master of Avengers. “We’re 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. I’m 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 – it’s going to be a check mark… simple! So, Avengers?”


“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. That’s 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?” “I’m afraid we’ll need all Scrum Masters because it is going to affect the entire Train. I also need Sunil – a developer from my team…”


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 I’ll 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 don’t 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.” She’s 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 we’re 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 don’t 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


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 Bill’s 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.


John and Tanya showed up a few minutes before four o’clock, 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 it’s 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…”


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 what’s 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


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 didn’t 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 haven’t 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


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 that’s 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, that’s for sure. Whether or not she will be a facilitator for Pacific Express – I can’t 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. Let’s list all the topics…” “Pre-‐order functionality. There’s such a gap here that I can’t believe it!” said John in a very emotional tone. “I’m also changing my schedule and canceling most of my meetings for tomorrow. I don’t 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 he’s 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.”


John agreed to that plan of action and we moved to the second topic – data warehousing. “I don’t 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, I’m afraid…” “Maybe we need to make sure we invite other Scrum Masters to this team’s 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 don’t even have enough testers to make sure they are doing the right thing. If we’d 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 I’ve heard today!” he concluded, breaking into laughter, along with the rest of the group. “Also, they didn’t 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 didn’t 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 doesn’t 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


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 – I’m trying to grab my phone without slowing my pace. It’s 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 don’t think so…” “Turns out they were there.” “But wait I don’t remember them at our last session. We only had like twenty five people total – I would have noticed them.” “See, that’s the problem,” Stephanie’s 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 wasn’t 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?”


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. I’m 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. I’m really worried about it all. Thank you and let’s 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 don’t even want to think about it.


V. TROJAN HORSE “I feel like I’m sending a sheep down among the wolves, Ryan. I’m 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 she’s not going to go to the CIO and bitch about us right away, she’ll give it a chance… she probably wants to savor it…” Stephanie smiled, but the smile was pretty pathetic. “Don’t worry about me. I’ll 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 what’s at stake for her. I certainly want this implementation to be successful and will do all I can to make it happen, but she’s probably putting her whole career at stake here. What’s 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 can’t let that happen… “Guys, you all know Ryan. He’s here with us today to address our current concerns with the process. Feel free to ask questions – that’s why we set up this session. Right, Ryan?” “That’s 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 – I’m 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?”


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 it’s actually a little worse than that. Have any of you heard the story of the Chicken and the Pig?” One person nodded: “It says we’re chickens, because we are ‘not committed to the successful outcome’ for the team. At least it doesn’t 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 don’t 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


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. I’m 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: “He’s 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:


• 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 Stephanie’s call yesterday, I timeboxed myself to twenty minutes and came up with these five dense slides.”


The gentleman next to me rubbed his forehead and said: “That’s a lot of things indeed, Ryan.” “It is a lot, you’re 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 don’t 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 isn’t 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 don’t know what you did to them, but they all ran into ‘Town Hall’, split up and started discussions with their teams. I’m staggered, Ryan. Thank you so much!” “Yeah, but Tanya didn’t seem to…” “Oh, don’t worry about it – that’s business as usual for her. She’ll stab us in the back later – that’s her style. Let’s 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. He’s running around the room and he’s probably met with every team already, some even twice. He’s assigned business value to basically all teams’ objectives, as you said, just a relative number one through ten, and assisted many of


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 hadn’t 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 I’ve 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 hadn’t seen before. “Hmm…” Stephanie looked around and said: “Looks like lot’s 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 don’t 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. “That’s actually what they are doing there in the corner as we speak – creating a dependency board. It’s 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. That’s why the teams are now working with one another – they are re-‐planning for those dependencies.


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 hadn’t even noticed us. “But that’s not why I texted you, Stephanie,” Saheli went on. “Team Moria has no stretch objectives. They are saying they don’t 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. Let’s go talk to them.” “We don’t have any other choice,” said the Scrum Master of Moria. “If we don’t 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…”


“Look. The fact that this entire scope needs to be delivered doesn’t automatically make it possible. The urgency of this scope and your team’s 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 team’s objectives. “I’m sure that the Argonauts can help you with this one,” she pointed at ‘Synchronized tracking of used-‐by date through the supply chain’. “Let’s get their Product Owner over here. And this one – ‘In-‐memory encryption mechanisms’ – I’m 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…


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:


Resolved. Owned. Accepted. Mitigated. “Let’s 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 Todd’s 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 weren’t 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 team’s risk sheet: “Here’s 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. “I’ll take it,” said Brian. “I hear what you guys are saying and I’m not too crazy about the brick wall between you and the deployment operations team. We are going to change this and I’m 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.


Brian was absolutely shining: “My pleasure…” The ROAM’ing 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 I’m 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, let’s 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…”


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. He’s 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, let’s see what he’s got. “I’m a developer that was previously on the maintenance team that was disbanded. Now I’m 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 team’s 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 doesn’t 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: “He’s 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


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 we’ve 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…


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. There’s 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, we’ve 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 here’s what happened,” Stephanie proceeded, “She faced a relentless resistance from her own development managers. I can’t 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 we’ll 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


Tanya’s 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 don’t 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 doesn’t allow us a finer perspective on our accomplishments. And it is a pity that we have only now realized that we don’t 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 don’t.” “Sure you do. What’s 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. That’s 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, you’ve 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. I’m so looking forward to seeing you…” Seems like the Train is acquiring momentum. I’m actually glad they failed their first system demo in Sprint one. At least now they clearly understand that our initial


sessions, including the PI planning, were not the transformation itself. There is a reason why it is called Quickstart. In fact, it is only the beginning of a learning journey that knows no end. 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 can’t improve because they are blind to the things that really matter – they don’t 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 can’t 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.

Date post:	24-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Pacific Express - rev 3 · © %2014%Scaled%Agile,%Inc.% 5...

Documents