A while ago, a friend and I were comparing experiences on our projects. She talked a little about one of her key stakeholders and said, "He asked me how could he get more throughput out of his team. I didn't know exactly what to say."
Throughput, eh? The word calls to mind network traffic and bits and bytes of data streaming over cables or fiber optics. It's not too far of a jump to extrapolate that to manufacturing or industrial processes like gallons of oil pumped through pipelines or numbers of cargo containers moving through shipping terminals. You could imagine the term applied to fungible goods or relatively interchangeable units of stuff moving on assembly lines. But we were talking about software so what was interchangeable or fungible about that? Lines of code? Nope. Function points? Features? Well, maybe those things are countable. But to what end?
"So, what was he really thinking about?" I asked my friend. "Is he saying that it's taking too long to get a release delivered or is he saying that he's not seeing many significant changes in the releases?"
"Well, both," she said.
"Ahh. I see. What you have there is either a process problem or a people problem or both. And whichever it is, you have the wrong thing and probably too much of it."
If it takes too long between releases, you have a process problem and you probably have too much process -- too many steps, checkpoints, sign-offs, etc.
If you don't get much value out of a release, you have a people problem. The wrong people are making decisions or you are not talking to the right people to get ideas.
Change the process, change the people and throughput should improve.
No comments:
Post a Comment