Making Work Visible – Part 3

This week we talked about the last thief of time (neglected work) and exposing time theft using a kanban board.


Thief of Time: Neglected Work

  • Zombie projects (not dead, but not getting attention either) are like old servers. The person who set it up leaves, then someone else comes along to maintain it for a while, then you end up turning it off to see if it’s really needed. Before turning something off, reach out to see what’s up.
  • Why neglected work happens…
    • You’re waiting on feedback.
    • The work is important but not urgent.
  • Entropy increases over time, meaning neglected work rots.
  • If it hurts, do it more often. (We saw this in The Phoenix Project as well with deployments.)
  • The easy path is to chase revenue-generating work, like features. What about revenue-protection work like technical debt? (This was Houston’s favorite part of the chapter because it gives merit to technical debt work.)
  • On that note, how do you put a number on technical debt (e.g., how much this will cost us later)? Taken another step further, how do you justify a QC engineer’s salary without treating them like a cost center?
  • Which thief — too much WIP, unknown dependencies, unplanned work, conflicting priorities, neglected work — is the most concerning?
    • Each company has it’s own worst thief, and the type of thief can change over time (e.g., unknown dependencies could improve as you get to understand your work better).
    • Houston: Unknown dependencies caused by unknown unknowns
    • Geoff: Unplanned work caused by not knowing what we need to do next
    • Jameson: Unplanned work where heroes work late hours to fix problems

Optimize Flow: Make Work Visible

  • A kanban board makes the work visual. It should be easy on the eyes, accurate, meaningful, and efficient at a glance.
  • How many managers look at these boards? In Geoff’s current case, the board shows tasks not stories, so the work is too granular to get a sense of what’s done other than the number of cards in each column or via a burndown chart. Some ideas…
    • The board may not be showing what’s useful
    • A manager may not know how to best use it
    • Someone prefers a personal touch (i.e., talking to an individual) to get more detail
    • The comments on a task/story may take too long to stitch together
  • You have to pick what gets visible. What causes your team the most pain? Take outputs from retrospectives and turn them into stories to work.
  • Track work if…
    • There’s only one person that can do it (unknown dependency thief)
    • It impacts other teams (unknown dependency thief)
    • It’s easy to get overrun with lots of small tasks (too much WIP thief)
  • What prevents you from getting work done? What randomizes your day? What causes pain? How many times does someone walk up to you to ask something of you? Formalize this to make it visible. (This happened in The Phoenix Project with the change management system they implemented using physical cards.)
  • Getting internal buy-in to truly address problems is more difficult than with customers because it’s easier to have a barrier between you and your customers, and you may not interact with them as frequently as you do with coworkers.
  • Start with a simple system — basic cards, to do, doing, done — then add as needed.
  • This chapter has some exercises you can do with your team, which can be useful for understanding what’s really going on, and for going from no process to some process.
    • Where are the demands on the team?
    • What categories of work do you have?
    • How would you design your kanban cards?
    • What’s your workflow?