Jim Henson and Frank Oz

I am 46 years old (at the time if this writing, it would be kind of nice to just keep on being a healthy active 46 year old, though).

Being 46 year old and American, I was raised by three parents: Don and Jennifer Benson…and Jim Henson.

Like most kids when I was growing up, I lived with Muppets. On Sesame Street, on the Muppet Show, in the Muppet Movie, even on Saturday Night Live a few times. Muppets like Kermit, Ernie, Bert, and later Yoda are as much a part of my generation’s psyche as anything can be.

But as we’ve aged, we seem to have lost sight of Jim Henson’s vision, his message, and his passion. In this Lean Muppets series, I hope to re-introduce a lot of us to Jim’s message and show how we might either learn from or be actually living out some classic Muppet skits every day.

This series is for everyone who works in an office, has an idea, follows Lean / SixSigma / 5s / Lean Startup / Personal Kanban / Kanban for software development / Lean medicine / Lean government…you see how adults complicate things?

This series is for everyone who feels dissatisfied, but would rather not.

This series is for people wondering why their business is broken, and who are tired of non-Muppets telling them why.

In a recent (April 2012) interview with iSixSigma magazine, I was asked what I thought Lean was all about. I talked about Deming’s Theory of Profound Knowledge. (I will post a link when it is published).

When I thought about this a few days later while enjoying a bout of jetlag in a Swedish Hotel, I realized that Deming’s vision was Jim Henson’s vision…and it’s a vision I too share.

To engage my hubris muscle, I will now say what I believe that distilled shared vision is:

If we care, we create.

If we create, we improve.

If we improve, we live.

That is my vision. That is Lean. That is Muppets.

How to implement the vision? Here come the guides (updated as they come out over the next month):

1. Variation Can Help: Lean Muppets Post 1
2. Failure Demand and Unthoughtful Production: Lean Muppets Post 2
3. Sunk Cost, Loss Aversion, and Cannibalism: Lean Muppets Post 3
4. The Language of Metrics: Lean Muppets Post 4
5. You Are in My System: Lean Muppets Post 5
6. Root Cause Analysis: Lean Muppets Post 6
7. Flow, Cadence, and Slack: Lean Muppets Post 7
8. Practice, Practice, Practice: Lean Muppets Post 8
9. Lean Muppets Post 9
10. Lean Muppets Post 10

Disclaimer: Jim Henson and the Muppets are a global treasure that we all share in the legacy of. We learned to count, spell, cooperate, and respect each other through Jim’s work. Modus Cooperandi and Personal Kanban have no legal relationship with the Muppets, but we sure were influenced by their wisdom.

I will not be accused of burying the lead here and say right up front:

Your Value Stream Is Wrong

And it always will be.

This is a good thing, as we work from day to day the steps we take to complete work subtly or even violently change. When we move from home to work to a special project, there are subtle and important differences to how we do what we do.

Today’s anti-pattern is is painful to watch. When people fall into a certain way of visualizing their work or a certain value stream, it becomes comfortable to them. So comfortable, in fact, that they are reluctant or downright resistant to change or improve it. They then flounder in increasing painful work because their value stream doesn’t match their actual needs.

Let’s say for example that Mozart is the manager of a record store in Bavaria.  He has three main types of work over a given month. One is order new stock from a variety of suppliers. The second is make sure the books are in order. The third is … everything else.

Everything else is actually easy – even though it may be rather chaotic at times. We visual this type of work with a standard Personal Kanban value stream of READY | DOING | DONE. The work is going to be varied and extremely task-focused. Each of Mozart’s tasks is its own element of value. The best way to manage this work, to weigh these options, and to get these tasks completed is in a model that accepts the complexities and inherent chaos of day-to-day work.

However, in other more project centered types of work, he may get more from value streams geared toward tracking of that specific work or project.

For example, when ordering stock, the ideal world would tell you that orders are placed and received each month at set times. Mozart’s store has a mix of goods provide through suppliers ranging from large vendors to one person in their basement. Order responses are highly varied, leaving Mozart having to track not only the rate at which inventory is sold, but also the average response times for ordering popular items.

So here we see Mozart’s order processing kanban. The value stream is quite specific to the value created. This is repeating value created in a fairly predictable way. If Mozart was only using the READY | DOING | DONE value stream for this type of project, he would have dozens of tasks polluting the rest of his work. The stages in these value streams may not actually be tasks. So, say he finds it’s time to order a new set of Buddha Machines – so he contacts the people in China via email. When he does that he can move the Buddha Machine ticket to ORDER.  A few days later, they might send him a letter saying, “We received your order and will get to it soon.” Mozart can then move the ticket to CONFIRMED – even though he really didn’t do any task himself. The point here is that there is new useful information about the state of the Buddha Machine order. A few days later, he gets an e-mail saying that the Buddha Machines have shipped. Mozart again can move the ticket.

