Good PI Planning is the Enemy of Great PI Planning


When I first met +Dean Leffingwell, 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 3 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 that I am, I felt somewhat wounded by this exchange. Looking back now, almost 3 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 channeling 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 judgement.  I think +Henrik Kniberg put it best in his recent talk about SAFe at Lego:  “SAFe = Shu-level scaling”.

Slide from "Is SAFe evil?" presented by
 Lars Roost & +Henrik Kniberg at +GOTO Conferences 

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 practitioner on had 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 lke? 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.


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 a scrum 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 into the business and is effectively the product owner for the Agile Release Train (ART), the team of agile teams. In SAFe the Product Management is also empowered to ensure the dedicated ART budget is being 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. In the beginning, 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 still not true business people. Regardless, the fact that these product owners reported to me as the business sponsor did give me a sense of 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 just didn’t have the in-depth business knowledge required to support the agile teams on a day to day basis.  So 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 were never going to be willing to dedicate the right people to working 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 whereby our largest requirements are epics, which are broken down into features, which are broken down again into stories for delivery by the agile teams. The ARTs 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 have the ability to give. Almost anyone can find 4-5 hours a week for a month or two to contribute to getting a good quality outcome on a project that 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 successful delivery of the feature. From the teams’ 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 facing 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 channel team plays product owner. This enables the commercial decisions regarding scope to be retained by the funding business unit while still 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.

Feature Owner vs. Product Owner
An example of the Feature Owner - Product Owner model used by one client

One of the most common concerns people raise about this model is the impact of multiple features 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 any 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 in which the ART has it's 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 tend 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. How to run an ART without a Product Manger - is beyond the scope of this blog post, but something I promise to provide guidance on in a future blog post.

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.

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:

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:

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 a 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 to me contemplating how Planning Poker uses the simultaneous reveal to prevent anchoring. One idea I had was to create cards numbered with the 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 butchers 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 a 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 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 the discussion that the team have amongst themselves on the results; Images in the form of the 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.

Last month’s Agile Australia conference 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 were able to 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 both 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”.

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 must say I agree with the sentiment.

The first time I came across the Scaling Agile @ Spotify paper was when EDW Release Train Engineer Wayne Palmer decided that the EDW Agile Release Train would benefit from creating a series of “Guilds”. Despite Wayne's 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 Wayne 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 Wayne 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 had been 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 restructure 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. The restructure that 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.

It was following this restructure that the EDW Release Train was launched. This marked significant change 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 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 held by other parties in the organisation.

After about 9 months of watching me argue with the powers that be that “You cannot inspect quality in”, Wayne pitched the idea “Guilds” to me and my leadership team. His self-appointed mission was for the train to take ownership for 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 Wayne 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.”

Source:"Agile at Spotify" talk at Agile2013 by Anders Ivarsson & Joakim Sundén

To me a Tribe is not unlike an Agile Release Train - a long lived team of agile teams. So for me, given we only had one train, it made sense that what we needed was Chapters. I’m not sure whether Wayne agreed with this logic, or was just happy that I was bought in enough to argue the point, but in the end we decide to form “Chapters”.

For each specialisation a pair of Chapter Leads were nominated and the cadence of regular Chapter meeting commenced. Every team on the train was represented by at least one person 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 more recent travels as a consultant, I have also found the concept of Chapters to be 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 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 be likely be the ScrumMasters, which at that point of time didn't even exist. Given their leadership and knowledge of the existing workforce, these functional team leads were going to be key to helping us getting 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. ScrumMasters were appointed and joined the Chapter Leads on the train’s leadership team. The Chapter leads facilitated regular chapter meetings and the ScrumMasters 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 tend to use with almost every new Release Train is the ScrumMaster chapter. One colleague is a huge fan of getting a newly minted group of ScrumMasters 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.

Last year I wrote about the communication cadence and in particular the daily feature wall stand up that was the heartbeat of the EDW Agile Release Train.  Recently I received an email from someone who had read this post and wanted to know more. As he quite rightly pointed out the "post lacked the details to effectively implement a similar event but it sounded really worthwhile."

When I sat down to reply to this e-mail, I found myself thinking about the power of the visualisations more than the event.  The inwards facing Release Train Engineer, Wayne Palmer, had been determined since the birth of the EDW Release Train to create a physical dashboard that represented the performance of the system.

The first incarnation of the "feature wall" provided a 10 iteration view of what each feature team planned to work on. At first it was +Wayne's hope that the ScrumMasters would self organise a consistent approach to visualising the work, but it was not long before his OCD kicked and he prescribed a legend. Large white cards for features in play, large green cards for features in discovery, small pink cards for defects and small blue cards for innovation work. Teams would visualise their plan for each feature by placing cards and an effort estimate in the relevant iterations. Each team showed the capacity they had available (based on historical velocity and planned leave) and the amount of work they planned to complete each sprint. This 10 iteration view also helped us plan our involvement in the enterprise release integration testing for those occasions when we could not decouple our deployments from an enterprise release.

An early version of the Feature Wall with a 10 iteration view of capacity

