Uncharted Waters

Jan 29 2018   9:52AM GMT

Never be blocked. Ever.

Matt Heusser Matt Heusser Profile: Matt Heusser

Tags:
blocked
Lean
requirements

blockerEarly in my career, I worked at a company where everyone was assigned multiple projects. Each status meeting was an exercise in explaining why nothing got done but it wasn’t your fault because you were blocked.

The programmer needed access to the version control system, so he was blocked. The IT person needed to set up a new server, so she was blocked waiting for approval from purchasing. Purchasing, if they were even in the room, would explain they were blocked on management approval.

This might have been okay, as the staff had other projects to work on … except those were all blocked as well. A “good” project manager could work as a sort of expediter, haranguing people to get the work unblocked until they give up and do it. Of course, while they did that un-blocking, some other PM would be blocked, which led to the “best” Project Managers being those with the best people skills. Hopefully they were on the most important projects. Sometimes they even were.

While extreme, this problem still exists on many teams in a much smaller way. Team A is waiting for the API from Team B, which needs to get the function signature approved by Architecture, who are waiting for more clear requirements so they can make sure the API is extensible — or in a hundred smaller ways.

Here’s what to do about it.

Never Be Blocked

Assume, for a moment, that your work is blocked in some way on requirements. You don’t know what it should do. So you wait, perhaps picking up some other piece of work, that may become blocked as well. Eventually you are working on four pieces of work at the same time, unable to really focus on anything. That kind of work is also not fun.

What if you never allowed yourself to be blocked?

Don’t have requirements? Make them up.

Need UX feedback? Proceed without it.

I know, that’s crazy. It could never work.

Except something amazing could happen.

Doing Speculative Work

Guessing instead of being blockedIf you take a guess at a feature that is not defined well, there is a good chance you will guess right. Let’s say that’s about 30%. There’s another chance that you will guess mostly-right, and the story will only need a few tweaks that require, say, an extra 10% of work, making your progress about 90% effective. The third option is that once the analyst sees the work, they say “well that’s not right”, but they could never have come to that conclusion without seeing a working system – if you’d waited and become unblocked to do it “right”, then you still would have had rework. The final choice, about 10% of the time, is that the work is wrong, wrong, wrong and needs to be done over.

Do the math on that and you’ll find speculative work is about 87% effective toward forward progress. Of course, I just made those numbers up, but you can substitute your own.

Am I saying to skip the part where we figure out what to build, and just jump into coding? Certainly not! However, once you’ve done a reasonable job to ensure first-time quality, injecting wait periods and multitasking generally slows you down. This includes reviews, requirements, and waiting to hand off to a tester. Either embed the tester in a dev/tester pair or work with two developers, with one playing mostly-tester and the other mostly-programmer. For a great exercise that allows you to measure the damage of multi-tasking, get a copy of Jim Benson’s book Why Limit WIP: We Are Drowning In Work.

Benson suggests fixing it by limiting Work In Progress, or WIP. If you’re blocked on all three things, he would rather have you sit and do nothing than pull in a fourth. (Realistically, that might mean helping a peer or doing research.)

My suggestion is to never be blocked. In practice, you might need information some key expert has about a framework, or wait for twenty minutes for a virtual machine to export/import to amazon/boot up. You might take on a second task – but I would like to see a retrospective discussion on why we started work before we knew how to do the work.

In order to make “never be blocked” an effective policy, the people doing the work need to know everything they need to know about the feature – from UX to code to test and deploy. That is one of the reasons I like pairing so much; the two together are much less likely to end up spending a morning staring confused at google search results that just don’t quite get them there.

Once we’ve achieved never be blocked, once the work team has all it needs to deliver a feature, we can start to approach one piece flow, also know as single piece flow or continuous flow.

If you’ve noticed that “continuous” has suddenly taken on more importance in IT, you’re paying attention. Before we can get to a meaningful adoption of all those “continuous” buzzwords, though, how often are you blocked?

That much, eh?

Sounds like we’ve all got work to do.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: