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