VSM is about neither value nor management

Some folks are still spreading misinformation about value stream management. For example, in a recent webinar, the so-called authority made up a definition of value stream management. Their logic went thusly: "What is value stream management? Well, let's look at the definition of each word: value, stream, management." After giving a definition of each, stated "Therefore, value management must be about managing value."

To the contrary, it's about neither managing nor value.

For the authoritative definition, I look to the early book on Value Street Management by Tapping, Luyster, and Shuker circa 2002 titled "Value Stream Management: Eight Steps to Planning, Mapping, and Sustaining Lean Improvements."

The authors clearly defined value stream management as an eight-step process of lean improvement. 

It's not about management.

It's about lean improvement. This original book on VSM says nothing at all about "managing" the flow, such as expediting work, or tracking work -- stuff commonly thought of as 'managing'. It's more about leadership than management. It's not about working in the system. It's about working on the system. 

It's not about value.

This authoritative book on VSM says nothing at all about what is sent through the system. 

It says nothing at all about how to measure the value of what you put into it. 

It's not about evaluating the value of what is flowing. 

It isn't about measuring the value you get out of it. 

Although those are good things to attend to, that's product management and strategy, not value stream management. 

In VSM, value is not computed, ensured, or measured. Value is assumed.

VSM is about improving the flow of whatever through the stream. VSM is about improving the stream. In true VSM, the theme is about reducing waste and improving the flow of whatever it is deemed by management to flow. In lean, improvement of flow is the theme. It's not about determining what should flow through the stream at all.

Okay, so, sure, value stream management is poorly named. But I still prefer that those who choose to have a voice about it do their homework first. That way they can stay true to the original definition rather than make up their own out of ignorance.

The Other Reason I Stopped Blogging

I blogged a fair amount (for me, and relative to many colleagues) before I went into consulting and continuing on into my time at Leading Agile -- right up until it became mandatory. The company had a desire to have more people write more content more often so it became expected that everyone be involved. The implementation was a well intentioned across the board writing calendar; a rotation for every consultant to write a blog post when his or her week came up.

That killed my writing motivation. 

I stopped writing. Corporate writing scheduler: "Write something!" Me: "Uh, well, no, and why don't you go pound sand." That's the lack-of-autonomy and lack-of-purpose (ref Pink's Drive) triggers for me. That was part of my writer's block.

Then I got over that (not wanting to comply) and began to think that I just couldn't write on schedule. I could write only when the inspiration hit me. Creativity can't be scheduled. There is some truth to that for me. Much of my writing was in response to either (a) a question someone asked me or (b) an answer someone gave me in response to a question I had. Even in the 1st case, the writing was a thinking tool. It helped me think though how to articulate a point or express a concept for the benefit of others.

It just now hit me that my writing also scratched the itch that Pink in Drive called mastery. As long as I was learning, I was writing. As long as I was learning how to better help others learn, I was writing. 

There came a time when my learning in some old areas slowed, and writing declined. And my learning shifted to a couple new spaces and before I figured out how to write about those things, I changed employers. 

I just discovered an important point about why I didn't start writing again in that new role. I discovered this while reading John Cutler's "TBM 9/52: Writing Culture Challenges". John wrote "A writing culture is a reading culture and a feedback-giving culture. A write-and-reading-and-feedback-giving culture requires time to think, process, and respond. Writing isn't the end goal: thinking and improving is the goal."

That's what happened when a writing schedule was put in place at Leading Agile -- writing was the goal; marketing was the goal. Well, the company's leadership might have known that writing was to develop thinking, but that's not how the expectation was expressed.

Then in the new role, the work-load set it. John says that you don't get a writing culture in "Conditions of high reactivity, cognitive load, and passivity. No one has time or energy to think, ask questions, and process. Too much energy goes into doing and reacting."

John goes on: "…you can't just 'switch' to writing culture. It has very little to do with the writing and everything to do with the preoccupation with busyness, optics, power, control, and tempo. ... Work-in-progess [sic], change-in-progress, and planning-in-progress is just too high to think." Yikes!

John gives some good suggestions, techniques in his article. Worth reading. But he doesn't tell you what to do with the high WIP, high change-in-progress problems in that article. I expect he has in some of his other articles that I haven't read. It's worth subscribing to his articles. 

"Value Stream Management is Human" Patterns

In spite of how others are redefining it to be something different, Tapping, Luyster and Shuker defined value stream management in 2002 as an 8-step lean process “for planning and linking lean initiatives though systematic data capture and analysis.” Basically, commit to lean, choose a value stream, map it, pick a future state, and create and implement kaizen plans. It’s improvement. And it’s a human endeavor. Too many people think VSM is about managing-the-work-in-the-system instead of improving-the-system.