From time to time, new tasks may appear in Mozart’s regular Personal Kanban that say things like “Order new AxMxAx album”. At that point, when Mozart does do the ordering, he will move that ticket to done, but also start a new ticket in the order processing kanban.

So, here we see that Mozart’s work can have more than one value stream.

Now, let’s say this works for Mozart for a while, but he begins to notice that even after he receives confirmation many orders are not shipped.  Tickets start to back up at the “ordered” stage but don’t progress beyond. Mozart can then come up with ways to fix that problem. For example, he could insert a “remind vendor” column that he can move tickets to if they aren’t shipped in less than a week.

Mozart must change his value streams to meet his needs. So must we all.

Image by Sprezzatura.

Last week, Eva Schiffer of Net-Map wrote me and said:

I have just erased my to do list and transformed it in something kanban-like. My own to do list format, that always worked well for me, had 4 categories:

Important and urgent
Important, less urgent
Less important, urgent
Less important, less urgent.

That helps me a lot because I normally love the less important, less urgent tasks, and while they often lead to really interesting creative outcomes, it is important for me to keep procrastination at bay and make sure that I don’t just impress myself with the number of tasks performed, but also do those things that are most urgent and/or important.

This got me thinking about the relationship between productivity and effectiveness. Eva recognized that simply increasing her throughput was not enough, that was mere mindless productivity.

What Eva was searching for was effectiveness.

At Modus, we do dynamic prioritization using a priority filter that looks like this:

For Tonianne and myself, this works wonders. We constantly have a short list of items that need doing, and as they move from 3 to 2 to 1 they become more important. However, prioritization is a contextual exercise that varies from moment to moment. As we can see here, “Eat all the chicken on earth” is Priority 2, but that could suddenly change to Priority 1 if suddenly I were in a place where all the chicken on earth was accessible.

Eva, like many organized people, uses a matrix to ascribe values of urgency and importance, which results in something like this:

Major Tom's Backlog

In the case of Major Tom, he has been sent into space to find out what’s there. He’s a celebrity and everyone is watching him. There are a variety of things he could be doing up there, but he has a a backlog that varies between levels of urgency and importance.

So for example, the papers want to know whose shirts he wears. That’s important both to his individual fame and to the space program in general because after all, it’s being good to the press. But at the moment, he’s in space so he can get to that later.

Major Tom's Workflow

If the press scores an interview while he’s up there, though, it can become relevant and therefore is something to complete.

So we reach Major Tom here in the middle of his work day. He’s already managed to tell his wife he loves her very much, and he’s stepped outside the capsule. He’s put his previously active conversation with ground control on hold because at the moment, he’s working on other things. And he’s now floating in a most peculiar way (and noticing how different the stars look).

Major Tom is still limiting his WIP and he’s still visualizing, even if his backlog is drawn as a matrix rather than columns. The matrix is a familiar organizational tool for him, and it should be preserved. (Although he probably should have checked his instruments.)

So Eva’s concern is very real – we stand a real risk of becoming mindless production units, grinding tasks out at hyper-speed without assessing their value. The key with Personal Kanban is to assess the value of what you are doing – however it is that you define value.

We’re all individuals – quality, value and growth are different for us all.

Not only that but quality, value and growth are also contextual. Today, home repair might be very low on your list. After a tornado, however, it’s probably going to be pretty high. Did you put it there? No. Life did. Context shifted. For that reason, just-in-time dynamic re-prioritization is key for workload management.

So be like Eva. Find the way you define your work – visualize it, and thoughtfully examine how you can best be effective.

Don’t strain your brain, paint a train
You’ll be singing’ in the rain…

- Blondie

Action over Words

Your brain is a muscle. As we repeat certain actions, our “muscle memory” becomes comfortable with those actions, and programs itself to anticipate them. As it trains itself to anticipate them, it optimizes for them. This is the basis of kaizen, continuous improvement. Your brain gets used to your workflow, it becomes an subconscious process, and so it looks for ways to do things better.

Smoother.

Faster.

You get sensitized to completion. Sensitized to waste.

So using Personal Kanban on a regular basis, through its visual and tactile interactions, sensitizes you to the building blocks of success.

Tell me and I forget.
Show me and I remember.
Let me do and I understand.

- Confucius

Simply put: your brain responds very well to doing. The active nature of Personal Kanban is what your brain wants. Confucius figured this out 1700 years ago.

