You're In My System: Lean Muppets Post 5

Gonk and Geefle Build a Collaborative System

Petri Net For Geefle and Gonk

This one might seem a little blatant, but Geefle and Gonk are doing more than simply dividing labor - they are systems thinking in action.Initially, the system is every Snooian for himself.  The trees provide fruit and feeding  should be a solo endeavor.Unfortunately for Geefle and Gonk though, Darwin apparently skipped Snoo. But they've somehow managed to develop shared but spacey verbal language without ever having actually eaten. (This could easily be one of the least defensible Muppet sketches for the Continuity Director.)So they set up a multi-part system that requires Geefle (the tall French/Welsh character with frozen elbows) to harvest the fruit, and then for Gonk (the short, enabling and emotive Italian character) to feed the fruit to both of them. Luckily for them, nectarines are excellent sources of calcium, potassium, magnesium, and vitamin C - and they have a bit more protein than the average fruit.One can see a clear value stream emerging: fruit grows on the tree and enters the backlog. When Geefle and Gonk are hungry, Geefle picks the fruit, then bounces it off of Gonk's head. Gonk responds with a "gonk," and then feeds the fruit to Geefle and if he's hungry, takes some for himself.A petri net for the Snooian System would look like this:This chart shows that only when fruit exists and Geefle and Gonk are both hungry does the feeding system activate. We can then dispatch Geefle to pick the fruit, when he has the fruit he can throw it to Gonk, who then can feed himself and Geefle.But the system has a bit more complexity that the normal Personal Kanban; it's not quite linear. Three conditions must be met before the work can begin to flow. If there are no nectarines, work cannot commence because there is no fruit to pick. If Gonk is not hungry, then he'll be off playing Snoo-ker and not be anywhere near the tree. If Geefle isn't hungry, he's also unlikely to be available. (Remember, these guys just invented cooperation - they're not even close to being ready for altruism.)And it might turn into a Personal Kanban like this. As Geefle and Gonk celebrate the success of this system, they appreciate that each others performance is contingent on the system. So in the current hunter/gatherer state of Snoo, nectarines come when they want. However, the video implies that there is only one nectarine tree on the entire planet. If we ignore the obvious issues of one specimen from each race and you know...reproduction, this means that Geefle and Gonk are going to need to become skilled at husbanding an orchard, which requires an expansion of their value stream.Which means expansion of their system.Likewise, this means that Geefle cannot be blamed for lack of harvesting if the nectarine tree is bare. Until the value stream expands in some way to control the supply of nectarines, interruptions in service are in no way Geefle-centric.This is fifth in a series of Lean Muppet posts. For a list of Lean Muppet posts and an explanation of why we did this, look here -> Lean Muppets Introduction.

Mozart’s Record Store: Personal Kanban Anti-Pattern 2: Only One Value Stream

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

Your Value Stream Is Wrong

Normal PK Board

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.

How To: Mapping Your Value Stream

When we build our kanban – whether for ourselves or for a team – we first need to build a value stream. A value stream is simply a list of the steps you take to create value. When we build a kanban, work flows along the value stream and this visualizes our flow.

Before We Begin

There are some quick tips about a value stream.

1. It should match reality as closely as possible.

2. It should be only as detailed as necessary to see and understand your work flow.

3. As your understanding and contexts change, your value stream will also change.

These three tips are telling. Words like stream,flow, and value are all difficult to pin down. They change, they evolve. In tip number one, we want to match reality as closely as possible. We will never draw a map that perfectly matches our workflow forever.

The Beginning: Start with the Ends in Mind

What is it you are doing?In a meeting you may be:

• fully discussing a topic

• coming up with action items

• planning a future set of tasks

At home you might be:

• delegating chores

• planning a vacation

• building a deck

During the workday you might be:

• creating documents

• managing staff

• building a section of an airplane

Kanban End States

All nine of these might have very different end-states.So, if we are writing a report, the end state might be “publish.”The other end … your backlog … is usually called “Backlog” or “Ready”. That is where your value stream starts. So, for our publishing value stream, our backlog looks like this:

Next Step: Fill in the Blanks

Full Sample Value Stream

Between start and finish is creation. What steps do you take to create something? Working backwards from publish, we might have collation, before that is final, before that is second draft, and before that might be the first draft.This now starts to build a stream into which the specific sections of the report can flow. The report team can now track each section or chapter as it moves toward completion.

Important Bits to Remember

1. Your value stream is your best educated guess as to how your work is actually occurring.

For some teams, the value stream above will work nicely. They would likely have a report that is from a template and being updated or customized, because the value stream suggests a very orderly process with no surprises or constant re-writes. Other teams will have a value stream that visualizes more editing, document re-organization, or people involved.

2. Your value stream will change.

As mentioned above, your value stream will change as you better understand your work. You do not need to sit around for a month figuring out the perfect mapping of your value stream. Just get one up and start working. You can refine as you move along. Different phases of projects may require very different value streams. Do not allow yourself to fall into the trap of rigid process.

3. Your Value Stream is Fault Tolerant

If you move a stickie to the right and something changes to make you move it back to the left – this is not a problem. It is reality. You really did move a chapter from the first draft to the second draft, conditions changed and then it moved back to the first draft stage again.

This is a Personal Kanban 101 Post. See others in the series.

