Good PI Planning is the Enemy of Great PI Planning

When I first met Dean Leffingwell (the creator of SAFe), I had already launched the EDW Release Train - without doing PI Planning. I was attending one of the early SPC classes in Boulder, CO. It was day three before I built up the courage to ask Dean the question that had been on my mind since I decided to attend the class: What should I do about the fact we weren’t doing PI Planning?

My memory of Dean’s response is that he was rather dismissive. Being the sensitive little thing I am, I felt somewhat wounded by this exchange. Looking back now, almost three years later, I can now see this exchange from a different perspective—the perspective of someone with a little more experience and a few more battle scars.

With my 20/20 hindsight, I can see how I must have appeared to Dean. A youngish business person with no real experience leading large IT teams, suggesting that I knew better than a veteran of the technology industry, author of several books and creator of the Scaled Agile Framework. Looking at the situation through this lens, I find myself squirming with embarrassment at my own arrogance.

Fast forward to the present day, I am an SPCT, making a living from helping enterprises implement SAFe. As a consultant, I get to see and learn from many different approaches to implementing SAFe and launching Agile Release Trains. I encounter people every day who think they know better, and I find myself bristling, perhaps in the same way that Dean bristled when I questioned the value of PI Planning.

While this could be the same arrogance I displayed back at that SPC class in Boulder, I hope the root cause is actually something different. I now believe. (Ok. I’m now channelling Agent Fox Mulder!) Seriously though, my experiences and those of others in the community who have chosen to share their experiences have convinced me that perhaps we should listen before passing judgment.  I think Henrik Kniberg put it best in his recent talk about SAFe at Lego:  “SAFe = Shu-level scaling”.

Launching an Agile Release Train with that very first all-hands PI Planning event is a terrifying thought for many new to SAFe. Without an experienced SAFe Practice Consultant on hand to lead the way through the courage of their convictions that it will work, new trains start to devise a plot for a “soft launch”, not unlike my first attempt at PI Planning with the EDW Release Train. The end result often being equally as soft.

No matter how soft the launch, almost without fail, the team is inspired by big room planning. They decide to do it again in 12 weeks' time, but this time better. Still not ready to go all in. They make some changes to make the next event a little more like textbook PI Planning. The second event is a raging success. Everyone is self-congratulatory. They have improved so much. They are making great progress. Clearly, the more structured, full-scale PI Planning approach is for fools.  In the end, it’s all a matter of perspective. How can you be great if you don’t know what great looks like? And there it is, just as Jim Collins observed - Good is the enemy of great.

The more poor PI Planning I see, the more I believe that the formula is almost fool proof. No matter how underprepared you are or how many corners you cut, there is always a good outcome and a little taste of the magic. Perhaps it is just like sex and pizza, even when it is bad it is good. These days, Dean likes to rib me about all the “workarounds” we did with EDW. It’s all good-natured fun. We did what we did because we had no choice. Dean understands that, but he also knew something we didn’t. If there is magic in SAFe, it is in PI Planning, and you just have to experience it to believe it.

Update 23 January 2024: A couple of years after writing this, I discovered that PI Planning is not actually foolproof! The one place I have seen it come severely unstuck is when there are no features or underbaked features. For more on this, check out my session at Agile Hartford: Stayin’ Alive! Feature Disco Your Way to PI Planning.

When an organisation introduces agile, it is not uncommon for there to be a mass rollout of Agile Fundamentals training, where the role of the Product Owner is positioned as being an empowered business person who is colocated with and 100% dedicated to work with the agile team. This sounds wonderful in theory, but when we start to scale, this begins to get tricky.

I once worked for an organisation that had a policy whereby you were only allowed to run your project agile if the business made a product owner 80% available to the project. Of course, the business wasn’t silly; they knew how to get around this constraint - either find someone in their department who isn’t adding a whole lot of value and allocate them to support the agile team or hire a contractor off the street and have them fill the role of Agile Product Owner. Problem solved!

As we begin to scale agile, the pressure on the business to provide more and more product owners exacerbates the situation. As much as we might want it to be the case, most businesses don’t have a small army of people just waiting for an agile team to come and adopt them. The Scaled Agile Framework (SAFe) has historically attempted to address this capacity constraint by allocating members of the development organisation to the product owner role and adding the role of the Product Manager, who reports to the business and is effectively the product owner of the Agile Release Train (ART), the team of agile teams. In SAFe, Product Management is also empowered to ensure the dedicated ART budget is invested in the right features.

