You know what one of the biggest problems with knowledge work is? It’s mostly invisible. We can talk about it, but we can’t see it. You can’t see the stuff you want to create (except perhaps in your own head, which really doesn’t count) and perhaps most importantly you can’t see the stuff that is missing.
It gets worse the more people you add to the equation. That’s right, go to a planning meeting and you will find a long list of things that the team thinks they want to do (struggling to make the work visible), but I can almost guarantee you there is no list of what is missing. Why not? Because we can’t see it. It’s hard enough to see the work – that’s tough enough to begin with, but you can just forget about seeing the delay that is associated with that work.
I was reading Reinertson’s book on Product Development Flow the other day and within a couple of pages, it hit me: we can’t see what the hell we are trying to do – and that makes knowledge work really hard. We are like blind men trying to describe the proverbial elephant. If I were assembling a bicycle, I would be able to see all the parts before I put them together. I might even have some sort of inventory list to check against. I can physically see and verify the parts and the work that needs to be done. Compared to knowledge work, this physical assembly is worlds easier to estimate and accomplish – simply because we can see it.
OK, to you this may be a big, “Duh!” moment. Fair enough. But here is where I realize that we may often have a problem. What is the output of a planning meeting? Some user stories, some tasks, maybe a few follow up questions? Perhaps a calendar or timeline of some sort? How often do you see a list of all the risks or potential delays that need to be addressed as an output of a planning meeting? Yeah, never.
You see any process can be broken down into work and delay. This is the foundation for value streams. The thing is, you can’t have one and not the other. There is always delay in any system, no matter how efficient it is. But delay is one of the most neglected things we plan for. Honestly, most of the time we don’t plan for it. We plan the work and choose to ignore the delay. This is like talking about the work, but not acknowledging the impediments to the work. You can’t have one without the other.
So why in the world would you NOT plan for delay? Planning for it is simply acknowledging that it’s real. Well, I would submit that part of the reason that delay doesn’t get more consideration is because it’s invisible. It’s very hard for us to see and visualize. Let’s face it, human beings perception of time is a total mess. We suck at assessing duration, so why would we be any good at assessing delay?
On agile teams we have evolved mechanisms to make the work visible: Story boards, Kanban boards, & Story maps, are just some of the techniques that have evolved to make work visible to us. We need similar mechanisms to make delay, impediments and other forms of waste visible too. Once we do that, we will have a more realistic vision of the work we are trying to do.