Over my career I’ve noticed several approaches to value stream management:

“Unintentional” – Not done on purpose. In this pattern, no one is intentionally improving the value stream. Every org has a value stream whether they realize it or not, whether they think about it or not. This doesn’t mean that the organization is bad or that their value stream isn’t effective, efficient or optimized. Very talented managers could manage a value stream to great effect by pure skill and experience, not conscious of any improvement efforts. They don’t think about it. Others, however, don’t think about it and get “Value Stream Mismanagement”.

“Casual, ad hoc, decentralized and distributed” – This pattern is typified by teams doing their own retrospectives. There is little sharing of lessons learned across teams even though there may be attempts to catalog or share these. No one is driving improvement across the org.

“Intentional and distributed” – In this pattern, there is someone high up, often a CIO or VP, very much interested in process and improvement. This works well, particularly through lean, kaizen, the Toyota Kata, and the Coaching Kata. Multiple techniques/tools are often used such as A3 Problem Solving, systems thinking, and the theory of constraints. There are often measures and metrics, typically lean (flow) metrics. Kaizen moments and retrospectives are encouraged and expected throughout the organization.

“Agile Transformation / Agile Coach / Centralized” – In this pattern, there is an agile transformation initiative driving process improvement efforts. Such efforts are often time-bound, tied to the duration of the transformation initiative. Attention and efforts wane after a time.

“Biz Process Reengineering / Centralized” – This is another form of the “agile transformation” pattern but is more explicit around improving the value stream, and it’s likely much broader than just IT or software development in that it likely includes business operations as well. This might be led by a process reengineering group, expert or consultant and should involve business architects.

“Control” – I insist that value stream management absolutely, chiefly, and primarily includes the concept of improvement. However, some organizations are more concerned with control and reporting of work progress, percent completion, and due dates than with improvement. Not much improvement happens with this pattern. (I first labeled this pattern “PMO”, but decided that wasn’t fair. PMOs didn’t have the best reputation in the heyday of the agile movement. Perhaps that’s changed now, and I’ve seen many PMOs adopt agile and even drive agile transformations with some success.)

The best approach to take is “Intentional and Distributed”.

My purpose for writing this was twofold:

• I want everyone to understand the true point of value stream management, which is continuous improvement. So many people (platform vendors especially) are making it out to be something else entirely.
• I hope more people will be intentional about improvement efforts. Perhaps they’ll recognize their pattern and consider other alternatives.

Context is King: Why I stopped blogging

A lot of the articles I read about agile don't describe the context in which their advice applies. The authors don't take the time. Many authors aren't even aware of their context. They haven't seen enough different kinds of agile implementations to understand that their advice doesn't apply outside of their context.

Writing was easy for me when I worked for Leading Agile because we had a well documented and limited context. Grossly oversimplified, companies who wanted predictability in their software development efforts were attracted to our offering. We had one message, one services offering, and one target market.

Everything on our blog and everything on our website and every talk given at a conference adhered to this single context. That context was explained so much that it didn't have to be explained every time. Yet every blog post pointed back to that context in some way. It all dovetailed together.

Every aspect of agile, of teams, of org structure, of metrics, of forecasting, of planning, of funding, of portfolio management, of roadmapping, of prioritization, and on and on needed to be explained in terms of that context, so there was lots of fodder.

I stopped blogging when I left Leading Agile because of this need for the applicable context to be explained. When I left the firm I left the context. I've seen agile done many different (valid and effective) ways before my time at the firm and in many ways after. For which context should I write? How should I explain the applicability of my opinions? 

I don't run my agile programs now the way we did at Leading Agile. It's not because I didn't believe in that approach, didn't find value in it, or can't do it. In fact, I like that approach a great deal. But it doesn't apply to my context now. Predictability isn't my driver. 

This isn't anything new. People have been arguing over agile since the 90s, with much disagreement stemming from the unique and unstated context in the mind of each author and consultant.

What triggered me to write this was some things John Cutler wrote. "…the key to putting bets in motion is to tailor your working approach to the bet." How you develop the idea of the bet and how you implement the bet should vary based on the nature of the bet, the uncertainty of the opportunity, the uncertainty of the solution, urgency, size, allowance for failure, level of collaboration needed, and etc. There's no single agile prescription that's best for every kind of bet. John explains the anti-pattern of when companies "lack any sense that the things they are doing have different characteristics. They try to use a mono-process for everything." "Impact: picking less-than-optimal ways of working." And "Mono-process kills companies." 

Don't bother trying to do agile "right" and don't fret over other people's advice when it doesn't match your context.