There’s a discussion over at kanbandev about the feasibility of how SAFe’s WIP limiting approaches work at the portfolio level, and I wrote up a few thoughts… cross-posted here for longer term availability.
There are few nuances that are important to understand when discussing how the portfolio level in SAFe is limited, and I apologize in advance if the following comes off as a lecture. The details are hard to assemble from the web site, but are somewhat more clear in the portfolio module of the course materials.
Epic Analysis flow: The only explicit, count-based limit in the portfolio kanban in SAFe is limiting the number of epics permitted to be in analysis and pre-approval at any given time. SAFe recommends the WIP constraint here is determined based on the desired epic throughput (pull rate from portfolio backlog into implementing) and the availability of the architectural and development capacity to perform analysis. In the past this was framed as “limited by the number of epic owners”, but this didn’t properly represent the bottleneck. Reference
Portfolio backlog: While there is no explicit limit set to the portfolio backlog size, in practice it has an implicit limit based on desired aging and investment flow characteristics. If items in the portfolio are consistently being passed in the final cost of delay sequencing, they are candidates to be pulled out and eliminated or passed back through the analysis flow for reconsideration and rescoping.
Implementation: There is an explicit, flow-based capacity limit between the portfolio backlog active implementation by the various trains. The limit is managed as an explicit pull system where the trains may pull in the work at the cadenced PI boundaries if they have capacity to support it. Forecasting and capacity recognition is done in “big round number” story points, generally derived from reference class forecasting or relative estimation approaches performed against a preliminary feature decomposition. Reference. Capacity may be reserved by allocating budget against the epics, representing an explicit, cross-cutting investment decision by the executives forming the program portfolio management team. Reference
Portfolio Distribution: SAFe significantly simplifies the decisionmaking around the above concerns through the recommended budgeting approach, which explicit allocates both budget, delegated financial authority, and scope determination to the release trains as the default approach. This leads to a significantly reduced portion of the overall spend being managed as explicit items in the portfolio flow, Instead, the majority of the work can flow “horizontally” at the train level without incurring the administrative and governance overhead associated with the larger items flowing through the portfolio backlog. The portfolio flow is intended to be used only for those items that cut across trains and are of sufficient size that they need explicit financial governance. Reference. SAFe additionally provides an optional value-stream level coordination layer to manage coordination of those cross-cutting items that demand additional coordination due to the various dependencies that remain after making the organizational structure trade-off decisions without adding the additional financial governance overhead. Reference.
In my experience working with organizations consulting and training SAFe, this final aspect is the hardest part to adopt organizationally, as it incurs the same set of challenges that evolving towards a incremental funding / Beyond Budgeting approach does. As a result, these organizations tend to flow a much higher percentage of their work through the portfolio than should be necessary and incur the significantly longer lead times associated with doing so. They also tend to enter a negatively reinforcing loop of excessive cross-train dependencies and failure to achieve multi-train continuous improvement. I know a few companies that have navigated their way through this trap, but it is one of the bigger SAFe anti-patterns I’ve observed, at least early in adoption efforts.
I’ve been hearing a lot of people say things like “We want to switch from Scrum to Kanban” or “When we stopped doing Scrum and started doing kanban…” or similar statements. My first two questions are almost always “Why?” and “What changed?” and my posture was always one of “you obviously don’t understand Kanban.” This, unfortunately, isn’t useful or helpful to the people I”m talking to. So, in the interest of actually helping people, I thought I’d help them through the first step of applying Kanban to a Scrum environment, respecting the ideas of “start where you are”, “make work visible”, and “Make process policies explicit”. Here’s the result, with the red policies ones that I know a lot of teams do even if they’re not generally believed to improve results long term (remember, start where you are).
At this point, a team can begin to talk about limits for each column:
- Building limited by number of people/pairs
- Sprint backlog limited on average story size * historical velocity
- Ready for planning at ~1.5 times the sprint backlog limit
We’ve already got a few roles in play, so we’ll just keep those for now: Product Owner, ScrumMaster, Team Member.
We’ll start by respecting the current cadences, mapped on to the new visualization:
- Anybody can add to product backlog at any time
- Replenishment cadence: Fill “Ready for Planning” is ongoing, with expectation it’s full at~3 weeks of work before the planning session. Team supports through an every-other-week grooming session in the off weeks from the planning sessions.
- Planning cadence: Batch transfer during every-other-week planning session from Ready for Planning to Sprint Backlog
- Daily Cadence: Team continues to meet and discuss their path to success on the current work each day
- Acceptance cadence: Product Owner accepts work as it’s done, moves to Accepted
- Demo cadence: Team demonstrates every two weeks, generally just before the planning meeting
- Retrospective cadence: Every other week, generally immediately after the demo
That’s it – that’s what Kanban probably looks like the day after a team “stops doing Scrum” and “Starts doing Kanban”. The future, however, is wide open, and the teams need to continue driving improvements if they want to discover that the future is something exciting rather than something unemployed. (Pretend to read a Deming survival quote here)
Remember – Improvement isn’t something that happens TO you.
I just threw my opinion in to a discussion on the lonely coaches society, and realized my answer may be valuable to share here, as well. The crux of the discussion is around accountability, especially focusing on the absence of individual accountability. Here was my contribution:
… I usually use something like the following, stopping when I’ve capped the scale of the company I’m working in at the time. I’ll use SAFe-based language here, but I customize it for my audience’s environment.
People (or pairs) are accountable to their team, talking in a language of tasks. The cost of being wrong is very small, because you’re doing this planning and committing every day, so the consequence of being wrong is also extremely low.
Teams are accountable to their release train, committing in the language of stories, usually every week or two. The cost of being completely wrong is a bit higher here, but if a team is close to its commitment, either over or under, the consequences should be equally light.
Release trains are accountable to their portfolio, committing in the language of features, usually every couple of months, perhaps a quarter. The cost of being wrong could be higher here, because associated groups in the business will be making their own plans and commitments based on the trust established between the release train and their customers. The importance of transparency, and understanding what others are doing based on your commitments becomes much more important at this level, as the consequences of being wrong may be much larger. As an example, what’s the impact of having to cancel a trade show because the announced features aren’t ready?
Yesterday on Twitter Matt Heusser asked me “@erwilleke can you email me with the story of what you did at the ms ALM summit a few years back? I may need to pull that trick at a conf”. Rather than tweet it or consign it to email, I thought I’d make a post out of it, since it was quite fun
Act 1: The curtain opens on the view from the back row of the seating in the stadium/theater room at the Microsoft Conference center at their Redmond campus. Lights are low, esteemed speakers are doing their thing on stage. It’s about halfway through the morning of day two at the ALM Summit.
The twitterverse explodes the conference #tag with variants of “Enough about Agile, we get it: Use Agile. Now stop telling us to use Agile”. Our hero (me), looking at my talk scheduled for right after lunch, realized it was essentially “Why managers should embrace agile.” Not shaping to be a crowd-pleasing experience. Oh crap, said Eric, then started chatting about it with Chad Albrecht, who was sitting beside me. At some point I asked “Should I just throw out my talk?” and Chad responded with “why not?” (or some paraphrasing of that exchange). I talked to Keith Pleas, the event organizer, and got 2 minutes of time at the end of the pre-lunch talk.
I explained to the room what Twitter had to say and asked “How many of you want to hear me explain why managers should embrace agile?” and got perhaps one hand out of 200+ people. With this, I declared that I would convene my session after lunch in the lunch room, and for people to please stay at their tables and chat until it was tie for the session.
Act 2: Eric is standing at the front of a big room set up in 10-person rounds. The catering team is clearing away the last bits of lunch. The vendor/sponsor slide behind Eric has been replaced with Eric’s freshly minted title slide in black text on white background.
Having thrown together a quick deck explaining the mechanics of the Coaching Dojo I’d recently been exposed to at that year’s Agile conference (Rachel Davies, perhaps?), I introduced the crowd to the idea of an “ALM Dojo” allowing them to bring their challenges to a group of peers facing the same problem, then explore solutions through questioning from their peers. I essentially asked “Who has something around Agile or your current tooling that you’re struggling to improve?” and invited any takers to come up front to the microphone. My goal was 14 “seekers” since there were 14 tables. I got three or four immediately, so I had them start explaining their question to the room, then invited a table that was interested in discussing that challenge to raise their hands. As people showed courage to share their problems, more and more people were willing to share, so I eventually had to cap it. After every table had a seeker, we got started. A few people moved to be at tables discussing things they wanted to pursue, and we spent an hour talking about real world problems in groups of 8-10. Not everybody was engaged all the time, but I got enough of the room that I was quite happy with the results.
Perhaps I’d even put it on a conference program under the title “Free group-based consulting” or some such
Disclaimer: This is a 2+ year old memory. Assume some facts are incorrect, and respect the spirit of it all.
Having just completed the 35th iteration of a significant project in which I’m pretty heavily invested, I thought I’d reflect back on some of the major trends visible in previous iterations.
Looking back, the first few iterations were heavily focused on getting our feet under us, discovering the important aspects of the project environment, and getting a feel for how things worked. While informal learning was very consistent through these early iterations, our primary stakeholders determined that the team needed formal training in some of the key areas associated with the product’s development and invested heavily in that training starting around the fifth iteration. These training efforts continued in parallel with development activities throughout the first 20 or so iterations.
Meanwhile, the team was able to successfully release incremental business value into the retail market starting around the 15th’s iteration, with the value of that contribution increasing steadily each iteration. The market feedback from the first few iterations in the retail market fed heavily into determining future product direction, and as a result the product team was able to achieve some significant strides in understanding the target market. This led to a strong pivot into an engineering market, including carefully arranged deep market training for the team over the next few iterations, including at least one significant gemba visit for each iteration. In return, this training allowed the value delivered soon after moving into the engineering target market to be heavily aligned with the future direction of the product.
The product made major strides over the ten iterations following the team’s deep technical training, investing nearly ten thousand hours each into creating major capabilities for both the technical engineering market and the engineering leadership market. Throughout this same period, two major stakeholders moved to an advisory role, the project merged with another project, bringing new stakeholders on board, and even spun off a new project around iteration 29 that is intended to explore new markets (although still demanding quite a bit of training and guidance from members of two merged projects).
Despite significant and profitable market penetration based on the product’s capabilities, the product team wasn’t satisfied with the product’s current positioning. As a result, the team worked to pivot again, bringing the product team into the training and development market. This has allowed the product team to achieve significant leverage towards the overall core vision, while increasing market awareness and continuing to experience significant market demand. These actions have also led to the product being featured in a number of trade shows, as well as being involved in the creation of a variety of market literature.
This leads us to our current reality, in which the team is sitting down to celebrate its achievements and consider future directions using the classic ceremony known to facilitators everywhere as “Birthday dinner.”
Happy birthday to me!
I worked with a group last week to help them get started with kanban, as I do many weeks. As we moved into the last stages of the class we were at the point where we’ve articulated the work they do, how they do it, what the constraints and policies are in their day to day, laid out the columns they’ll use to represent that work… all the good things that happen when you design a kanban system. As is pretty typical at this point, the question arose “How do we choose our limits?”
I started into my typical list of the different ways of limiting. I shared how it works in manufacturing, taking the ratios of work time to each other. I revisited the idea of focus and talked about avatar limits and not having more than one or two items in the system per person. I talked about the need to smooth flow, and how the various column limits will change once you achieve a reasonable flow through your system. I even talked about the “pull it out of your experience” approach. Then I realized… all of these missed the point.
It’s not about “choosing our limits,” it’s about “choosing our limits.” It’s about the choice being a choice, fully embraced by the team doing the work. It’s about a team inspecting its own work, accepting the need to constrain themselves, and respecting that constraint.
With this realization, my advice became “Pick something that’s actually a constraint, something that encourages you to work a little differently, but doesn’t prevent you from delivering how you deliver today. Get in the habit of respecting the limits, but recognize that whatever you pick today will be wrong in three months. There will be a time when the specific choices make an impact on your flow and help you shine light on impediments, but that’s not now. Right now, learn to focus on finishing work instead of starting new work, and use the limit to help you achieve that focus.”
The self-discipline to limit behavior while standing up for what one believes is among the attributes that I respect most in people. Why should I respect it any less in a team?
We are a community that values delivering early and often. Releasing incomplete work in order to gather feedback and improve our materials is in our DNA, right? So I fully expected to see a nice, smooth line of submissions entering the Agile 2013 submission system over the two months it was open. Yeah, right!
I get to see a few interesting behaviors in my role on the Agile 2013 program committee, but the most interesting is just how strong student syndrome is in our community. A couple of the more interesting things I noted:
- The several emails to the program committee asking what time of day a two-month-long window will close for new submissions
- The several people who potentially lose their ability to submit due to technical issues in the last hours of the submission window
- 70% of submissions were submitted in the last 7 days
- 54% of submissions were submitted in the last 2 days!
I recently started reading “Intellectuals and Society” by Thomas Sowell, and like any good book I didn’t even make it out of the preface before I found things I wanted to write about. Unlike most good books, I’m actually writing them! Sowell quotes from Mark Lilla’s “The Reckless Mind” about what it takes to “write an honest intellectual history”:
… But he will need something more. He will need to overcome his disgust long enough to ponder the roots of this strange and puzzling phenomenon.
This struck me very powerfully because it resonates with a lot of the coaching I do in large companies. I see a lot of things that go very strongly against my “agilist mindset”, against everything that strikes me as good common sense and effective. Some of the policies and approaches I see approach inhuman in the way they treat people, and the disempowering language occasionally kills off small pieces of my soul. Occasionally I go far beyond “I wouldn’t want to work here” to “I can’t understand why anybody would ever willingly come to work here.”
And then… every time, I start to see. I move beyond my reactions, and I feel glimmers of what makes those companies great. I feel a sense of promise and desire. I feel the amazing power of human passion bubbling just below the surface. I see a wonderful group of people striving mightily against a system that was originally set up to serve them, but has now become their master.
I open my mind to understanding the real environment. I respect the many highly intelligent people working in the environment. I recognize that all of the policies arose for a reason. I see that the language is meant to be efficient when it loses the people. I remember that everybody is doing the best they can at the time they do it. I appreciate vision for changing the world and improving lives.
I start to believe.
Then, and only then, I can help create a better world…
Karl Scotland and I have helped coordinate the organization of the bag stuffing each year for the last three years. It’s a great time because of the awesome group of volunteers showing up and the mindset of “I’m here to learn something while I help out” that’s so pervasive.
The flow of bags was very effective at the end of the day last year and this year we simply started where we left off last year with the same design. Thanks to some great pre-work, we knew where everything was and what needed to go in each bag, so the briefing of the volunteer staff took less than 15 minutes and we were ready to go.
The team got moving and each zone quickly solved any issues that arose, continually improving and adapting how they worked to the needs of their specific area. We got done a couple hours early, and everything pretty much “just worked” better than could be expected.
So, when I’m asked to lead a retrospective, what do I do? Everything went so well, and learning was incorporated so rapidly, that a simple plus/delta seems utterly pointless. The plusses have been amplified, and the deltas have been changed, why should we write them down? So here’s what we did…
We gathered in a standing circle, grabbed a spare piece of swag to use as a talking stick, and each answered one simple question: “What did you learn?”. After sharing, the group reflected the individual’s statement back in a simple phrase appropriate to a sticky note. . As each of us answered, we sat down to bring focus to the people still wanting to speak. Best of all, the “people in charge”  did and said very little, and learned quite a bit.
Why did it work? Well, as I mentioned above, many of the volunteers were there to learn. The bag stuffing has filled up in the first volunteer sign-up round (of four) each of the last two years. The process execution was well beyond “good enough”, so it seems like the right thing to do is help people take away more than just their own perspectives. With a majority of volunteers having English as a second (or more!) language, the reflection portion ensured that the individual’s perpective was conveyed clearly and helped to ensure that people were able to absorb the statements effectively. More interestingly to me, the “what did I learn” style questioning seems to have drawn out positive emotions in a way that other retrospective formats haven’t been able to do in my experience.
Here’s to next year!
 Karl captured them here.
 Specifically, Karl and I as facilitators were able to keep our mouths pretty well shut.