As someone who has been the business sponsor of a large agile program, I am very familiar with how challenging it can be to source enough business product owners to support multiple agile teams. Initially, I opted for the “contractor off the street” solution. Well, that is a slight exaggeration - most of the contractors were not exactly off the street and were at least somewhat familiar with the solution context, but they were still not true business people. Regardless, the fact that these product owners reported to me as the business sponsor gave me comfort.

As ingenious as I felt my approach was, it was not the right solution. These proxy product owners caused all sorts of challenges for the delivery teams. They didn’t have the in-depth business knowledge required to support the agile teams on a day-to-day basis.  However, when I first came across SAFe’s product owner model in Dean Leffingwell's Agile Software Requirements, Product Owners reporting into development felt like an even bigger compromise than the approach I already had in place.

I knew what we needed was real business people. I also knew the business units would never be willing to dedicate the right people to work with the agile teams. So why not ask the business for something they can give…a Feature Owner? Yes, yes, I know there is no such thing as a Feature Owner, so bear with me a moment while I explain...

You see, SAFe has a requirements hierarchy where the largest requirements are epics. Epcis are broken down into features, which are broken down into stories by the agile teams during PI Planning. Agile Release Trains deliver features, and features have business benefits. So rather than attaching the content authority to the ART in the form of a Product Manager or the team in the form of the Product Owner, why not have a content authority for each feature in the form of a Feature Owner?

Unlike a product owner, we didn’t expect Feature Owners to be 80-100% dedicated to a single agile team. Instead, we expected them to be available to the team(s) 4-5 hours a week, every week, that their feature is being worked on. The idea was to ask the business for something that they can give. Almost anyone can find 4-5 hours a week for a month or two to contribute to a good quality outcome on a project they care about. As a rule, I have found that once the Feature Owner and the Agile Team have established a relationship, a human connection, then the arrangement changes from a number of hours a week to all parties collaborating to contribute whatever time is necessary for the successful delivery of the feature. From the team’s perspective, the Feature Owner is the ultimate authority and single voice of the customer on the scope and acceptance of the feature.

Over the years since I first used this model, I have found many other ARTs have faced similar challenges with respect to the availability of business product owners and the allocation of dedicated ART budgets. The feature owner model has often come in handy in these situations. Sometimes, the Feature Owner is more like a Product Owner for a specific feature, collocated with the team and able to provide a large proportion of their time to the team while their feature is being developed. In other scenarios, the Feature Owner is supported by a product owner who is a member of the agile team. When working with ARTs in the digital domain, the role of Feature Owner has often been played by someone from the business unit funding the feature, while someone from the digital channel team plays the product owner. This enables the commercial decisions regarding scope to be retained by the funding business unit while enabling those responsible for the channel’s customer experience to ensure consistency. In some cases, I have used this model to augment the technical product owner as advocated in SAFe.

One of the most common concerns people raise about this model is the impact of multiple feature owners on the agile team. When applying the Feature Owner model within SAFe, we need to ensure that we have also provided the teams on the train with a force-ranked, WSJF-prioritised backlog, so there is never any doubt about the priorities of the features being delivered by each team. Limiting feature WIP can also help minimise confusion or competing priorities caused by multiple feature owners working with a single agile team.

You may have noticed that the introduction of the Feature Owner role does not address the role of the Product Manager. In a world where the ART has its own budget, the function of Product Management probably wouldn't change much.  However, if your ART is project-funded, this gets a little more complicated. One of two models tends to apply in this situation. Either the Product Manager is the business owner of the ART (common in the digital domain where the business may have a nominated channel owner), or perhaps there is no Product Manager at all. (In these instances, we often use a Pipeline Manager.)

So, while technically, there is no such thing as a Feature Owner, perhaps there is a place for such a role in some circumstances. In my experience, appointing a Feature Owner provides a pragmatic solution to some of the challenges we face when Scaling Agile. In most cases, it does not replace the need for each team to have a product owner; instead, the addition of the Feature Owner augments the Product Owner and strengthens the connection between the business and the agile teams. I like to think of the Feature Owner model as prioritising access to the right people over more access to the wrong people.

Updated 5 February 2024 - In SAFe 4.6, the SAFe Product Owner guidance was updated, removing the reference to the Product Owner reporting to the delivery organisation.

As part of my participation in CukeUp Australia last month, the team at Cucumber invited me to join them in recording a podcast about Scaling Agile and how large organisations can make it work.

You can tune to the discussion with +Terry Yin, +Matt Wynne, +Hamish Tedeschi,  +Steve Tooke and of course me, using the +SoundCloud player below.

