While speaking with my wife (@mhwilleke), we realized that we were going through a very similar journey of understanding in our careers despite working in very different areas: Eric striving to align thousands of people against a common purpose in the corporate world, Marian developing learning experiences to expose individuals to opportunities of personal transformation in the educational world (for now). Based on our combined interest and application in this topic concerning organizational behavior and human learning behaviors, we co-wrote and published this to each of our blogs.
Process or Values?
[MHHW] As my cello instructor pours at least 10 techniques into me in one lesson, it became increasingly clear that limiting WIP for learning a string instrument, especially one with a bow, is simply impossible. Even if one practiced a specific technique over and over, it is out of sync with everything else. Simply closing my eyes and letting my brain come into oneness with what my body knows it must do has led me to realize that limiting WIP with cello involves becoming present with the experience as a whole, not focusing on any specific individual technique.
This appeared to conflict with my intense belief and practice in limiting WIP, which has led to tremendous results for my career. The bottom line was that what my cello instructor had me do as a whole body experience worked. Also, what I’ve been doing with limiting my WIP for my career worked. How could both work?
[ERW] In the business world, we’ve seen huge impact from the simple act of limiting work in process, but have observed very mixed results in the cultural aspects of implementing this. On reflection, the places where limiting WIP has been successful are those places where the reduction of WIP has resulted in more alignment among those tasks that remain. Where the body of work doesn’t have more cohesion as a result of limiting WIP, the group may still gain the productivity benefits, but they fail to engage emotionally into the improvement, and lose much of the potential for sustainability as a result.
[MHHW] I recognized that the career applications of limiting WIP were cognitive only. What was the affective experience? In other words, where were my values in those tasks? Experimenting, I changed my card structure away from the specific tasks and focusing on the desired outcome, building out the steps towards that outcome within the (virtual) card. Almost immediately, prioritization became more obvious as I coordinated across the value stream of the organization and it became explicit when we chose to discuss implementation details within one of those prioritized goals.
[ERW] In the transformation world, these concepts really align with the tightly coupled needs to improve the cognitive and affective aspects of how we engage individuals and teams in the act of delivering value. The aspect of SAFe, which requires teams to read back the purpose of their work as an output (see post on objectives ) is one step in this direction, yet it is only one step, continuing the journey started by including “why” on every story. There remains a great deal of work to do in providing clarity of purpose as a guiding principle of how we work. My belief is that providing balanced attention to these two areas is a key to providing both the structural flexibility needed to successfully adapt in today’s world and the organizational health required to carry a company through the inevitable changes.
Working towards the Vision
[MHHW] As a result, I’ve moved from many tasks to just a few concepts/goals, which dramatically simplifies conversations about intent and prioritization. In addition, prematurely breaking down these tasks can force me into a “do this, then this” mode where I don’t feel free to change them. Lifting the level up to an intent level in many ways allows me to maintain the state of play that is so valuable to engage my values and achieve the real outcomes aligned with that work. Knowing myself, my compulsiveness pushes me even more easily into a “tick the box” mindset, where many times the tasks may no longer be relevant to the purpose.
[ERW] Lifting the conversation above the details of the work provides a massive simplification of what needs actively managed in an organization as people learn they have not only ability, but also permission, authority, and expectation of taking personal responsibility of the tactical details of converting a goal into reality. While not immediate, this collective journey provides leadership with the freedom and safety to pursue the truly strategic aspects of their roles while permitting the whole-person engagement across the company that amplifies effectiveness so dramatically. This deep collective engagement provides a massive improvement in quality of output, productivity, and fitness for purpose of what is created.
Limiting Purpose in Progress
[MHHW] Swimming around all of this is recognizing that whole-person learning and limiting WIP can go together, but it requires a transition somewhere to bring this together. I relate cognition to the process, and affect to why I care about what I’m doing, and I’m trying to represent this as a singular thing, providing continual motivation.
[ERW] Returning to the original premise of this post, we see that the critical aspect to achieving flow in knowledge work is not specifically to limit work in process, but rather is to limit the purpose in progress. Like many aspects of lean, it is an act of imposing constraints that accelerate people’s ability to deliver results. In this case, the constraint is delivered affectively, through creating a singular focus of purpose driven with intense clarity from organizational leadership, while simultaneously minimizing the detrimental impact of competing purposes.
Cross-posted with Marian Willeke at Adaptive Learning
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.