None of us can know everything; each of us knows something; and we can put the pieces together if we pool our resources and combine our skills. ~ Henry Jenkins via Jabe Bloom

This was one of Jabe’s slides.

It reminds me of a discussion I had while I was living in DC with a recently retired CIA friend. We were discussing how intelligence was gathered in the past, and how current reality was more complex. Before we had a few, easily defined enemies who behaved according to fairly predictable patterns.

The Bad News

Today, we are working against a more amorphous “enemy.” By definition, the amorphous enemy is less defined. Because it is less defined we know less about it. Because we know less about it, it is more scary. Because it is more scary, it is more stressful.

In short, our enemies have become more complex, unknown, and scary.

This means two very important things.

1. We can’t have one standard response to threats

2. We are going to imagine a lot more danger than is actually there

In our own work, we feel these threats all the time. Too many tasks, too many data streams, too much stuff coming from too many directions. We don’t have time to think, let alone collaborate.

The Good News

The good news is that we can use Jabe’s quote from Jenkins to deal with this complexity more effectively. And we approach Jenkin’s counsel through Limiting WIP.

In our personal lives, we have the same problem as the CIA. The CIA has too many avenues of input. Too many distractions. And, oddly enough, too many experts. The only way they can solve their problems is through collaboration. The only way they can truly collaborate is to understand their own work and have the capacity for collaboration.

The CIA used to have a linear problem. One, two, three other countries that were potential threats. Now they have an exponential problem. Potential threats that can form, execute, and disband before anyone knows who they are or why they did it.

The CIA cannot solve their exponential problems with the linear problem solving solutions of the past. They cannot rely on solitary agents or even small groups. The organization as a whole needs to collaborate to remain effective.

When I was growing up, I could choose between 4 TV channels, the telephone and maybe a movie at the theater for incoming streaming media. Outside that, I could read a book, magazine, or newspaper. Or maybe I could listen to music on my stereo or Walkman.

At that time, we thought that was a pretty lengthy list. But it was a linear list. I could filter them out simply by walking away from them.

The other day during a lunch with a friend, my Android Phone buzzed non-stop with tweets, text messages, Facebook updates, Foursquare updates, phone calls, and emails. Finally, I shut it off. I had to apply “aggressive filtering” to my lunch. But that was not enough.

The number of distractions we have grows as the number of avenues for distractions grow. Not only that, but – like the CIA fearing more danger than is really there – even when the phone wasn’t vibrating, I was waiting for it to vibrate. Even when I shut the phone off, I could feel it was off and was vaguely worrying I was missing out on something. However, I was able to focus much more intently on my conversation.

When we limit our WIP, we are filtering our work. We are filtering distraction, filtering data sources, filtering complexity. But that is only a temporary solution. Just like if the CIA only focused on one hot-spot, they could focus, but they would be ignoring everything else. But their collaboration would mean nothing if there weren’t sub-groups actively focusing on specific tasks.

In this case, we want to limit our WIP so that we can focus in the service of becoming very aware of what we are doing, what we are not doing, and why. This lets us know, very well, what we know so we can begin to pool our resources and combine our skills. In our increasingly complex world, our role as individuals is changing. There’s too many things going on at once for any of us to take in, process, and act on.

When we limit our WIP, we are recognizing that we can either pay attention to some things with great effectiveness, or we can pay attention to many things with little effectiveness. If we choose the first path, we are creators, if we choose the second path, we are consumers.

Lastly, when we limit WIP and calm our own complexity, we are better able to find others to collaborate with, to add our unique value, and to create stronger teams. As we collaborate, we learn more about other disciplines and find ways to incorporate that learning our future work.

The word conjures up images of slothfulness, of days spent lazying about in a seaside hammock beneath the fronds of a blowing palm tree.

But relaxation is not necessarily sloth. Just because someone or something appears to not be fully utilized is not an indication of their disutility.

Consider the belts in your car’s engine. In order to operate effectively, they can’t be too tense, they must have some give. Engine optimization relies on belts having the appropriate amount of slack.