While I was at Agile 2015, I had the opportunity to catch up with fellow Aussie +Craig Smith from +InfoQ. We talk about how I came to lead Australia's first Scaled Agile Framework (SAFe) implementation and both my Agile 2015 sessions - The Magic Carpet Ride: A Business Perspective on DevOps and Thawing the Frozen Middle.

You can watch, listen to or read the entire conversation at:
https://www.infoq.com/interviews/agile2015-campbell-pretty

One of the topics I have been talking about at various conferences over the last 18 months, is scaling culture with agile tribes. This is a topic that resonates with people in both the Agile and DevOps communities. As part of my participation in the DevOps Enterprise Summit last month I was invited to share my thoughts on this topic on the TechBeacon blog:
From teams to tribes: Creating a one-team culture in DevOps

As part of an Agile Release Train’s commitment to relentless improvement, it is necessary for all the teams on the train to reflect and assess the effectiveness of their Scrum and XP practices on a regular cadence. For most once a PI seems to be a logical frequency. The Scaled Agile Framework provides a self-assessment tool to support this process and makes it freely available for download at: https://www.scaledagileframework.com/metrics/

I have found clients often want to do self-assessments by sending them out as an online survey for team members to complete individually.  Personally, I am not keen on this approach for a number of reasons. Firstly, most new agile teams don’t have a clear and consistent understanding of what good looks like, therefore, they tend to overstate their level of maturity. (The first time we conducted a self-assessment with the EDW Release Train, the most mature team gave themselves the lowest score and the least mature teams gave themselves the highest score!)

Secondly, by completing online surveys the team doesn’t have an opportunity to discuss their different perspectives and reach a shared understanding.  In my experience self-assessments provide an excellent coaching opportunity, especially if you are the only coach supporting an ART and doing so part-time. Often this can be as simple as reminding them of what a 5 looks like and resetting their anchors. Even though an RTE can take a DIY approach to this, an external facilitator can be very valuable and as a coach, this is your opportunity to ensure the assessment is only used for good and not evil.

Last year I was getting ready to facilitate the first round of self-assessments for a new train and I got thinking about my approach to facilitating these sessions. My priority was to ensure that every team member got an opportunity to express their individual point of view. Which led me to contemplate how Planning Poker uses the simultaneous reveal to prevent anchoring. One idea I had was to create cards numbered with a 0 to 5 rating scale, but that felt a little boring. Then it came to me - the perfect combination of silent writing on post-it notes and a big visible information radiator…

During my lunch break, I raced out to Officeworks and purchased a box of Sharpies, an 8-pack of Super Sticky Post-its and a pad of butcher's paper. I made it back to the office and found the meeting room with moments to spare. I quickly drew a large star, like the axes of a radar chart, on 5 sheets of butcher's paper I gave each poster a heading as per the areas in the SAFe Self Assessment: Product Ownership Health, PI/Release Health, Sprint Health, Team Health And Technical Health. I then labelled each axis A through E and marked the numbers 1 through 5 along each axis. I then took the 6th piece of poster paper and wrote up the rating scale.  I attached the posters to the wall, put a post-it pad and sharpie out for each team member and waited for the team to arrive.

Once the team had settled in, I provided a brief introduction, reminding everyone that the purpose of self-assessment is to reflect on where the team is at and identify opportunities for improvement. The self-assessments would not be used to compare teams, nor would they be used by management to “beat up” the teams. Then came the instructions:   “We are going to work through each of the five sections using the following approach. Each section has five statements, which I have labelled A through E. As I read out each statement you will need to write the letter corresponding to the statement and your score using the rating scale provided. This will be a silent writing exercise. Once everyone has provided an assessment for all 5 statements for a given area, you will each place your responses on the chart. Then we will go through and discuss the responses and reach a consensus on the overall score for the team.”  

Section by section the teams created visualisations reflecting their assessment of the current state.  On some aspects, the team was close to 100% aligned and on others, their opinions could not have been more varied. As each section was completed I facilitated a discussion with the group about the results. Where there were clear outliers I would start by asking for someone to comment on them. For the most part, the discussions tended to result in convergence on a shared assessment, that I could record in the template. When the team struggled to reach a consensus, I ask them to “re-vote” by holding up the number of fingers that reflect their current view and I recorded the mode.  Once I had completed all five assessment rounds, I also had the data to complete the summary radar chart. 

The first few times I used this approach I struggled with the time box and did not leave enough time for the most important step: identifying the actions the team would take to improve. These days I use a two-hour time box and always make sure the team leaves the session having committed to actioning their key learnings. I like to try and get one improvement focus or action from each of the 5 areas.   