I’ve not been blogging lately. I haven’t really been pushing things to twitter, either. For a while, I thought I was just lazy, and perhaps tired from travel. I’ve lately come to see that this isn’t the case. Good or bad… I don’t write for myself.
I write for others. I write for people who care about what I have to say, who use it to improve their own lives. I write for people that have a passion for learning, for exploring ideas, for changing the world around them. What do these people want?
I really have no idea. Looking back at my blog, I realize that most of my posts are the result of an amazing conversation I’ve had with somebody, or the result of reading somebody else’s work and being inspired to extend or evolve it in some way. When I hear from others which bits they find valuable, they are uniformly the cases where I write because somebody says “you should post this.” My inspiration is a reflection of shared passions.
So what’s this mean? It’s changed my behavior a bit. I’ve not written anything “just to write it”. I’ve focused much more on the people and ideas that are around me, especially inside of Rally. I’ve paid more attention to which trends and areas I find myself passionate about. I brainstorm with my peers around ideas before starting my writing. I’m exploring crowdsourcing initial drafts internally to Rally, and may open that beyond. I’m looking at the needs of various groups to see which ones resonate as ways of selecting topics. I’ve started involving others in my writing.
Starting with this post, I’m actively inviting others in my community to pull content from me. Tell me what you feel I should write about, what ideas you’d like me to extend, what basics need better coverage. Help me to understand what’s valuable, what’s engaging, what will help you create your own reality. And I might just ask you to write with me.
Enter User Voice. On the right bar of the blog, you’ll see a tab flagged “Suggest Topics” Throw them out there, and I’ll listen. If you wish, vote up the ideas of others. Pull the content you value, the material that inspires yourselves and others. Join me in my new experiment.
…and for those who read… Thank you!