Managing your workload with static lists, while they can help you organize, doesn’t have the same brain-training impact as having a visual tool like Personal Kanban. Lists don’t involve motor skills or elements of flow.

Lists merely “tell you.”

Personal Kanban both shows you, and lets you do.

Image by Rob Web

Throw out the schedule

In my previous post, “GTD & Kanban: Similarities, Differences & Synergies Between The Two“ in this series, I talked about using Kanban for managing the flow of work, rather than having any number of projects and someday/maybe items in separate lists which are reviewed every week to a month.  In this post I will describe how using flow to manage GTD projects and someday/maybe lists can be beneficial.  In a future post I’ll describe how this also translates into flowing actions in a context, such as the work place, and limiting the work in progress (WIP) of these actions.

Again, for the basics of GTD I recommend the material linked from Wikipedia.  The basics of Personal Kanban can be found on this very site.

What are “Someday/Maybe” lists and Projects?

Getting things Done (GTD) has a number of horizons above any given action: Projects, Goals, Focus, Vision & Purpose.  These are aimed at providing yourself goals to aim for and to test your choice of actions against, so that you aren’t just “doing”, but are actually moving toward a goal, and these goals join up to achieving larger objectives in life.

In GTD, anything you wish to achieve that has more than one specific  action is considered a project.  For example, even arranging a meal out at a restraunt could be considered a project as you will have to go through actions similar to: who to invite, confirm who is available, when to go, where to go, book a table, confirm booking with invitees and go.  The reason why this definition works is, actions could be in any number of places in your personal productivity system, be it a calendar or a list, and when they are done there needs to be a reminder in your system that acts as a touchstone so that you can ensure a next action is available to move forward towards an envisaged successful outcome.

Any objective that requires action, yet does not make sense to undertake as-at-now, yet you feel this is something you would like to do in the future is considered a candidate for the “someday/maybe” list.  Someday/maybe is reviewed at regular intervals to see if an item needs pulling into the current project list, or, if only one action is required, a contextual action list or placed on a calendar.  Why have a someday/maybe list?  Someday/maybe lists assist in clearing your head by placing all these wishes and thoughts into a trusted and regularly reviewed system.

Managing Someday/Maybe & Projects by using a Personal Kanban

Rather than have multiple flat lists, one for projects and one for someday/maybe with no interaction between them other than once a week if not longer, lets use a Kanban to represent both!  The example bellow includes prioritisation, a step for the initial brainstorm of what success looks like and what actions may be required, the doing part (working), and the done part.  All with WIP limits for focus.

Lets do a quick illustration:

1. You get a new project at work called “Project A” that is going to require several actions, so you place it on the backlog as you have plenty to do already.  The backlog acts as your someday/maybe list.
2. A space becomes available on your “Should” lane, which prompts you to look at your backlog for possible projects to start prioritising, you assess the items against your current Goals at work, and select Project A.
3. Over time, Project A moves from “Should” to “Ready”, and before undertaking the work, to the elaboration lane for envisaging a successful outcome and working back to the next steps from where you are.
4. Once Project A moves to the “Working” lane, you place the next action discovered as part of elaborating into the appropriate context list or date on the calendar.
5. Actions get performed overtime, and eventually the successful outcome is achieved and Project A is placed in the “Project Goal Achieved!” lane.

Clearly, due to the variance in size of knowledge work or personal projects it’s difficult to set a limit on “working”, so I suggest you experiment with this number, and try to keep it as low as possible for focus.

Going back to the purpose of someday/maybe, it is possible you have single discreet actions on your backlog now, so it is worth moving those items to an appropriate context list or calendar entry when the time comes that you wish to do something about them.  Personally, most of my Someday/Maybe items were and are projects, so I don’t mind the backlog being closely associated to projects.

Let's Work Together

In this article in the “GTD & Personal Kanban Series” we will explore the why? behind bringing GTD & Personal Kanban together.

What is Getting Things Done (GTD)?

GTD emerged as a highly effective and popular personal productivity approach in the early two thousands.  The approach consists of a five stage process, a workflow to guide that process and a couple of techniques for handling choice around what to do at any given moment, what should be progressed as soon as possible or someday/maybe, and also, how to handle life and work’s various horizons – from now at this moment, all the way through to what is important to you in life as a whole.  This article isn’t a ’101′ on GTD, for that there are plenty of resources available, which are linked to here.

On a personal note, I find that GTD frees my mind enabling me to focus totally on the tasks at hand, and also represents a concrete approach to help achieve Stephen Covey’s first three habits of his famous: The Seven Habits of highly Effective People.

