"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.

Sketchnotes of Agile Immersion

Here are the sketchnotes from my November Agile Immersion workshop.

These sketchnotes were done by a business partner of mine, Jenny Trautman of evenview. Sketchnotes aren't the main thing evenview does -- sketchnotes are an artifact. What evenview does is help people bring innovative strategies into focus. They lead fun, high-energy meetings using interactive visuals that draw a team together. With their support, groups collaborate to develop a shared vision, create a plan for action, and implement their ideas. Use them for your next strategy meeting or kickoff.

By the way, this workshop is designed for everyone. No agile experience or programming skills required. All types of roles have found it benefical: product managers, marketers, managers, office managers, business development executives, developers, testers, CFOs, and etc. Check out this interesting blog post from a recent non-developer attendee.

Personal Kanban Retrospectives

At the end of each week I do a quick retrospective on my use of Personal Kanban, the tasks I've completed, and the week in general. I don't do anything elaborate or time consuming. Just a simple evaluation of how I'm doing.

I use two particular approaches to my personal kanban retrospectives more than any other.

+s and Δs

With Pluses and Deltas I think more about what worked well and what I want to change going forwards. Sometimes I use 'Regrets' instead of 'Deltas'. I do look at the tasks I accomplished, but with this approach my mind considers more than the tasks. For example, some of my notes from prior retros include things like: relaxed, haven't been inbox-zero for a while, did I forget to plan?, someone important linked to my blog post, got a great lead from someone, so-and-so is unreliable, such-and-such didn't pan out, well prepared for next course, successful partnership with so and so, good blogging this week, etc. I use index cards for this style retrospective.

Most Successful / Least Successful

The other approach I use lots is to simply arrange my completed tasks by how I feel about them. Some I feel really good about. Some weren't so successful. Maybe some are neutral.

I'll take notes, again on an index card, on these high points and low points.

Not a Commitment

What I don't do is compare my actual achievement against a plan. I do "plan" my week, but it's not a commitment to specific tasks. It's more of a re-prioritizing of the backlog and preparation for the days ahead. I use that time to make sure I don't miss any commitments or fail to prepare appropriately.

I hope you found this useful. What kind of Personal Kanban Retrospectives do you do?

---

Register now for my 11/5/12 Agile Immersion Workshop. This low cost day-long hands-on workshop will guide you through an agile project, from inception through the first couple iterations. Through this immersion, you'll understand agile 1st hand. Lunch is included.

For the Sake of a Productive Retrospective

Even good, competent, and valued people sometimes have an off day, make an ill-advised or selfish choice, or are just plain mindless.¹

Like many others, I'm not quite satisfied with the Retrospective Prime Directive as it's written. I understand and appreciate Dinwiddie's explanation of it, but as a useful tool, the directive doesn't strike any chords for me. What I think the directive is trying to say is:

Retrospectives are not about blame. They are about moving forward.

So why not just say that? I'm fond of Tobias' take on it (with another phrase² inserted):

We are emotional and vulnerable beings, subject to a continuous flow of influences from a myriad of sources. Sometimes we perform magnificently, other times we mess up. Mostly we are somewhere between these extremes. In this last period of work everyone did what they did, and likely had reasons for doing so.
     Bearing in mind that there are many factors of which I am unaware.²
Accept what is. And now, what can we learn from our past actions and thinking that will inform and guide our future ones?

Whenever I'm working with a team that is still struggling to create a safe environment, I also suggest "quietly considering" this:

I will ensure that we have a safe environment
in which we can each own up to our own mistakes own our own
and endeavor to not be defensive if someone else points out my mistakes.
If someone gets defensive, we'll assume that the environment is not safe
rather than assume a personality flaw.

1. Stone, Patton, Heen, Fisher, Difficult Conversations: How to Discuss What Matters Most, Penguin, 2010, page 287.

2. Wallace C. Ellerbroek, MD, “Language, Thought, & Disease”, The CoEvolution Quarterly, No. 17, Spring 1978, page 33.

Yet Another Agile Reading List

(Updated October 2018)

I'm often asked for an agile reading list and each time I wish that I had already blogged it. What's kept me from doing it so far is that I tend to write a somewhat new list each time depending on the requester's level of experience, unique situation, and context. Such a list is also likely to change over time, but that shouldn't stop me from posting it -- this post is my thoughts at this point in time. My thoughts are likely to change.

That said, and without further ado or proof reading, here is an agile reading list.

Getting Started
Just go read the Scrum Guide. If you've never read it, you really should. It's short. But you might need something beyond that to gain a better understanding of how and why agile works, so don't stop there...

I could make this easy for me and just say read Cohn's signature series plus the Beck signature series. That'd keep you busy for a while and cover the topic pretty well.

But I can put a little more effort into this. Don't let this long list scare you. Start with this 1st block, then supplement with some of the others. I'm writing this from the point of view of helping a total agile novice get started.

