Planeban - A Quick offline kanban for in-flight work

As a matter of fact, yes.

I boarded the first leg of my flight from Seattle to Hanoi. I had 19 hours of flying ahead of me. I also had a backlog, and no wifi. Agile Zen was not going to be useful for me. So, I opened Open Office Writer and made a quick table.

I had a series of things to do, but with a few constraints. The first was that I was likely to fall asleep at some point, so I wanted to knock out the most important task first. The second was that I had a list of commitments I’d made over the week and needed to make good on them. Fortunately, I have a 17 hour battery and a 4 hour battery as backup, so I had enough juice to cover me.

In no particular order I wrote down my work. I had 14 papers to read for Hanoi, so I began with those.  I knew that not finishing them first would mean I’d read them when I was too tired to retain anything. Then I went to work on the feature sets for the new software projects. Finally I ended with blog posts (of which this is one).

In the end, I had a full accounting of what I’d done – so I could make sure that the files and work completed in-flight made it to the appropriate people and after-action steps were taken.

I want to point out again, you don’t need special hardware or software, you just need to visualize your work, limit your WIP, and prioritize.

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

Visual Controls are Reminders

I’ve been surprised lately by the number of people asking me about work/life balance. We feel we are undervaluing our family ties, our personal goals, our community involvement, our hobbies and our art. Oftentimes our work makes us feel isolated – we feel alone and seek meaning in our lives. Amusingly, we feel like we’ve invented this feeling.

When people tell me that their generation is somehow unique in this feeling, I ask them to talk to their parents and their grandparents. Soon they discover it is merely a myth that takes just a few minutes to dispel. When your parents laugh at your hubris for an hour or so, it’s quite a gut-check.

Nonetheless, we can posit that we’ve managed to give ourselves a lot more controllable distractions than were there before. We just don’t control them very well.

So for this third post on Task Types, we’ll do some work/life balance tasks and, like we did with work tasks, we’ll establish some rules around them. Again, let’s use colors.

Let’s say that purple represents family time. Use purple stickies and note real family time – not that trip to Costco but rather, those things that your kids will look back on and remember with a smile.

Next, let’s have blue represent those things that need to be done for the family. These are tasks like, “Fix the leak in the downstairs bathroom” or “Mow the Lawn.”

Finally, let’s use green for aspirations. These are tasks like “Read the complete works of Vonnegut” or “Learn Personal Kanban” or “Get CPR Certificate.”

Sound good? Great! So what happens next?

These colored tasks can appear on your Personal Kanban as task types. You can then set up your balance – literally. Every day you can pull one purple. Every week you can pull two blue and two green. And in your DONE column, you can see where you are with your goals.

Work/life balance now has a shape and a color palette.

Having said this, I consider my work and my life as indiscrete parts of a continuum. I love what I’m doing at Modus and the people I’m doing it with. So for me, the balance comes from not becoming so enamored with Modus work that I forsake all other activities.  And, yes, I do need to work on this.

But, I will venture a guess that if you actively dislike what you do professionally, work/life balance will be unapproachable. You simply cannot dislike that much of your life and expect to achieve a healthy balance.

Photo by Robotography

Some things are hard to maintain

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:

Personal Kanban with Stuck Work Taking up WIP

To this:

Personal Kanban with Stuck Columns

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

Mrs Winchester's WIP

Flexibility is an unsung virtue. People want absolutes: “Do this, then do that, don’t deviate and then you’ll achieve success.” But we all know that absolutes are often false, and that context is king – in life, in work, and in all human endeavor.

So limiting our WIP needs to take context into account, even WIP limiting needs to be flexible. Sometimes tasks just don’t behave themselves. Some are extremely urgent, while others become mired down for whatever reason. Both of these scenarios demand respect.

I recently had a session with a personal coaching client who has just begun using Personal Kanban. He had set up a few rather detailed value streams, but was having trouble limiting his WIP because different task types were causing conflicts.

At Seattle Lean Coffee, the topic of task types has come up at almost every meeting.

It’s clear we need to talk about task types here.

So, let’s examine the case of a coder, whom we’ll call Richard.

A hired gun, with a busy home and work life, Richard is juggling multiple commitments. His primary client is a company that uses an esoteric software system to run their business. Not only is Richard one of only a few (less than 5) individuals on earth familiar with this particular package, the others are not interested in working with it any more.

Over the course of each month, Richard receives tasks from his client. These tasks come with some – but not rigorous – prioritization. Every so often though, a bug will surface that impacts the company’s operations, and Richard will need to drop what he’s doing and focus instead on that bug.

Over the years, the system Richard is “lucky” enough to be stewarding has been touched by a succession of coders resulting in a tangled mass of spaghetti code that is undocumented, and often difficult to read.

Think of it as the Winchester Mystery House of source code.

All too often, problems often arise requiring additional work just to locate the issue, not to mention having to test and find the impacts of any changes he might make.

From his experience, Richard has identified five main task types:

• Easy tasks – these are straightforward, can be done quickly, and will require minimal testing;
• Normal tasks – these can be done in a few days without much, if any, outside interaction;
• Hard tasks – these are tasks that will require a lot (or at least an unknown amount) of work and research;
• Escalated tasks – these are tasks that cause the client discomfort and need to move to the front of the queue; and
• Emergency tasks – these are tasks that displace the work already in process and become in-process.

For Richard who is working solo and off-site, parsing his tasks out like this is invaluable. Since his client has had little visibility into his workload, he’s begun using an online Personal Kanban tool to create a workflow that he can share with his client. Tasks are colored according to their type, allowing the client transparency into the mix of work he has.

Right now, the client has no way of knowing the grades of severity of tasks. Tasks that sound simple to the client can sometimes be difficult in the code. Similarly, tasks sound hard may actually be very straightforward. When the client is waiting for results, it’s important for them to know which tasks look easy or hard. This will directly inform the client’s risk assessment of setting Richard loose on a particular task. If he identifies one as hard, the client can then re-assess the priority of the task and the investment it might require.

With client access to Richard’s Personal Kanban, and task types clearly differentiated, clients can work alongside Richard to prioritize and schedule specific tasks. This will increase mutual understanding by giving them something visual and tangible to speak to when they have their regular meetings. Work can always be re-prioritized on-the-fly by mutual agreement. With transparency into Richard’s workflow, the client will be less inclined to feel behind schedule because level of difficulty is now understood.

Richard can now use all this information to help guide what items to pull when he’s moving from one task to the next. Escalated and Emergency tasks are self-evident and should be rare (if they aren’t rare, that points to other problems we’ll talk about in a later blog post). Beyond those, Richard’s risk assessment for pulling specific tasks is based on an amalgam of client priorities and available time.

If he looks into his backlog and, if he has only a few hours, he can pull out an Easy task. If he has a few days, he can pull a normal task, etc. His risk profile for pulling tasks is now informed by these task types.

And yes, this is all fine until some task goes wrong. Which of course will happen. This we’ll cover tomorrow in the post “When Tasks Don’t Go Right.”

Photo by Jeffc5000