What is Kanban?

This whole site is about Kanban in the context of solving personal and group problems around the home and workplace,  for a great 101 head over to here.

Kanban has allowed me to increase the throughput of things getting done.

Similarities

Though targeted at different problems, there are similarities between Kanban & GTD.

• The breaking down of “stuff” into discrete items to be processed – With GTD this happens as part of taking each item from the physical and/or electronic inboxes and asking if it is actionable, and if so, what is the next physical action.  With Kanban, we create stories which form the Kanbans themselves, to then be placed on a backlog.
• Inboxes & Backlogs - These are both areas where potential work is collected, and represents the start of either a GTD process with inboxes, or a Kanban process with backlogs.  The similarity here will differ based on context, and it’s fair to say that with a backlog, some initial processing of the material onto the backlog may have taken place.  With GTD, raw material is added to the physical or electronic inboxes.
• Lists, lists & more lists – Both GTD & Kanban utilise lists.  In GTD’s case it can take any form as the process is not prescriptive in it’s concrete implementation.  In Kanban’s case, there are lists, though they are split into dimensions, such as stage/state/work station the story is at, and there is additional process related information, like WIP limits and checklists.
• Contexts – Kanban & GTD are very flexible in their applications.  Both can be shaped to fit various situations.  For example, manufacturing cars, or managing your reading list in the case of Kanban.  GTD can have a “context list” for pretty much anything you can imagine, from a specific location to a situation you find yourself in, where certain work makes sense.
• With both GTD & Kanban granularity is important – For GTD, it’s not about writing lists of goals: “buy milk”, “fill in tax return”, but rather, GTD is concerned with determining the next action required and given the right context or time, just performing that action without having to constantly figure out the next step each time.  In Kanban’s case, it favours work items that are discrete, unambiguous and ideally of a similar “size” to reduce variance.
• Support for levels of granularity – Kanban can achieve this with a kind of nesting of Kanbans and horizontal swim-lanes.  Or, multiple Kanbans, one representing a higher level of granularity than the other, whereby the items in the “Kanban in the large” are related to those being processed in the “Kanban in the small”.  I use an approach like this with my current projects and their related current actions being processed.  GTD achieves multiple levels of granularity with lists.  There is: purpose, vision, goals, focus, projects and plenty of contexts, for example “At work” & “At home”.
• Addressing Waste - Kanban addresses waste explicitly as does GTD.  Kanban using WIP limiting and “stop the line” techniques with a general attitude of continuous improvement.  GTD insists that any piece of “stuff” that enters your world should be processed once and once only, by using techniques like a ‘Zero Inbox’ policy and the ‘Two-Minute Rule’.
• Pull – At the most abstract level, both approaches exist to process work to fulfill a demand.  Both approaches pull work through a process to achieve the goal of getting valuable stuff done.

This is encouraging, it would appear that we have a lot to work with in terms of bringing these ideas together.

Differences

There are obvious differences in the two approaches, given they are aimed at different problems. However, I find little that is polarised or in conflict but rather the differences are complementary in enhancing areas of non-existence or weakness in the other, when applied to personal productivity.

• Reduced backlog size versus a clear head – Kanban comes from the world of Lean Manufacturing, where the Theory of Constraints philosophy is pervasive.  Large backlogs are considered to be wasteful as the cost of maintaining them and the friction they cause impacts the value that will be generated. A backlog that is sized so that it is processed rapidly and renewed with new stories regularly is considered ideal.  GTD is different to this, there are no caps, implied or artificial.  GTD encourages a clear head, to reduce stress and allow complete focus on the task at hand.  Obviously, there is a conflict there on face value.  In the past I had GTD action lists with hundreds of action items on them, and project and someday/maybe lists with 10s of items.
• Kanban allows for Work In Progress (WIP) limiting -  GTD doesn’t explicitly try to limit that which is being worked on in any hard manner, rather a softer approach which asks if something is relevant against focus, goals, vision, purpose or just plain want to do it now.  Sadly, GTD can lead to thrashing, when the total number of options for doing is enormous.  Kanban is all about focus, and if used well can seriously reduce the chance, let alone the act of context switching.
• Visual control - Although I’m sure there are ways this could be addressed currently, as a whole, most GTD implementations seem to be light on visualisation of WIP.  Kanban is all about visualisation.
• Process definition – GTD has a definite default process, which is not prescriptive in so far it’s not all or nothing.  Kanban doesn’t define a default, but rather provides tools to be used in a greater or lesser extent to get the right result in a context.
• Prioritisation – In GTD there is no prioritisation as such.  By virtue of the fact something is actionable, it will either appear in a context action list, calendar, waiting for (delegation) or may appear project list.  With Kanban there are  all kinds of ways priorities can be defined.
• Time critical actions – Kanban is about flow, so specific times and dates aren’t catered for.  GTD does use calendars and possibly tickle files to cater for those things that do need attending to at a specific time and date.