Most importantly, you need to understand the agile values: http://agilemanifesto.org/ and http://pmdoi.org/ and either http://www.extremeprogramming.org/values.html or http://www.softwarereality.com/lifecycle/xp/four_values.jsp or http://xp123.com/xplor/xp0209b/index.shtml.

Here are some links about agile in general and two specific agile processes, XP and Scrum, and one lean/agile approach called Kanban. Just read as little or as much of these as you desire to get the gist of what it's all about:
http://en.wikipedia.org/wiki/Agile_development
http://en.wikipedia.org/wiki/Extreme_Programming
http://en.wikipedia.org/wiki/Scrum_%28development%29
http://en.wikipedia.org/wiki/Kanban_%28development%29

You need a good understanding of the Scrum process since it's the market share leader right now. I really really like Kenny Rubin's way with words and his Essential Scrum book is excellent. This is good: Succeeding with Agile: Software Development Using Scrum by Mike Cohn. Subscribe to Mike's blog.

Here's a good short, quick, easy to read intro to Scrum: "The Elements of Scrum" by Sims and Johnson. It includes some extra stuff that you really should do if you are using Scrum. I liked that. Well written.

I think I'll throw in http://scrumpocketguide.com/# from my friend Peter Saddington. I haven't read it, but it sounds short. :-)

Alternatives or Slightly More Advanced Items
Subscribe to my blog and LeadingAgile's blog :-).

These next few are a bit old, but you need to have read something by "Uncle Bob" and Alistair. You could substitute some other book by them if you wish:
Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin.
Agile Software Development by Alistair Cockburn.

These eXtreme Programming books are great and short and solidly apply to Scrum:
Planning XP by Beck.
XP Installed by Jeffries.
XP Explored by Wake.
Don't get the original white XP Explained book by Beck. It's talks about Load Factors and Ideal Engineering Days which I don't recommend.

If you want to broaden beyond Scrum and XP, read about Crystal Clear and the other Crystal methods by Alistair Cockburn.

Product Owner
Now we move beyond the basics into some specifics. First, let's take a look at the Product Owner related literature:

http://www.agilemodeling.com/artifacts/userStory.htm

Agile Estimating and Planning by Mike Cohn.

User Stories Applied: For Agile Software Development by Mike Cohn.

Here are some great posts from my colleague on The Product Owner:
http://www.leadingagile.com/2011/03/why-a-product-owner-team/
http://www.leadingagile.com/2011/03/product-owner-team-who-needs-to-play/
http://www.leadingagile.com/2011/03/one-real-life-product-owner-team/
http://www.leadingagile.com/2011/03/product-owner-team-design-considerations/

Scrum Product Ownership by Robert Galen. It's not an intro to agile. It's a good, thorough book on product ownership. It's full of good advice and tips and warnings against certain dysfunctional behaviors. The book contains some typos and passive voice that will annoy some people.

The Product Owner role in agile is a big job. And very important. Many say it can't be filled by just one person because no one has all the necessary skills. They say you often need a team of people with diverse skills and responsibilities to do the job well. I tend to agree. Here is some food for thought:
http://blog.xebia.com/2008/05/22/scrum-the-mythical-product-owner-role/

Scrum Master
Next, someone on your team needs to understand retrospectives in depth. If you don't get what you need to know out of the above books, this one is wonderful: Agile Retrospectives: Making Good Teams Great by Esther Derby. Subscribe to Esther's blog.

I highly recommend Scrum Mastery by Geoff Watts. This is an excellent book filled with very practical and though provoking advice.

Lyssa's book, Coaching Agile Teams, is very useful, but the novice should read the others first.

Technical
Here are some more assorted topics:

Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin. And check out her sequel also: More Agile Testing.

Read Beck's TDD book, Fowler's Refactoring book, Evans' Domain Driven Design book, and Williams' Pair Programming book.

Specification By Example by Gojko Adzic should be in this list as should The Cucumber Book by Wynne and Hellesoy.

Lean
At some point, you might need to know what people mean by Lean as it applies to software. Poppendieck wrote the books on it:

Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck

Leading Lean Software Development: Results Are not the Point by Mary Poppendieck.

To really understand lean, really and truly, read Toyota Kata by Mike Rother. This is about getting everyone in the org to make process improvement part of their daily job, to be very intentional about understanding the current and target condition, and to be very intentional about mentoring everyone about everything I just mentioned. This text will help you have a proper understanding about everything else you read about lean, all the techniques, all the metrics, all the approaches. 

Then read The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt, a delightful book. We also have his Theory of Constraints (ToC) text. Goldratt is becoming a very important person to have read, at least for lean/agile consultants.

However, if you read Goldratt, you must also read The Principles of Product Development Flow by Reinertsen. Reinertsen takes exception with the over simplified or at least naïve implementations of ToC (et. al.).

ToC brings us to the kanban process which is gaining popularity. Kanban by David J Anderson is a wonderful book,but lacks specifics on how to do the metrics when the rubber meets the road. Subscribe to the kanbandev yahoo group. Anderson's Agile Management I would say is more advanced and should be read by serious agile managers or coaches. It's a good cross section of lean, pre-kanban, ToC, etc.

