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

What Are Your Task Types?

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

Inventory Makes Work

Lean talks a lot about inventory. A major tenet of Lean is to reduce inventory. Companies that stock up on too much stuff have to maintain that stuff, manage it, and then deal with it when it is no longer useful. This is why companies end up having huge sales at the end of the year - they've amassed warehouses of stock (or their suppliers have) and now that merchandise needs to be sold fast.

Inventory lowers organizational effectiveness because the time and money spent taking care of the inventory could have been spent making the company more successful. Therefore, Lean organizations tend to receive the things they need to operate at the last responsible moment, this is called "Just in Time" (JIT). A JIT organization does not take on inventory until the moment they need it and therefore spends as little as possible maintaining inventory, greatly reducing the risk of having overstock.But inventory isn't just "stuff." Inventory for us as individuals includes anything we have that requires maintenance or on-going attention. We have responsibilities, they aren't going away. We will have a yard, it will need to be mowed. Dishes need to be washed. Children need to be raised.Other inventory comes in the form of stress. Stress, I would argue, is inventory. Your brain is like a factory, you take in information, you create value. Stress slows your factory down.I've written about "Existential Overhead." Stress is a big part of that overhead and it is totally inventory. The question is, how much of our stress do we manufacture ourselves? Certainly there is stress that comes from outside our control. Illness in the family, natural disasters, economic crises - we can't do much to stave these off.There's other overhead we create for ourselves. Lean teaches us to save action until the last responsible minute, but procrastination teaches us to ignore action until someone yells at us. Procrastination is not responsible. The more you procrastinate, the more you know someone is going to yell at you. So, even when you are doing something else, you are fretting about what you aren't doing and that lowers your productivity.Focus for you as an individual comes from an understanding of what you are doing and why. Existential Overhead, inventory, stress all combine to make you question what you are doing and why. That muddies your understanding, you lose focus, and your effectiveness decreases.The biggest problem here: if you stress about things that can be relieved, when big problems come along, your capacity to absorb that extra stress is reduced. And if the new big problem is too big, you lose your cookies. But all we needed to do to keep our cool and rise to the occasion was some work up-front to relieve those previous stressers.I invite you to look at what is going on in your life, identify stressers and other inventory that you 

know

routinely keep you awake at night, and start to figure out ways to mitigate them or even remove them from your life. Especially look for stress you are manufacturing yourself.

The Retrospective Column

JimBenson_01 Mar. 08 13.28

When we make our work and our process explicit, and we do retrospectives, it makes sense to have a retrospective column in our Personal Kanban. The thought here is fairly simple: at the beginning of each day move tasks from Complete into Retrospective. Then, at the end of the week (or whenever you wish) take a look at the tasks in the Retrospective column. They will remind you what you did over the retrospective period.

This is also handy if you need to do your timesheets every week and want to actually remember what you accomplished.