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.