Rother's book Learning To See is about value stream mapping from a manufacturing perspective. I enjoyed working through it, but i'm weird that way. Most people in software development organizations won't need this.

Scale
There are books on scaling agile: Practices for Scaling Lean & Agile Development by Larman and Vodde. And Scaling Software Agility, Leffingwell.

Manage
Management 3.0 by Jurgen Appelo is the most important book for anyone leading or managing IT knowledge workers.

Dan Pink's Drive: understand autonomy, mastery and purpose.

Not sure whether to put DeMarco's Slack, Getting Past Burnout, Busywork and the Myth of Total Efficiency here or up under Lean. I have a blog post on slack.

Fin
Sadly, I cannot recommend this book, even thought I have a chapter in it: XP 2003 Proceedings.

Finally, find a local agile/lean/scrum user group to attend and make connections. I can tell you all about the ones in Atlanta and can connect you to people who know all about the ones in Ohio and Chicago and RTP, NC.

There are probably a thousand other folks with their own agile reading list. I wouldn't mind it at all if you were to post your list here or link from here to your site.

Approaches to Retrospectives

I had the distinct pleasure of working briefly with Tim Wingfield a few months ago. Bright guy. We were talking recently about different retrospective approaches. One of his teams was in a rut with how their retrospectives were going. They tend to only be the griping and airing of grievances style and they weren't getting actionable items. Everyone was caught up in the complaints.

The great thing about agile is that you can be agile in order keep from getting into a rut. Each new client has a different situation which gives me opportunity to focus on a one aspect of agile more heavily than at another client. I get to try different nuances each time.

The neat thing about retrospectives is how applicable they are and how easy they are to apply outside of IT. Today I was sharing some of my approaches with a cycling friend whose realty group, Dillard & Company, uses a genuine team approach. I say genuine because they are a team in the real sense of the word. They aren't just a group or loose federation that incorrectly calls themselves a team.

Anyway, I had these approaches in my head and Tim had commented that my retrospective artifact was a little different than what he had seen described in writing so I thought I'd put them down in a blog post.

I tend to use a flip chart for the retrospective when I have a dedicated space in which I can leave a big visible chart. Unfortunately, my clients often lack sufficient space. So I find that I most often end up using a white board and then transcribing the retrospective notes into some tool like VersionOne or into a wiki. I like using the whiteboard during the retrospective, but I don't like hiding the results online.

When I use a flip chart, I find it convenient to draw quadrants. When I use a whiteboard, I just do columns.

Either way, in these quadrants or columns I often write:

• what went well
• what did not go well
• do more of
• do less of

Sometimes I use:

• good
• bad
• do differently

Less often I use SaMoLo:

• Same As
• More Of
• Less Of

I may use "opportunities" instead of "bad" or "did not go well". It depends on the tone of or presence of animosity in the team and whether certain terms are emotionally charged.

There are times when I really want to dig into things and fully understand what's going on. I facilitate the whole discussion. I often start out with "so, what happened this iteration?" Or, "what went well?" Or, "how did it go?" I try to record the essence of what people say. Be a good facilitator. Elicit input from the quiet ones. Try to cover each of the areas at least a little. I may dot-vote for the one or two issues to attack in the next iteration, if consensus isn’t obvious. This approach can take a while. I use this approach the first few times with a client or when we have largish iterations. If people get impatient, I don't use this approach.

Once I'm through that stage I like to switch to this other approach. I have everyone come up to the whiteboard all at once and write whatever they want in any of the columns. I request that they briefly tell someone in the room about what they just wrote. I listen in for themes or things I want to dig into during the discussion that I have once everyone is done writing. I often don't write anything of my own, but I may if I see something important missing. This gets us through the kudos and complaints more quickly so that I can get on to the "do differently" items and find some specific action item to take away. I have gotten a lot of positive feedback on this approach. Everyone feels more engaged. It gets them out of their chairs and their blood pumping.

Another approach is to ask people to write their thoughts on sticky notes. You can then read them or have them read them. You can have the team do an affinity grouping of them. I'm not sure how to keep that approach from dragging on too long, but I can see how it can help elicit input from the quiet ones.

One other thing I like to do before I run a retrospective is skim over what we recorded in prior retros. If I find an issue that was brought up over and over but that never made it into an action item, I’ll just start the retrospective with that and figure out how to solve it.

Other than in that instance, I never exclude the opportunity for people to complain about something. It's important to have a release valve, an opportunity to blow off some steam. But we don't have to dwell on it. Some things you are just not going to solve and other times just mentioning an issue can solve it.

I mix it up because it's important to do retrospectives in different ways. Regardless of how I run it, I always look for one specific, measurable, achievable, actionable action item as an outcome of the process and I make sure it has an owner.

Of course, Esther Derby's Agile Retrospectives book is a great resource for more ideas.