It’s the same with our work. We need slack for our own optimization. In our work, we’d like to have a degree of slack to:

1. Make sure we are able to focus on the tasks at hand;
2. Make sure we have the capacity to deal with unforeseen events;
3. Make sure we can stop periodically to allow our brains to perform vital functions in memory, processing, and regeneration; and especially to
4. Make sure we don’t work ourselves into an early grave.

When we have unlimited WIP, we tend to start multiple tasks concurrently, and then run in circles trying to complete them. As we’ve discussed in our previous posts in this series, overwork creates additional work, heightens stress, and results in a poor quality product.

Focus on Tasks at Hand

Slack allows us to focus on the tasks at hand simply by giving us the ability to work in a non-freaked, sans-OMFG state. In the absence of slack, we aren’t only working on our current task, we’re fretting because we know there are countless other tasks we’ve started and that they demand completion. We live with an underlying fear that something, somewhere will break and when it does, it’ll be unlikely we’ll be able to deal with it.

Slack is, in the end, a recognition that our time, our brainpower and our emotional fortitude are all limited. If we tax all these resources, we will not be able to do the work on our plate or deal with unforeseen events.

Unforeseen Events

When we’re overloaded with work, we invite panic. We invite emergencies. When we have zero capacity for new work, additional work exacerbates our overload. The thing is, unforeseen events are inevitable; they happen all the time. We can’t predict the future, we can only give ourselves the slack to deal with whatever may come our way – good or otherwise.

If we have three tasks in process and something unexpected comes along, we – at worst – have four tasks in flight. This is still a substantial number less than most people currently have.  This doesn’t make the unforeseen event a welcome one, but it does make it a manageable one.

Rest, Processing, and Catch-up

Francesco Cirillo’s simple yet profoundly powerful Pomodoro Technique invites us to use a timer set to 25 minutes during which we focus without distraction. The timer’s ring alerts us to rest. The ratio suggested is 25 minutes of work to 5 minutes of rest – and then repeat (taking an even longer break after 4 successive pomodori). This isn’t merely to let us have a “coffee break.” Our brains need recharge points.

The brain is not some easy going organ…it’s a resource hog.

When we’re working intently on something, our brain burns a lot of calories, uses a lot of water, and gets tired. Allowing periodic points of slack allows us to hydrate, grab a snack, and recharge.

Not only this, but the brain also works in three memory modes: short term, mid term, and long term. Having slack and taking breaks allows the brain to pause and write vital information from short to mid term memory. The more we overload ourselves with work, the more we forget.

Stayin’ Alive

As we can see, without incorporating slack into our work day, we end up taking on too much work, too much stress, and with too little down time. These factors decrease happiness and longevity. That’s not a good thing.

We limit our WIP specifically to achieve a comprehensible workload that allows us to complete, understand the costs of our choices, make better decisions, and react elegantly to life’s surprises.

With only two guiding principles – Visualize your work and Limit your WIP – much of Personal Kanban seems fairly straightforward. But it’s not as obvious as it seems, and there’s actually a lot going on under the hood.

Tons, actually. So let’s discuss.

We said in the previous post we want to limit our work-in-progress, our “WIP,” and set it within a reasonable limit. But there’s still some confusion about what WIP really addresses.

Does it mean:

A: At this very moment, what task am I actively doing with my hands?

or

B: At this very moment, what tasks am I am actually doing with my brain?

To be clear, your brain does more than your hands.

This goes back to the role of the visual control in your life. As a visual control, your Personal Kanban keeps you honest about the work being done in your head.  The visual control is not necessary there to track what’s going on in your hands.

So the Personal Kanban doesn’t need to tell you (A).

This comment was left on our latest post How to Set Your WIP Limit:

Interesting. My WIP limit on my personal kanban has always been 1. Perhaps it’s just the way I’ve got it set up. For instance, right now the card I have in work is “read blog posts and comment”.

Now, I have a ‘waiting’ lane for cards where I’m blocked from taking any direct action. So by having a different lane I suppose that’s an additional WIP item since it’s not complete, but I like to split that out if I can’t take any action on it myself at the moment. It re-enters my pull queue when the block has been resolved.

