Throughput - I

I've been thinking about throughput a lot lately.

Example: It's winter in Michigan, and it's snowing. So, on my way to work this morning, I see a truck that is plowing. The truck is doing an excellent job of plowing, shifting from forward to reverse very quickly, accelerating quickly and using heavy brakes. He sure is marching and moving.

The problem was, I was trying to get past him, and I couldn't, because his sudden shifts in momentum were so uprupt that it would be dangerous to pull forward. I had to wait. And wait.

So, the truck was doing an excellent job plowing, but overall throughput on the road suffered.

We do this in software development all the time. We optimize the job for our role, focus on handoffs, signatures, and role-based contracts, instead of trying to be helpful and collaborate. Devs refuse to proceed without documented requirements instead of having a conversation and trying to figure out what the customers and analysts desire. Architects (and I use the term loosely) refuse to begin design until "all" the requirements are elaborated. Testers refuse to begin testing until all the documentation is completed.

Each of these tactics helps the individual role be efficient (or easy), but the overall project suffers. In fact, you can make a strong argument that the Waterfall model gained it's popularity not because it was good, but because it is conveinient and easy for management. (After all, for the schedule, you can just "set it and forget it.")

In my own career, in general, I've protected the project at my own expense. While I have taken some slings and arrows (and been told at least twice to "know your role, be your role" when I was trying to be helpful and get things done) it's led to more successful projects, and allow me to develop expertise in software testing, requirements, scheduling, and the overall process.

A rising tide lifts all boats, so I would like to submit this to you: Forget your role, keep the project moving, and your title and position might just take care of itself.

(Of course, there's more to it than that. More later.)