3 ms·

Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank. That says it all about it. It's mostly for less skilled and unmotivated work

Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank. That says it all about it. It's mostly for less skilled and unmotivated workers working on a relatively simple projects (e.g. corporate/enterprise software development). Leaving aside stupid rituals and ceremonies, which are time-wasters, and motivation-killers. Scrum aims to address the task management aspect by approaching it as a tickets bin packing problem. However, it relies on the false assumption that accurate task estimation is possible. For reactive or unplanned work, short sprints can be effectively replaced by a pure Kanban approach. For proactive or planned work, long sprints can be better substituted with mini-waterfall SDLCs. While the post mentions the Shape Up method and highlights that FAANG companies do not use Scrum, it fails to mention that these companies utilize mini-waterfall SDLCs with approximately six-week cycles.

dragonwriter 3y ago
> However, it relies on the false assumption that accurate task estimation is possible. Scrum-as-designed does not do this nearly as much as “Scrum”-in-common-practice, the big problem in practice in neglecting the concept of a Sprint Goal and its central role as a guidepost in reactively deciding what how to adapt the list of individual items being done in a sprint (in either direction) as you learn more about how much time the tasks being worked are taking. Well, that and attempts at overly precise estimates, demands for 100% utilization when planning a sprint around task estimates, and demands to treat the tasks pulled into a sprint as a rigid commitment, all of which amount to neglect of the rule “Scope may be clarified and renegotiated with the Product Owner as more is learned.” I’m not saying Scrum-per-the-Scrum-Guide is ideal, it has lots of issues and I think flow-based Kanban is better than sprint-based Scrum in general. But a lot of the problems of Scrum-in-practice have nothing to do with Scrum-as-designed, and everything to do with the fact that the best design cannot be eliminate the problem of managers rewrite the design to fit their own mental myths about the way projects should work and ignoring the design of the nominal system in use and the agency of the team.

dragonwriter 3y ago

> However, it relies on the false assumption that accurate task estimation is possible. Scrum-as-designed does not do this nearly as much as “Scrum”-in-common-practice, the big problem in practice in neglecting the concept of a Sprint Goal and its central role as a guidepost in reactively deciding what how to adapt the list of individual items being done in a sprint (in either direction) as you learn more about how much time the tasks being worked are taking. Well, that and attempts at overly precise estimates, demands for 100% utilization when planning a sprint around task estimates, and demands to treat the tasks pulled into a sprint as a rigid commitment, all of which amount to neglect of the rule “Scope may be clarified and renegotiated with the Product Owner as more is learned.” I’m not saying Scrum-per-the-Scrum-Guide is ideal, it has lots of issues and I think flow-based Kanban is better than sprint-based Scrum in general. But a lot of the problems of Scrum-in-practice have nothing to do with Scrum-as-designed, and everything to do with the fact that the best design cannot be eliminate the problem of managers rewrite the design to fit their own mental myths about the way projects should work and ignoring the design of the nominal system in use and the agency of the team.