Complex Lives Pt 1: Jessica’s Future In Progress

Ready –> Doing –> DoneLife presents us with opportunities, and so we've no choice but to take on concurrent projects. Unfortunately they don’t always conform to that simple Ready –> Doing –> Done value stream.Last month I was in San Francisco giving lectures on Personal Kanban at Stanford and Keller. My host for the trip was my good friend Jessica. Jessica is a single mom. She  has two jobs on opposite ends of the Bay. She  is studying for her financial advisor certification. She is training for a triathlon.Jessica has a lot to keep track of.As a mathematician and an expert in intangible assets, it was not a big leap for Jessica to recognize: (1) she had so much on her plate that busting her WIP limit was guaranteed, and (2) making money was only one asset out of many she had to devote time to.So on a sunny Sunday morning at a coffee shop, the simple question “Do you want to talk a little about your Personal Kanban” quickly turned into a 2.5 hour conversation. We discussed what she valued, what her goals were.It soon became clear that Jessica is not simply goal-oriented, she's a goal-collector. So we needed to get that under control. Goals are awesome, but when they start generating more tasks than we can handle – they need to be tamed.We agreed she needed more than a WIP Limit – she needed a FIP limit. Future In Progress. She had the triathlon, the certification, a book she wanted to write, and more. It made sense to pick two and (no pun intended) run with them. The triathlon enforced health and working out, so we couldn’t say no to that. The certification was immediately necessary for her job and short-term. So that too was obvious. The others, went into the FIP queue.Jessica now had a FIP limit of two.

When Good Tasks Go Bad

Yesterday we were introduced to Richard, who is juggling the demands of several clients trying to keep each of them happy. His largest project entails working alone on a client's mission-critical legacy system. So in the last blog post we discussed his tasks and task types. As we discovered, outlining those task types proved invaluable to him when needing to communicate how he was working to meet his client's requests.In addition to needing to distinguish task types, Richard explained one of his biggest problems he faces is getting mired down in tasks where the solution was difficult to find. (Remember, the system he's working on is undocumented, complex and the work of several coders - so interpreting what he's reading is kind of like solving the DaVinci code every day.)Interesting work perhaps, but it can eat into your personal life when tasks routinely cause you to work late.When I asked him out of 20 tasks, how many are likely to go afield, he responded with a tentative "15."Holy moly - FIFTEEN!Needless to say, 75% of something impacts process. You can plan for 75%. 75% is not an error, it is status quo.Then I asked, "Does your client understand the miracles you are working?""Not really," was his reply.When the client doesn't understand status quo, that's also a problem.So I explained how we needed to make these issues explicit for two reasons:1. To Stop Richard from Becoming Mired Down We want to give Richard the ability to note a task as blocked, to identify the type of blockage, and to explore some options for action. (Note: the task may be blocked, right now that's miring Richard down. We want to give him permission to move around.)2. To Communicate Status on Specific Tasks We want the client know at all times, what's going on.First, we examine what the major blockage types are:

• Interaction Blockages - These tasks have begun and require help from an outside party, and

• Slogs - Tasks Richard has to slog through, alone.

So, just as we did with the task types in the previous post, a useful way to visualize these blockages is also with color.Task types were specific to, and travel with, the tasks. If these types of blockages are rare, then they would also be task-specific. But at 75% they are actually part of the workflow. They are likely events in Richard's regular working.His workflow would go from this:To this:Richard allows himself an overall WIP limit of 2. But "Stucks" get so stuck that the only way he can move forward is to do other work until something happens that will unstuck a stuck. (release a stuck?) This results in exceeding his WIP limit because incomplete tasks wind up littering his value stream.The new "stuck" columns are WIP-exempt and allow Richard to put active tasks in Coding, Testing, etc. while the stuck tasks are allowed - at least momentarily - to languish in the stuck areas.Admittedly, this is totally not a preferred way of working. If Richard were anything other than a lone actor, I would do everything in my power not to suggest this. I would be looking for ways to bring teamwork to bare to solve these stuck tasks. But historically Richard has had no team to rely on, and it serves little purpose to have him try to force solutions when they are slow to come by design.Again, with a full 3/4 of Richard's tasks being put into a holding state due to complexity or the need for additional input, that activity needs to be visualized before it can be dealt with. We need to see the procedural breakdown to refine our understanding of it and then, and only then, can we hopefully deal with it.Perhaps 70% of these stuck tasks deal with a few, identifiable areas of the system. Richard could then add up the time he's spent working with those specific areas and approach his client with a suggestion that he actually re-write those areas from scratch. As Richard did so, he could document his code and adhere to a coding standard that was higher than the one the original authors adhered to. This in turn would make the code more maintainable and, in the end, remove 70% of future blockages, saving his client money and Richard future heartache.I can't stress this point enough - the goal here is to visualize what is really happening, and then do something about it. Without the assistance of visualization in this and the previous post, neither Richard nor his client could gain clarity into the complexity of Richard's work load. Now that both he and his client have work types and are visualizing the tasks that are mired down, they can at long last make decisions that free Richard from long work hours and difficulties in estimation.Now Richard can better schedule his work time and attempt to achieve the coveted albeit elusive work / life balance. Not surprisingly, tomorrow's post will address this very topic.Photo by Steve Jurvetson