What do you think about that Jim? Can I do better?

-Josh

We’ve encountered numerous people who set their WIP limit to one and believe they are working on only one thing at a time. They will actually move cards in and out of DOING to note whether they are actively working on them. Again, what you are doing with your hands should tell you this.

However, those tasks that were moved back into WAITING are still active. They are still IN PROGRESS. Simply because your fingers aren’t moving them right now, doesn’t mean your brain is not still DOING them.

This is important, as the Zeigarnik Effect tells us two things about how we work:

1: We have a psychological need to complete a task. Incomplete tasks tend to create intrusive thoughts, causing us to dwell on what we’ve left unfinished.

2: We forget things that we’ve completed.

In the book and in our talks, we go into great detail about how this impacts our work. For now, let’s focus on #1.

When we begin a task and leave it unfinished, our brain keeps thinking about it. Psychologically we need closure, which can come from two sources – actual completion or officially deciding not to complete.

If we have a column in our Personal Kanban that is just holding incomplete tasks, there will be an irresistible temptation to put more and more tasks in that column. We will come up with excuses like, “This one is more important” or “I don’t have time for that right now,” or “I’ll get to it later.”

We want the DOING column to exert pressure on us. Our goal with Personal Kanban is to have a realistic WIP limit that is honestly displayed so that we can understand our options, better manage our work, and finish what we begin.

More on this in future posts in the Why Limit WIP Series.

A WIP Limit of 3 Makes Work Easy to Understand and Complete

In Personal Kanban we have only two rules. One of them is to limit your WIP.

That sounds simple enough. But what does limiting your WIP really imply?

This series describes what we mean by “WIP,” why it’s important to limit it, and – with all the competing demands on our time – how we can begin to go about doing just that.

WIP = Work-in-Progress

WIP is an acronym for “work-in-progress.” It’s the proverbial “stuff on your plate,” the “balls you are juggling.” It’s the work you’ve begun and currently have in process.

Now consider those things in your life that can and will at some point constitute your WIP:  deliverables you have at the office, improvement projects piling up at home, monthly bills that need tending to, doctors appointments that need scheduling, phone calls that need returning. Now take into account the things you enjoy doing (but that often get put on the back burner), like taking a photography class or working on your yoga practice. Things you both need and want to accomplish can add up to a huge number of tasks you have to hold in your head simultaneously.

Some of these tasks are fairly low-impact. Others are more challenging and might require additional attention.

We want to limit the number of active tasks we juggle because we have a “capacity” – a maximum amount of work we can process at a given time. We simply cannot do more work than we can handle.

What Happens When We Don’t Limit WIP

When we exceed the amount of work we can handle, it heightens our distraction and decreases our concentration.  Our attention to detail suffers, we leave things unfinished, or compromise the quality of our finished product.  All of these outcomes create more work or us in the future.

Forgetting

When we forget something – whether it entails leaving out important details or missing a deadline – invariably someone else will point out our misstep. When they do,  a conversation (most likely a pointed one) often ensues. Addressing and compensating for missteps takes time and effort, compounding cost, and ultimately frustration.

Leaving Things Unfinished

When we leave things incomplete we have two outcomes: (1) We never finish them or (2) We finish them later.

For case (1) it’s likely we’ve wasted time, effort, and resources.

In case (2) we return to the task at a later date, when the task’s context (its need, impact,  or resources available) might have changed. Oftentimes that requires looking at the task and figuring out exactly where we left off,  why we made the decisions we did, and what – exactly – was our preferred course to completion. This reorienting process of remembering and reorganizing likewise can consume time, and incur additional effort and resources.

Compromising Quality

A job poorly executed is sometimes worse than a job left incomplete. When work is done poorly, it usually contains defects. When defects become work multipliers, there are consequences down the line: defects can slow work down, break something else, or even hurt someone. Or they might just make your work product less helpful than it could have been had proper care been taken initially. If your defect is deemed serious enough to require repair (in essence, doing your work over again), first that defect must be discovered, then appreciated, then discussed, then deemed worthy of repair, then the repair needs to be identified, then acted upon.

