Anyone with an software engineering background knows that every programmer has a long list of things they want to work on when they finally have time. Create some useful editor extension. Implement that new algorithm. Refactor that code the way it really should have been done (as if you could have known that at the start). Play around with the new IDE. Learn the new APIs for some interesting service. The list seems endless.
But what happens when you first introduce WIP (work in progress) limits to a team? The immediate question from programmers on the team is the same, every single time. “What do I do when I get blocked?” How can this be? We know they have a list!
Being blocked looks like a problem they must solve. What else in the backlog needs my skills? What if I just work ahead on something I know the team will pick up next time? I’m most valuable as a programmer, so I must find some programming to do while I’m blocked.
Most programmers are drilled throughout their careers in the idea that they are expensive resources, and should not remain idle for any length of time. Staying busy earns their keep. That long list of rainy-day projects will wait. And your specialty is coding, so find something to code.
It takes a surprising amount of effort to persuade these people that working ahead upstream from a bottleneck doesn’t add value, and instead stacks work up at the bottleneck, making the problem even worse. They understand the concepts just fine, but find it extremely hard to give up the habitual response to being idle. And often some stakeholder or middle manager continues to reinforce the stay-busy mentality.
Until you break this habit, a team will continue operate in a mini-waterfall fashion. Each person does one part of the work and hands off to someone else downstream. But once this habit breaks, and the team begins to refocus on the flow of value rather than their individual contribution to it, you have a chance to achieve real cross-functional teamwork.
Being blocked by self-imposed WIP limits is uncomfortable, as it must be to break the common habit of staying busy. Introducing WIP limits forces team members to embrace the opportunity in being blocked, whether by helping others up and down the value stream, or working on that long list of rainy-day projects to improve as a programmer. When that happens, you no longer have a set of individuals working together, but finally have a real team.
Posted on Dec 6, 2015