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