Books for software engineers and managers

Making Work Visible

Making Work Visible

Exposing Time Theft to Optimize Work &  Flow

by Dominica DeGrandis

Engineering Manager,
Tech Lead,
Star Engineer,
Product Manager,

How strongly do I recommend Making Work Visible?
9 / 10

Review of Making Work Visible

I highly recommend Making Wok Visible for everyone involved in software development.

This book covers two major things: the issues underlying poor software delivery and how to use kanban boards to improve the situation.

Making Work Visible is a great introduction to topics like utilization, WIP reduction, and unplanned work. Read this book, enjoy it, then move on to more detailed descriptions in Slack, The Phoenix Project, and Accelerate.

The 5 time thieves are WIP, unknown dependencies, unplanned work, conflicting priorities, and neglected  work

Throughout Making Work Visible, the author highlights the five time thieves and their connections. For instance, that high WIP makes us incapable of addressing incoming requests which creates unplanned work.

This high level framing feels like a good conversation starter for engineering managers and their tech leads.

Two-thirds of people are visual-spacial learners and making work visible is one of the easiest ways to improve software  delivery

On an automotive assembly line, we can visually see work in progress.

Software does not share this advantage. Our work often feels invisible.

Kanban boards exist to increase visibility of WIP, surfacing problems that would otherwise go unnoticed and therefore unknown and unaddressed.

Start with simple kanban boards displaying To Do, Doing, and Done because more advanced requirements will become self-evident as usage  increases

Kanban boards do not require complexity. In fact, simplicity is preferred especially when starting because complex boards will decrease adoption.

Making Work Visible offers plenty of tangible examples and diagrams for kanban boards ranging from simple to complex, highlighting various ways of organizing the information depending on the problem identified and being addressed.

Project teams are often measured with vanity metrics where product teams are measured by business value  delivered

Organizing teams around projects can feel rewarding because the goal is on completion, but organizing teams around products will deliver more value.

Where project teams will focus on completing project tasks, product teams will study the problem more deeply and focus on delivering business value.

Improve standups by focusing on the work - blockages, risks, and hidden WIP - not the  people

Most standups include each person reporting their status and blockers.

A better approach is to focus on the work itself. Which work is blocked? Which work is at risk? Which work is unaccounted for?

Circling the team around a kanban board can help focus the conversation on the work itself. It’s also important to note that your kanban boards should not contain swimlanes per person because doing so creates perverse incentives hindering collaboration.

Like OKRs, kanban boards should exist at each level of the business and cascade  down

You can and should have multiple kanban boards. For instance, your kanban boards may exist at these levels:

  1. Company
  2. Department
  3. Team

Like OKRs, the cascading nature of kanban boards can help tie the work of individual contributors to company strategy.

Don’t spend too much time on backlog prioritization because priorities change by the time work  starts

My team uses a Top 10 list and the author suggests a Top 5 list to control what enters Doing / WIP next. Focus on prioritizing that list and what enters it, but don’t worry about the voluminous backlog behind it.

Beyond 80% utilization, work queues increase exponentially making us incapable of reacting with agility to emerging  requests

Rumor is that companies with 20% time keep it not for innovation or creativity, although that is the stated purpose, but rather for flexibility in addressing unexpected work. This keeps their organization running smoothly, whereas companies with 100% utilization get thrown into a snowballing world of WIP causing unplanned work and excessive lead times.

Software executives want less risk and more  predictability

When both the author and I talk with executives, we repeatedly hear about the desire for reduced risk and predictability.

That’s why in the growth framework I’ve used for engineers and managers, we have a competency area called Reliable Delivery which focuses on predictability.

Making Work Visible