We've covered agile fundamentals, MVPs, waterfall vs agile, and product ownership. Now let's talk about something that affects all of us: why work takes longer than it should.
Making Work Visible by Dominica DeGrandis is published by IT Revolution Press. If you see a book from IT Revolution, it's worth paying attention to - they consistently publish material that actually helps technology teams succeed.
This book exposes what DeGrandis calls the five thieves of time - the things that steal our capacity without us realising it.
Let me show you how each of these has shown up in my work.
This happens in cycles with every dev team I've worked with.
Things get blocked. We start other work whilst blocked. Then something else happens and the board is a mess. Everything's in progress, nothing's finishing.
The phrase I use is "can't see the woods for the trees."
The solution: whiteboard session. List everything out, rank them in order. Some things can be ticked off quickly - they felt daunting but were just taking up mental capacity. Some get pushed back. Some get divided up. The can sometimes be a pretty long session but working things throuh and ranking them really helps.
This happens when ticket discipline slips. Stop documenting work, start context switching without thinking about it. The board fills up, everything slows down.
Then we clear it, get focused, things speed up. Until the next cycle.
The cycles happen less frequently now. Getting better at recognising the pattern earlier.
This has happened constantly in the current ERP migration.
Migrating functionality that hasn't been touched for years. Think I understand what needs to happen. Then discover an endpoint doesn't exist. Or the data structure isn't what I thought. Or there's a dependency on a system I didn't know was involved.
These aren't failures - they're learning. But they slow things down when unexpected.
The more experience with the system, the better at anticipating dependencies. But surprises still happen regularly.
Wherever I've worked, there have been integrations or applications that are fragile and kick out live support issues.
The more experience I get, the more these systems move higher up my priority list. Fix them properly or replace them, because the unplanned work they generate eats capacity.
Then there are last-minute priorities. Every month, something urgent surfaces. I try to mitigate this by talking to people about their roadmaps, understanding what's coming. But surprises still happen.
Unplanned work isn't going away. The best you can do is expect it and plan capacity for it.
I am a major cause of conflicting priorities.
I get excited about something new. Work out specs or user stories, often with AI assistance which makes this faster. Then talk about them enthusiastically.
This creates confusion about what's actually being prioritised.
It's compounded by genuine new priorities that shift the landscape. But a lot of it is me chasing shiny objects and not being disciplined about saying "not now."
The hardest word in software development is "no." The second hardest is "not now."
I'm getting better at both. But I still cause this problem more than I should.
I've been in multiple businesses who went through the miserable job of moving from SQL Server 11 or 12 to 15 or 16. Not a pleasant upgrade path.
The problem is always the same: the upgrade was deferred. "Next quarter." "After this project." "When we have time."
Then the old version is out of support, or a security vulnerability surfaces, or a new system requires a newer SQL version. Now you're forced to upgrade with a painful path ahead - compatibility issues, deprecated features, application changes.
If it had been upgraded incrementally, it would have been manageable. Instead, it becomes a major project that disrupts everything.
Neglected work doesn't go away. It accumulates and comes back at the worst time.
You're on a boat (your system) and it's hit by a sea monster (the root cause). The sea monster puts a hole in the boat. Water is coming in (the symptoms - errors, support tickets, problems).
You have three options:
Which option is right depends on:
Applied to unplanned work: block time for it (grab a bucket), fix errors at the source where you can (patch the boat), and give users tools to fix issues themselves or eliminate the root cause (deal with the sea monster).
The goal isn't to eliminate unplanned work - you can't. But you can reduce it and plan capacity for what remains.
The core insight of the book is right there in the title: make work visible.
Use boards, cards, lists - whatever works. But make sure you can see:
You can't manage what you can't see. And you can't see work that lives in email threads, Teams messages, and people's heads.
I still lose ticket discipline and let WIP build up until I can't see the woods for the trees. Still get surprised by dependencies. Still chase shiny objects and create conflicting priorities.
But I'm getting better at recognising the patterns. The whiteboard sessions happen sooner. I expect dependencies now and build learning time into projects. I plan capacity for unplanned work instead of pretending it won't happen.
The thieves are still there. But at least I can see them now.
Read the book: Making Work Visible: Exposing Time Theft to Optimize Work & Flow by Dominica DeGrandis (IT Revolution Press)
Watch the video (47 minutes, if you want to go deeper): https://www.youtube.com/watch?v=GhzEHlILSo8