I think one of the strengths of this approach is its alignment to the Brain Science about how adults learn. In her book Using Brain Science To Make Training Stick, Sharon Bowman, creator of ‘Training From the Back of the Room’ talks about six learning principles that trump traditional teaching:

• Movement trumps Sitting: In order to learn the brain needs oxygen. The best way to get oxygen to the brain is to move.
• Talking trumps Listening: The person doing the most talking is doing the most learning.
• Images Trump Words: The more visual the input is the more likely it is to be remembered.
• Writing trumps Reading: The team will remember anything they write longer than anything you write. 
• Shorter trumps Longer: People will generally check out within 20 minutes.
• Different trumps Same: The brain quickly ignores anything that is repetitive, routine or boring. 

This approach to facilitating self-assessments includes Movement in the form of standing up and placing answers on the chart; Talking in the form of a discussion that the team have amongst themselves on the results; Images in the form of posters; Writing in the form of the written response; Shorter in the form of the 20-minute time box for each area, and; Different to filling out an online survey!  

As the SAFe Self-Assessment is very practice-centric, teams will probably outgrow it as they move through Shu-Ha-Ri. You will probably also find that after the first assessment, results will often go down rather than up as teams being to understand what good looks like and they hold themselves to a higher standard. As a rule, I am not a fan of “agile maturity” surveys, as they have a tendency to end up on performance dashboards and scorecards resulting in teams being pressured to improve their scores and the system most likely being gamed. The real value is in the conversations. Reaching a shared understanding of each team member’s experience and consensus on the next actions the team should take as part of their commitment to relentless improvement.   

If you would like to try this approach yourself, you can access the facilitation guide here.

Tweet

The Agile Australia conference in June 2015 played host to both Dean Leffingwell, the creator of the Scaled Agile Framework and Anders Ivarsson, Spotify Agile Coach and co-author of the Scaling Agile @ Spotify paper. Those who could drag themselves (and their hangovers) out of bed early enough on day 2 of the conference were treated to an “Ask the Experts” panel featuring Dean and Anders, along with Linda Rising and James Shore.  I’m sure you won't be surprised to learn that it was not long before an audience member asked what might seem like the obvious question - SAFe vs. “the Spotify model”.

Great start to day two - Ask an Expert! #agileaus #agileaustralia pic.twitter.com/kOPLtwOHTd

— Tom Malone (@TomAMalone) June 17, 2015