I am certain there are more differences here, so please do highlight any to better our understanding.

Synergise

Lots of similarities and lots of differences, generally of a non-conflicting nature. The question is, where can we benefit from bringing these powerful approaches together?  Lets see…

Kanban can help GTD a lot! The problem I have had with GTD is flow, thrashing and WIP limiting at all stages in particular contexts, especially the backlog.  I know there is waste there, given the number of times I have conducted a review and found:

• It takes ages because of the size of the backlog.
• I find out-of-date actions/projects, again due to the size of the backlog.
• Feel like i should be getting some of the value of the review just by doing, instead of waiting for the end of the week review.
• I have also struggled with pulling projects from the someday/maybe into current projects lists.

GTD can help Kanban in a personal productivity context by:

• Providing a way for people to clear their heads to focus on what is at hand.
• Excellent techniques for identifying what should be done or not.
• Doing actions not goals, by forcing the right questions at the beginning of processing “stuff”, instead of constantly asking what do I need to with this?
• Handle work that needs to be on the calendar and most importantly some simple rules to motivate doing!  The Two Minute Rule being a great example.
• Delegation.
• Levels of focus in life and work.  Kanban doesn’t address what it is you are flowing toward.

Over the coming posts in this series I will try to illustrate the above synergies with examples.  Again, please do comment, I’m keen to explore this more myself.

Books are Life

If you are anything like me, you will have a monster reading list.  Do you manage it?  Do you focus on a few books at a time?  If not, maybe you should, to better enjoy that fiction or help manage your reading based learning?

Problem – Too Many Books, Not Enough Time & Bad Habits

I have a lot of books waiting to be read thanks to a nasty ’1-click’ habit with Amazon, I also have a decent amount of quality reading time due to a lengthy commute, yet I just can’t read them all soon enough, and the list keeps growing.  Part of the problem is that until recently I had a bad habit of picking up books, reading a few hundred pages, getting distracted by another book,  and before I know it I have five books on the go, which is plain silly.  The result was a load of books I have finished, and a load I have touched on, yet not fully focused upon and completed.  I asked myself – “If only I could drop this wasteful habit and focus on completing a few books at a time, the NET result would be different, namely, more books read and better understood over any period of time, with less wasteful unfocused reading and rereading”.

Solution – Enter the ‘General Reading Personal Kanban’

Funny name for this pattern right?  Why not just “Reading Personal Kanban”?  Well, I’m going with this one on the basis that I think  there are two types of reading we do, an end-to-end style (General Reading), and for those that use various learning techniques, like a SQ3R, a ‘SQ3R Personal Kanban’ pattern is in the works, so expect a post soon.  In the meantime, ‘General Reading’ can encompass anything factual or fictional, and I personally tend to carry one of each type of book with me.

The root of the problem is one of focus and priority.  If there is one thing I have learnt about Kanban is it can be used, amongst other things, to address these two subjects simply and directly.  Below is an example based on my current reading list, using a great tool called AgileZen:

Manage that reading list with a Kanban

How does this give focus and priority?  Quite simply.  The Kanban describes the process from left to right of first prioritising the reading, reading and then finishing books.  Each step, bar the backlog and the completed step, has a work in progress limit (WIP).  This WIP limiting is the aspects that enables the narrowing of the prioritisation, then tight focus on the act of reading – I like a WIP of two so I can have a factual and a fictional book on the go.  To complete a book, we pull a book off the backlog through the process to add to the flow of books being read over time.  You can read more on Kanban in general and why it works elsewhere on this site under Primers.

My own General Reading Personal Kanban forms part of my overall productivity system, which I am writing about here.

1. GTD & Kanban: Similarities, Differences & Synergies Between The Two
2. GTD & Kanban: Managing The Relationship Between Someday/Maybe & Active Projects
3. GTD & Kanban: Work In Progress Limiting GTD Next Actions Within A Context
4. GTD & Kanban: Inboxes, Lists, Calendars, Kanbans & Mind Maps Working Together In Harmony
5. GTD & Kanban: An Example Of It All Coming Together

Getting Things Done Workflow

I am getting value from the changes I have made to how I work, yet still experimenting to improve.  Any suggestions or questions, please do comment or email in the interest of moving all of our understanding forward.