You can always says you can tell a good wall by the conversations that are had at it and there was always plenty of conversation at this wall, mainly about capacity and forward planning.  After a while Wayne reached the conclusion that while these discussions might be interesting to the Project Management / Pipeline folk, they were not the right conversations. The conversations taking place were predominantly how to get more work onto the train. It was a view of capacity management which didn't truly take into account what people were actually doing and how full the train was.

The feature wall stand up was becoming a daily team status report and in Wayne's view we needed to be talking about the work. With this in mind he redesigned the dashboard, with a view to visualising the flow (or lack there of) of the work through the system, He was also determined to improve the capture of cycle time metrics, with the intention of one day moving away from story point based estimation and instead using the past performance of the system as a key factor in determining future performance.

Wayne convinced me that the new wall was worth trying but I didn't want to lose the capacity view. In the end he waited until I was away from the office for a couple of weeks then replaced the capacity wall with the feature flow view and chaos ensued. We no longer had a capacity view and it quickly became apparent that our ability to visualise capacity was key to enabling the Pipeline to manage expectations and smooth the flow of demand to the feature teams. While  the feature flow help development services expose what was happening to them, it caused a problem for pipeline who still had to maintain a relationship with the business and ensure the survival of the teams. Creating harmonious change is not easy. (Many months later this would get resolved through our improved rolling wave planning and reunification sessions which emerged from our experiment with PI Planning.)

Rolling wave plans

Our first attempt at visualising feature flow was actually at the epic level as we for the most part only deployed to production once all the features in an epic were complete. This was a wake up call for me. Despite preaching that features should adhere to INVEST in the same way as user stories - independent was clearly an issue for us! In this early version, the visualisation was still very team centric. The card colours represented teams and the charts along the top were team cumulative flow and sprint goals.

Macintosh HD:Users:emcampbellpretty:Dropbox:Photos:SAFe Photos:FeatureKanban1.jpg
An early attempt at visualising feature flow

By the time I left the EDW Release Train we had evolved to the view I call “feature flow”, which was far more aligned with the original intent than our first attempt. We retained the three separate kanbans (on the one wall) but shifted the focus to the flow of features through the train.

The "feature flow" view

The first Kanban board showed the flow of epics through "discovery", the inception work the feature teams did with their business stakeholders to break down epics into features and provide an estimate of effort that could be used to inform funding and prioritisation decisions. (Remembering of course that the EDW Release Train never implemented PSIs in the way prescribed by SAFe).

The second Kanban was the main focus area. It visualised the flow of features through the train / feature teams.  As you can see in both the photos, visualising flow highlighted  a couple of problems. We were struggling to move work through business verification (the second last state) and with each deployment we added to the problem. This information had a huge impact on the system of work. We discovered that many of the business verification problems could have been resolved in the inception phase if we had just asked the right questions. We also discovered we had a WIP problem! This kinda jumped out at us when we ran out of wall space! To quote Wayne: “I am a firm believer in 3D walls - if people are having to physically step over the work, it does make it more real - think of the switch catalyst!”

The third kanban visualised the production defects the team was responsible for fixing. We had a simple rule: "He who breaks it fixes it!". If a team pushed "crappy code" to production than that team would need to clean up their own mess. The other data collected and displayed on the later version of the feature wall were train level metrics such as average cycle time and the number of features in WIP.

Of course none of this really talks to the question of "how the feature wall stand-up worked", other than highlighting the need to create the right visualisations to support the conversation!

The feature wall stand up was facilitated by the inward facing Release Train Engineer and was held daily straight after the feature team stand ups. The Iteration Managers and Technical Leads from each team were the mandatory attendees. As the process matured, some of the other team members that were working on specific features would also join the stand up.

With the early versions of the feature wall the stand up consisted of  a team by team update on the state of play from the Iteration Managers. When we moved to the feature flow model, we also changed our approach to the stand up. We started with the defects kanban and walked through each state until we hit “ready” for discovery. Not every card was talked about every day - instead team representatives would call out blockers, issues, risks and requests for help as the discussion moved to the state the feature was in. Our focused moved from what features teams were working on and how their capacity was impacted to talking about the work and how we could help it progress.   Most mornings held a combination of wins (features moving along) and blockers that needed attention from the Project Portfolio Managers or the leadership team. Once we had gone through the Kanban we would ask the folks from the Pipeline and Deployment teams if they had anything to add and generally we would be done and dusted within 15 minutes.

I continue to be an advocate of the “feature flow” Kanban and have implemented it at other sites since joining the world of agile consulting. Of course the trains I work with these days do have PIs and Release Planning, so the visualisation includes the process of getting features ready for the next PI. In one instance it received a lot of criticism because nothing ever moved, which in due course led to a discussion about feature size and how smaller batches enable flow.  Good visualisation leads to good  conversation.  If you can’t have or aren’t having the conversations you want in front of the wall, evolve your visualisation.

And finally, bear in mind that the wall may not tell you want you want to hear but it never lies.

A more recent Feature Flow Kanban from another site

Pretty Agile® and Tribal Unity® are registered trademarks of Pretty Agile Pty Ltd.

© 2021 Pretty Agile