2 months ago • Edited • Visible to anyone on or off LinkedIn
If you are working with development teams (and aren't a developer or ex-developer) then this might be jarring, but it's intended for good.
The reason it takes so long for work to be done? I know from a distance it seems like it's "they're not working hard enough" but it's very possible (better than 50/50) that they're working too much.
You see, wherever there is a handoff there is a queue.
If the person receiving the work is busy, the queue becomes a wait.
How long work waits is largely a matter of:
Development organizations are often a labyrinth of queues. And yes, this delays starting work AND delays completing work.
Often work is assigned to individuals, so incoming jobs wait until that one person is available, no matter who else has time. If you are job #12, you are job #12.
But also, the queue is disrupted by work returned from quality gate rejections. When work is hurried, it is more likely to be returned as shortcuts don't always pass all tests and inspections, or may be ill-considered. Rework from hurried implementation is disturbingly common in many programming organizations.
After completion, the work may spend weeks or months before it is deployed, and most of that is queuing also, sometimes repeatedly queuing for quality gates until it gets through.
Without so much work-in-progress (really work-in-queue) there would be faster starts and completions.
There's more to this, but maybe check and see what the load is like before "they have to work harder" since the system, the human pipeline, may be inflicting most of the slowness.
And, no, AI doesn't fix this.
The reason it takes so long for work to be done? I know from a distance it seems like it's "they're not working hard enough" but it's very possible (better than 50/50) that they're working too much.
You see, wherever there is a handoff there is a queue.
If the person receiving the work is busy, the queue becomes a wait.
How long work waits is largely a matter of:
- How many things are in the queue
- How soon someone can pull the work from the queue
- How long it takes to complete the job once started
- How long it takes to clear all of the other queues post-development.
Development organizations are often a labyrinth of queues. And yes, this delays starting work AND delays completing work.
Often work is assigned to individuals, so incoming jobs wait until that one person is available, no matter who else has time. If you are job #12, you are job #12.
But also, the queue is disrupted by work returned from quality gate rejections. When work is hurried, it is more likely to be returned as shortcuts don't always pass all tests and inspections, or may be ill-considered. Rework from hurried implementation is disturbingly common in many programming organizations.
After completion, the work may spend weeks or months before it is deployed, and most of that is queuing also, sometimes repeatedly queuing for quality gates until it gets through.
Without so much work-in-progress (really work-in-queue) there would be faster starts and completions.
There's more to this, but maybe check and see what the load is like before "they have to work harder" since the system, the human pipeline, may be inflicting most of the slowness.
And, no, AI doesn't fix this.
No comments:
Post a Comment