And those are the easy ones.

When we compromise the quality of our work, we don’t just “do a bad job,” we leave someone to clean up an expensive and time consuming mess.

What Happens When We Do Limit WIP

We’d like to say that limiting WIP will solve all these problems, but it won’t. Nothing makes these things go away entirely.

However, not limiting WIP means we are pretty much guaranteed to fall victim to these time wasters, and we are guaranteed to do it often.

When we limit our WIP, we have less distractions. We are able to focus on correct decisions, completion, and quality.

When we set a WIP limit, we are telling ourselves and the world around us that we want to get work done quickly, and we want to do a quality job.

Even though prioritizing some tasks over others means some tasks have to wait, those tasks will still be completed sooner than they would have if we started them all right away. Since we are no longer paying the penalties for forgetting, incompletion, or poor quality, the work we finish is done faster and does not cause additional work.

What’s Next

This is just the tip of the iceberg as to why we should limit WIP. Over the upcoming months, we will be releasing more benefits to both Limiting Your WIP and Visualizing Your Work.

Until then, there are other related resources on this site. Simply check out articles tagged “WIP,” or visit the PK 101 page.

That was step one.

Step two is visualizing that FIP. Jessica was concerned because her triathlon regimen included both repetitive and non-repetitive tasks. She needed to consume the right amount of calories, be sure to take her meds, and of course work out. This would equate to three repetitive, monotonous tickets per day in Ready –> Doing –> Done.

Many tickets. Too little real information.

Getting the work done for the triathlon was of course, important, but Personal Kanban is built to be an information radiator. What was the real information she needed?  This turned out to be:

1. what workouts did I do
2. when did I do them
3. did my caloric intake match the workouts
4. did I take my meds and, most important
5. am I being consistent or missing anything?

So here we see Jessica’s board. She just had a little white board, so we worked with the walls in her home. Backlog and Done are both off the board (on the walls where the board hung). Her spontaneous tasks still work through a Ready –> Doing –> Done value stream, those tasks were color coded between work, family, studying and other tasks.  But there’s more here than that.

There are two additional “swim lanes” on this board. A swim lane is another value stream or dedicated horizontal lane on our board for special tasks.

The first swim lane is Triathlon Training. We have several metrics here:

Diet: each day net calories, water, and meds are measured. Calories are a number, meds and water are a checkmark for done.

Workout: Type, severity, and subjective well being are noted here. “20” is a 20 minute cardio. On Wednesday you can see “10 mile ride.” E,M,H are easy, medium and hard workouts. Smilies measure how Jessica subjectively felt about the workout.

She can then take these metrics and not only see adherence and progress, but also plan for future workouts.

The second swim lane is Jessica Studying for her Section 65 Certification. She told me that she studies by creating a study plan for herself, studying, and then testing herself on what she just did. So we set up a swim lane with a WIP of one. At any point, she can only be working on one module.

So with this, we took Jessica’s overwhelming combination of things in progress and goals and made them visible and actionable. Take the time to critically look at the different projects you have in flight. In the end, you want to get the work done, but your real aim is to understand what you’re doing. To get those projects done right, Jessica needed some dedicated swim lanes.

I’m willing to bet she’s not alone.

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.

A basic Personal Kanban on the iPhone or iPod Touch

You asked for it, and we listened. Today we are proud to announce the launch of the first Personal Kanban iPhone app, iKan.

When we set out to build it, we decided to focus on a few key things:

1. Small Screen Many Tasks -  We wanted to make the best use of the screen real estate on the iPhone, so we built the app vertically.

2. KISS - We wanted the initial release to be extremely basic. In future updates we will respond to YOUR needs, and additional features will be based on YOUR input. So please keep us posted as to the direction you’d like to see iKan take. We already have a long list of upgrades in our pipeline, but are primarily interested in how you are actually using the app.

