Re:Ask HN: Why Not Kanban?
by nivertech on Thursday August 31, 2023 @08:27AM
(#37336129)
Task Decomposition / Task Management is only a small part of SLDC, but both Scrum and Kanban mostly focusing on it.
Kanban is a great fit for the reactive work (e.g. bug fixing, support, mainetnance, ops, etc.)
Scrum solves a bin-packing problem, how to decompose work into imaginary tasks and fill them into 1-2-3-4 week cycles (aka sprints). Additionally it based on the false assumption that it's possible to accurately do time estimation of each task.
There is a continuum between purely reactive/unplanned work to purely proactive/planned work:
The shorter the cycle, the lower the response time, the greater the planning overhead, and the lower the software quality.[2]
IMO it's impossible to build and deliver a non-trivial feature in >= 3 weeks.
Detailed task management is an anti-pattern, initially issue trackers were used to track bugs only, not as TODO lists.
Under mini-waterfall once the stakeholders agree on the goals, approve the design documents and delivery dates, the developers can work autonomously, they don't need to use task management tools, they can do it with pen and paper, or in their head if they want, it doesn't matter . Everything else is micro-management, handling only imaginary tasks, no tasks discovered after the work has already begun.
Another distinction lies in how Scrum views developer teams as conveyor belts. In this approach, you can assign any set of imaginary tickets, regardless of their relation, and the team will implement them.
To the contrary in the mini-waterfall methods, you present developers with a cohesive collection of tasks featuring pre-approved, thoughtfully planned, and peer-reviewed designs. The best case is when devlopers are doing design by themselves, that way they don't need somebody else to decompose work into detailed tasks for them.
Kanban is a great fit for the reactive work (e.g. bug fixing, support, mainetnance, ops, etc.)
Scrum solves a bin-packing problem, how to decompose work into imaginary tasks and fill them into 1-2-3-4 week cycles (aka sprints). Additionally it based on the false assumption that it's possible to accurately do time estimation of each task.
There is a continuum between purely reactive/unplanned work to purely proactive/planned work:
The shorter the cycle, the lower the response time, the greater the planning overhead, and the lower the software quality.[2]IMO it's impossible to build and deliver a non-trivial feature in >= 3 weeks.
Detailed task management is an anti-pattern, initially issue trackers were used to track bugs only, not as TODO lists.
Under mini-waterfall once the stakeholders agree on the goals, approve the design documents and delivery dates, the developers can work autonomously, they don't need to use task management tools, they can do it with pen and paper, or in their head if they want, it doesn't matter . Everything else is micro-management, handling only imaginary tasks, no tasks discovered after the work has already begun.
Another distinction lies in how Scrum views developer teams as conveyor belts. In this approach, you can assign any set of imaginary tickets, regardless of their relation, and the team will implement them.
To the contrary in the mini-waterfall methods, you present developers with a cohesive collection of tasks featuring pre-approved, thoughtfully planned, and peer-reviewed designs. The best case is when devlopers are doing design by themselves, that way they don't need somebody else to decompose work into detailed tasks for them.
---
[1] Map of SDLCs and Product Frameworks
https://twitter.com/nivertech/status/1695945592801800412/pho...
[2] Kanban - Scrum - mini-waterfall continuum
https://twitter.com/nivertech/status/1690669746578980864