After the mandatory cringe from Anders (the Spotify folk really wish the rest of us would stop calling what they do the "Spotify Model”), both Anders and Dean were quick to agree that it was not an either-or question. To quote Dean Leffingwell, "We had Henrik Kniberg in class last week, and I think it would be fair to say we learned a ton from him, and I think they will learn a ton from us." As someone who has been using ideas from Henrik Kniberg’s books and the Spotify folk since very early in my SAFe journey, I agree with the sentiment.

And off we go to Colorado! Looking forward to meeting @Deanleffingwell and learning more about the Scaled Agile Framework. #collectingtools

— Henrik Kniberg (@henrikkniberg) June 7, 2015

The first time I came across the Scaling Agile @ Spotify paper was when the EDW Release Train Engineer decided that the EDW Agile Release Train would benefit from creating a series of “Guilds”. Despite his enthusiasm, I don’t think he got past telling us his great idea was “Guilds” before the rest of my leadership team laughed him out of the room, having quickly reached the consensus that “Guilds” sounded like something from Lord of the Rings and had no place on our Release Train!

I remember the RTE  invoking the power of Wikipedia in his eagerness to help us understand his vision. “According to Wikipedia, a Guild is a collection of artisans who are responsible for the practice of their craft.“ he argued. Resulting in only more laughter from the team. Not one to be easily deterred, he took it on the chin and set about convincing me he was onto something...

First, let me give you some context. The EDW Release Train was born in a world where the delivery team had a strong track record of failure to deliver on business outcomes. An endless parade of consultants had passed through the domain, declaring the delivery problems to be the product of poor technical practices that had resulted in a lack of technical integrity in the platform.

Prior to the restructuring that had enabled the launch of the EDW Release Train, the existing management had created a new group called “Technical Governance” to define standards and oversee the technical integrity of the delivery. This restructure, which landed me at the helm of the EDW Delivery organisation, also saw the Technical Governance function move away from delivery so as to provide an external “control” over solution design and build.

When the EDW Release Train was launched, there was a significant shift in how we delivered, as we exited the outsourced, offshore, outcome-based contract approach to development in favour of a co-located, co-sourced, onshore agile release train. In my view, this change in the delivery model meant that the Technical Governance function established to provide quality assurance over the outsourced delivery had no place in the new world. However, this was not the view other parties in the organisation held.

After about nine months of watching me argue with the powers that be that “You cannot inspect quality in”, the RTE pitched the idea of “Guilds” to me and my leadership team. His self-appointed mission was for the train to take ownership of the quality of what it delivered and, more specifically, to “put the control and responsibility for core specialisations into the hands of the people who are doing the work, in order to restore a sense of pride and satisfaction within their work.”

This mission was premised on the deeply held belief that “to achieve true continuous improvement, the value stream needs to be owned, understood and improved upon by the people closest to it.” It was his hope that people with expertise in specific skill sets would meet regularly, as a Guild, in order to:

• share knowledge
• create tools
• create training material and conduct training
• set standards and practices
• review changes in approach or technology
• take an outside-in view of the system

It has always puzzled me why he chose to start a discussion about Guilds rather than Chapters. For those who have not read the Scaling Agile @ Spotify paper, the definitions are as follows:

A Chapter “is your small family of people having similar skills and working within the same general competency area, within the same Tribe.”
“A Guild is a more organic and wide-reaching “community of interest”, a group of people that want to share knowledge, tools, code, and practices.” 
Where a Tribe is “a collection of squads that work in related areas” and a Squad is “similar to a Scrum team”.
Noting that: “Chapters are always local to a Tribe, while a guild usually cuts across the whole organization.”

To me, a Tribe is not unlike an Agile Release Train - a long-lived team of agile teams. Given we only had one train, I thought we needed Chapters rather than Guilds. I’m not sure whether the RTE agreed with this logic or was just happy that I was bought in enough to argue the point, but in the end, we decided to form “Chapters”.

For each specialisation, a pair of Chapter Leads were nominated, and a cadence of regular Chapter meetings commenced. Every team on the train was represented in each chapter. The Chapters quickly evolved to become a core part of how we operated at EDW, fully integrated into our end-of-sprint Bubble-ups, taking ownership of train-wide challenges, and setting the standards for the way we worked.

In my recent travels as a consultant, I have also found the concept of Chapters useful when launching a new release train. In the case of StAART, there was a large program team already in place when we started talking about launching a train.

The existing structure essentially consisted of functionally aligned teams. There was a Business Analyst team, a Functional Analyst team, a Development team, a Test team and an Infrastructure team. The leaders of each of these teams made up the membership of the Program Manager's leadership team. So, the first order of business in shaping this release train was going to be helping the Program Manager shift her organisation from being made up of functional teams to cross-functional teams.

Given that the Program Manager was also going to be the Release Train Engineer, her world was about to change dramatically. In the new world, her lieutenants would likely be the Scrum Masters, which didn't exist at that point in time. Given their leadership and knowledge of the existing workforce, these functional team leads were going to be key to helping us get to well-balanced, cross-functional teams. I think it was the memory of Anders Ivarsson and Joakim Sundén's talk at Agile 2013 that made me think of Chapters and, in particular, Chapter Leads as a mechanism to help with this shift. You see, at Spotify, unlike with EDW, the Chapter Leads were the line managers of the chapters.

We went on to work with the newly appointed chapter leads to shape the agile teams, which we called Squads. Scrum Masters were appointed and joined the Chapter Leads on the train’s leadership team. The Chapter Leads facilitated regular chapter meetings, and the Scrum Masters facilitated the sprints. StAART celebrated its first birthday last month, and the model is still evolving. As we found at EDW, it is not as simple as slapping a “chapter” badge on a group of people; these things take time. Next PI, StAART is introducing Hackdays (inspired by Anders talk at Agile Australia) as a way to “step up” the role of the chapters in the “relentless improvement” of the train.

At Pretty Agile, we have gone on to reuse the chapter concept in other Agile Release Trains, some more so than others. My favourite chapter, which we have implemented with almost every new Release Train, is the Scrum Master chapter. One colleague is a huge fan of getting a newly minted group of Scrum Masters to bond in their chapter meetings by arming them with copies of Lyssa Adkins' Coaching Agile Teams and suggesting they run a book club.

As for SAFe and Spotify, SAFe has communities of practice, but the concept does not seem to have been fleshed out, as well as the Chapters and Guilds approach used by Spotify. I don’t know if we'll ever see Chapters in SAFe, but I did notice that the SAFe 4.0 preview includes a Communities of Practice icon on the big picture, and for me, that is a step in the right direction.

Update 5th February 2024 - SAFe did add Communities of Practice to the big picture in November 2016. The initial guidance referenced Guilds as per the Scaling Agile @ Spotify paper. The guidance article was later updated to remove this reference.