3. Use Your Data - In the first version, we have   had importation from Zen.  (Zen, unfortunately, never let you write data back from the API. In one of their updates, the import also ceased to function.).

4. Start with Basics then Build to Suit - Each iKan starts with an entry-level Personal Kanban value stream with Ready / Doing / Done sections. You can however, create your own column headings and set your own WIP limits.

In the coming weeks, we’ll have a series of short tutorial videos for iKan – so stay tuned!

Special thanks to Jeremy Lightsmith, Gary Bernhardt and Corey Ladas who were all vital in making iKan a reality.

Get your copy of iKan at the iTunes Store.

NOTE: If you want to help create an Android app, talk to us!

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

You can tame what seems difficult

Your backlog is bigger than it should be and it needs to be managed. Everyday people tell us how they are overwhelmed by their backlog, and cannot possibly manage it within a Personal Kanban because it could contain hundreds or thousands of tasks.

Let’s examine this.

On Stephen Smith’s blog, he describes using Personal Kanban to visualize his workflow with his file-card system. Leslie Dewar left this comment:

I have tried this system of cards in the past and found it extremely distracting and demotivating. I was working with a very intensely personal client base of about 280 people and there were dozens of small jobs that probably really needed to be in a tickler file. If I put them all on a “Task” list, it was quite overwhelming, even though some of the work only needed ten or fifteen minutes.

I also suffer from the “out of sight – out of mind” disability. I have gone through many office an office blitz; prioritised; put in folders; sequenced in desktop folders and ……. forgot about it. By the time I do all that organizing, I somehow felt as though I must have also done the job!

Leslie’s issues are not unique. I’m seeing two in particular here. The first is tracking tasks over time (tasks that aren’t relevant for a while clutter up your Personal Kanban and make it hard to read), and the second is Personal Portfolio Management.

Tracking Tasks Over Time

There are things we do every day that are repeating or scheduled out into the future. We need to remember these things and add them to the Personal Kanban when necessary. Products like Outlook or Google Calendar can help here. Simply place automated reminders (what GTD calls “ticklers”) in your calendar at the earliest date you’ll need to be reminded of them. The due date isn’t going to help you – calls to action will. One of the biggest mistakes people make with calendars is that they record the date something will happen rather than recording the earliest date action will be necessary.

Then forget about that thing until the tickler comes up.

Personal Portfolio Management

I have the feeling this is going to become a major theme for Personal Kanban. Everyone has multiple projects. Those projects have features and those actions have specific tasks. Defined:

• Project – a large thing of value that needs to be done – Build Deck
• Features – units of value that, when combined, create the project – Railings
• Tasks – discrete actions that create features – cut 16 posts to 3’5”

We can use Personal Kanban to manage our work at all three levels. Depending on how many projects we have, a project can simply be denoted by the color of the sticky note. Features can be tracked on the Personal Kanban until we start in on the feature – then we can decide how best to break it down.

If the Project is “Make Breakfast,” that probably stands on its own. You won’t need the features (like Toast) or the Tasks (slice bread, place bread in toaster, depress toaster button, double check toast setting to make sure it’s on golden brown, stare at toaster for what seems like an eternity…).

Part of what makes life challenging is that personal work does come in Projects like “Build House” and “Make Coffee.”  Combined, these projects comprise our Personal Portfolio.

Since one of the goals of Personal Kanban is to simplify your life – creating a huge, mandatory system of nested Personal Kanban or secondary tools doesn’t make sense (for everyone).

So What Do I Do With This Wisdom?

Understand that your body of work is a Portfolio. Your Personal Kanban goal is to manage that portfolio in the way that works best for you. If your Personal Kanban is overloaded with tasks, find ways to group them into Features or Projects until it comes time to actually do the work. If you have too many things in the future, remind yourself with an automated calendar.

If you are like Leslie and have 208 clients, manage them in a Customer Relationship Management system. And, if you get to the point where you can’t manage your work at all – you are taking on too much. That’s the point where you go to Odesk and get an outsourced Personal Assistant.  (And manage them with an on-line Personal Kanban!)

Photo by Sea Turtle