Avoiding WIP Creep
Recently, I had described how I arranged my work tracking to deal with high amounts of WIP, or rather, after hitting rock bottom with WIP.
But how did that happen? I’m normally good with prioritisation. I could admittedly improve my delegation skills, but feel there’s a good balance. WIP just seemed to accumulate over time. At some point, this WIP creep became too much. What led to the accumulation, though?
I believe it’s ultimately dependencies, combined with an inability to fully cover each WIP item. Let me explain.
A pattern that I observed is this. I start looking into some matter, accepting it as a WIP item. At some point, I need input or a contribution from someone else - there’s a dependency. In some cases, I can drive the item forward by doing as much as possible of the contribution I need myself. In cases where that’s not possible (due to expertise, knowledge, authority, or whatever), I’m unable to continue. The dependency stalls for as long as it takes to obtain the required input.
If I’m disciplined and have a WIP limit, that means that, at some point, I’ll start idling because I have stalled dependencies on a majority of (or all) WIP items. So my natural tendency to get stuff done kicks in, and I accept new WIP items. Loop back to above, and there’s the downward spiral.
No one’s to blame - we’re all busy and have many things to do. Not all dependencies can be resolved immediately. So the next question is: how to avoid WIP creep, and what to do instead of idling and accepting more WIP?
Let it be clear - accepting more WIP that comes as requests is often inevitable (at least for me). The role demands paying attention to many things. (There is something to be said about how to bring down the number of things to actively pay attention to.) What seems to be more relevant is that allowing things to rest and waiting for them to move creates the false impression of more time being available. This is the “void” that new WIP eagerly fills.
So what can be done instead of waiting? Taking action, of course. That piece of input I’m expecting someone to deliver: can I get that myself by doing some research (and learn something new along the way)? The piece of work I think I need someone else to do: can I do that myself (and take some of the load off of that other person)? Possibly even more so than mentioned above - in other words, by doing more than possible?
Bottom line: if I have a task I want or need to advance, I should own the responsibility for advancing it.
There are lines that can’t be crossed. If I’m waiting for an expense approval for my latest business trip, I can’t just approve my own expenses to keep it moving. If advancing a certain task involves significant amounts of coding, I really shouldn’t do that because it’s not what I’m here for (and I wouldn’t expect an engineer to do, say, hiring manager interviews - that’s not what the engineer is here for). And so forth. But roughly speaking, if the next thing that needs to happen is well within my remit and abilities, why don’t I do it?
This idea is, essentially, the same as what's usually named internal open source (or a variation thereon). If I’m in charge of delivering some outcome, I should pretty darn well be on top of that progress, and be ready to do what’s necessary. Within boundaries, but those shouldn’t be too narrow.
The internal open source model is essentially all about collaborating to manage and resolve dependencies. Again, collaboration and dependencies: these are the two key things. The mechanisms explained in the iOSS V2MOM apply to the context of software engineering. Abstracting away from that context, the key idea is really to empower dependents to be proactive partners in a collaboration instead of increasingly impatient recipients of a service.
That’s it, that’s the thing.
(Note: The iOSS V2MOM was originally written by several folks at eBay. While I was driving that effort, the credit isn't all mine. Sadly, I do not recall the names of many individuals who contributed at the time, but hat tip to Mitch!)
Tags: work