Making Work Visible: Exposing Time Theft to Optimize Work & Flow
Making Work Visible: Exposing Time Theft to Optimize Work & Flow
A Book Review
If you are like me, so much of the work you do, and the work your team does, is invisible to most outside observers. You may understand what you’re working on, and your team likely understands it as well. But as soon as you move outside of the inner circle, the work becomes opaque. Move further away, it becomes a black box that outsiders peer into, but can’t discern what is happening.
This is often the source of immense conflict and consternation.
For product managers, work can pile up faster and faster. We can become the bottleneck since we have difficulty saying “no” for ourselves and want to take on tasks that enable our teams to do more.
For product teams, we often have the visible work of new features to create or bugs to fix. But those are often small parts of much more work that is difficult to quantify or track. All the small requests from other teams, from product managers, from engineering managers, from other departments get added to the mental queue without being added to the visible queue. And all these things take time.
For stakeholders who want to know when features will be done or bugs will be fixed or items will be delivered, the full context is often missing. While it may seem like there is only one or two features on the list, or one or two bugs, that rarely takes into account the full list with all the requests and context switching and meetings.
That is the world we find ourselves in. A world where time thieves are rampant and often hidden. A world where we all have too much to do, too many things to do at once, too many conflicting priorities, and too many dependencies.
If you find yourself dealing with the same issues as I just described (and I believe you probably do), then this month’s book is probably a good one for you.
Making Work Visible: Exposing Time Theft to Optimize Work & Flow by Dominica DeGrandis explores the problems of invisible work.
As you may be able to tell from the cover, this book is about making work visible through the use of Kanban principles.
Many of you may have used Kanban in the past or may use it now. I’ve used it extensively in my work in various teams, along with scrum, scrumban, and a few other Lean approaches. And while I thought that I was fairly well-versed in Kanban, I found a number of ideas coming to mind as I read this book. It addressed issues I’ve had in the past, issues I’m facing currently, and probably others I’ll see in the future.
So I was pleasantly surprised overall. Making Work Visible is a short read, but with plenty of good takeaways for work and projects.
Let’s dive in.
Key Takeaways
Make Work Visible
The author is a proponent for Kanban, which is a Lean work methodology that helps visualize work. Most of us are probably familiar with Kanban boards—To Do, Doing, Done—or some variation on that. These are often at the heart of Kanban. They make the work visible. Everyone can see what work is on the board and where it is.
The idea is simple in theory, but often harder in reality. As I described before, how much of our work is often left off of our boards? For those of us who work in Jira for example, how often do small things get left out? How often do our product teams work on something only to go back and add it to the board or to Jira after it’s all done just to reflect the work?
This isn’t about collecting story points (as too often happens) or making the reports correct (which may or may not be helpful), but about showing the work. Making it easy to see what is happening for everyone involved. If you’re the lead engineer, you obviously know what you’re working on. But no one else does! You can mention it to everyone, but if it’s not visible, it is easy to lose amid all the other work that everyone is doing.
That is why this book drives the point home about making work visible. It is one of the most important things we can do for ourselves and our teams.
I realized that there are many ways I can make work more visible as well. As part of my own work, I’ve started to create Kanban boards for my own deliverables, outside of the engineering team so that I can give transparency into what I’m working on and where it is. I’ve also created several personal project boards in Trello (a great Kanban tool) to track home and other projects. I’ve had these kicking around in various forms, but realized that the best way would be to create a Kanban board rather than my lists so I can more easily manage them.
For our product teams, I’ve also been working on ways to make our work more visible with better swimlanes, as DeGrandis discusses in the book. With specific swimlanes on our Kanban boards for specific areas of work, we’re better able to visualize the work we are focused on and track it apart from other pieces of work.
By making work more visible, and more easily visualized, we can start to track it better and understand it better.
Make Time Thieves Visible
In a similar vein, Making Work Visible suggests that we also make the time thieves visible.
The book calls out five specific time thieves:
Too much work in progress (WIP)
Unknown dependencies
Unplanned work
Conflicting priorities
Neglected work
First off, I feel very seen with these time thieves. Hopefully I’m not the only one.
But in order to neutralize these time thieves, we have to make them visible, just like the work we were discussing previously.
These time thieves can creep into our teams and our work at any time.
Just this past week, we were dealing with a myriad of issues with cross-team dependencies that brought our team to a halt. Which left me figuring out how to make those dependencies more visible for us and for the other teams (and eventually eliminate them, but if we can make them visible for now, that will be a win).
As product people, we also deal frequently with conflicting priorities. The book suggests a number of prioritization methods. I don’t care for any of the methods listed in the book (especially the Scaled Agile stuff). But fortunately for you, dear reader, I’ve written about prioritization previously:
The book suggests WIP is the ringleader of the other thieves. That most of our troubles stem from having too much work in progress at any time. Which leads us to the final takeaway.
Limit Work in Progress
One of the main purposes of Kanban is to limit work in progress. And the book emphasizes this repeatedly.
Most Kanban tools allow us to set limits on WIP. Only a certain number of stories or tasks or issues at one time. Even if we can’t do it in the tool, though, we can adopt rules that limit how much work in progress we have.
The point of limiting our work in progress is to allow us to focus on the most important items (prioritization), see them through to completion (focus), and allow slack in the system (speed) so we can actually get work done. If we focus on maxing out capacity by putting too much work in progress, then we lose our prioritization, our focus, and our speed. We introduce context switching and remove any slack in the system.
The author discusses the problem with removing slack and queueing theory, which is a fascinating topic. We won’t go into it too much here, but as capacity becomes more and more occupied (80% to 90% to 95%), our wait times begin to increase exponentially. Slack in our systems, whether on our product teams or in the DMV line, allow us to move things more quickly. Take that away and things grind to a halt.
Final Thoughts
Making Work Visible: Exposing Time Theft to Optimize Work & Flow by Dominica DeGrandis also explores a number of other topics, which I don’t get a chance to dive into. But if any of these ideas whet your appetite, I’d suggest you grab a copy. It’s a short read and will likely spark a number of ideas on how you can improve your own flow and make your work more visible.
I was pleasantly surprised by this read. It came at a pretty opportune time as well. Many of the topics the author discussed are very pertinent to what I’m working on and applicable to my work, both in the virtual office and at home.
I’m a fan of Kanban, and have switched between it and scrum several times on various teams professionally. Frankly, most teams I know use a form of Kanban, whether or not they want to call it scrum. So being familiar with Kanban and the principles is good for everyone. And making work more visible is one of the most important things we can all do.