2 ms·

I think you're describing what Steve Yegge called "good agile" [1]. Each task is handled by the person closest to the issue rather than by the person whose job

I think you're describing what Steve Yegge called "good agile" [1]. Each task is handled by the person closest to the issue rather than by the person whose job title best matches the perceived difficulty of the task. "With a priority queue, you have a dumping-ground for any and all ideas (and bugs) that people suggest as the project unfolds. No engineer is ever idle, unless the queue is empty, which by definition means the project has launched. Tasks can be suspended and resumed simply by putting them back in the queue with appropriate notes or documentation. You always know how much work is left, and if you like, you can make time estimates based on the remaining tasks. You can examine closed work items to infer anything from bug regression rates to (if you like) individual productivity. You can see which tasks are often passed over, which can help you discover root causes of pain in the organization. A work queue is completely transparent, so there is minimal risk of accidental duplication of work." [1] http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...

bernardlunn 15y ago
"good agile" work queue sounds a bit like how good open source works and that might be scalable even for commercial and enterprise. The problem with some agile is it does not scale, so managers invent some process that is a bit waterfall-like and that turns into a kludgey mess.
- dkarl 15y ago
  Exactly. Agile does not scale to the problems management wants to apply it to, so they rip it to pieces to make it fit. We have features contractually committed before development even starts, months-distant deadlines with predetermined deliverables, products with multiple owners, and scrum teams where people have the barest understanding of the work that their teammates do. We even have inter-team dependencies that mean any change of direction by a team will hang other teams out to dry (and what is more essential to agility than the ability to change direction?) A well-managed waterfall process would beat the hell out of the travesty of Agile that we practice now. But nothing would fix the bogus and stunting idea of a division of labor between "architects" and "developers."

bernardlunn 15y ago

"good agile" work queue sounds a bit like how good open source works and that might be scalable even for commercial and enterprise. The problem with some agile is it does not scale, so managers invent some process that is a bit waterfall-like and that turns into a kludgey mess.

dkarl 15y ago
Exactly. Agile does not scale to the problems management wants to apply it to, so they rip it to pieces to make it fit. We have features contractually committed before development even starts, months-distant deadlines with predetermined deliverables, products with multiple owners, and scrum teams where people have the barest understanding of the work that their teammates do. We even have inter-team dependencies that mean any change of direction by a team will hang other teams out to dry (and what is more essential to agility than the ability to change direction?) A well-managed waterfall process would beat the hell out of the travesty of Agile that we practice now. But nothing would fix the bogus and stunting idea of a division of labor between "architects" and "developers."