Scrum will die Scrum was successful in the past, but its time is over
leadinginproduct.com
leadinginproduct.com
Problems: - Larger team: I can't swarm developers on a single project. It's impractical for every team member to be instantly able to help out with the domain specific work. - We're a platform team and so are in the way of $FEATURE a lot. Our long term roadmap is primarily driven by other teams urgency and we have to roll with it. - Estimates are a boolean, not a date. Our estimates don't matter because unless it's a 6m+ project, it needs to be done because of $FEATURE
Because of this, sprint planning is never stable long term. Every work comes with tradeoffs being made at the top level. Estimation means time away from doing work we know we're going to do unless it's a huge SWAG.
I like the ownership scrum has, but the work is gonna take what the work takes. Why should we spend tons of time estimating and planning when we just need to get the work done before next product launch 6m out? Feels like Kanban might work better. I need to read up on the Basecamp model.
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.
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.
batching those things up seems like way to minimize context switching type activities.
For an MVP you just do it with no code/google sheets/email what ever it takes to get something out the door.
How do you handle Continuous Deployment then? Only to Staging?
I'm not arguing against more flexibility when your in small team /pre or early release MVP stage(s)
Also, you need a "Hot Fix" short circuit process as well. Although you need to watch it and make sure management is on board with the idea that a reliable road map is important and specific criteria for urgency or everything turns into a "hot fix".