4 ms·

Scrum will die Scrum was successful in the past, but its time is over

11 points by benkan 3y ago

sharemywin 3y ago
Sounds like the author is advocating for Chaos?
- sharemywin 3y ago
  if you have any kind of size to a team your going to have to coordinate. If your releasing to production you can't break things or change things without communicating to your customers. batching those things up seems like way to minimize context switching type activities.
  - benkan 3y ago
    I guess you're right about that. Do you need cycles of two weeks for that? (Scrum officially doesn't force two-week cycles, but it's still the norm) How do you handle Continuous Deployment then? Only to Staging?
    - sharemywin 3y ago
      or a dev server and you then you can deploy qa server or staging for load testing, integration testing if you have multiple sub systems. and testing for load balancing type issues. 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".
  - sharemywin 3y ago
    I would advocate for a 3 month road map. leaving about 20-25% of your time for small request/bug fixes(unscheduled work). Again this is for an existing product with users. For an MVP you just do it with no code/google sheets/email what ever it takes to get something out the door.
Raidion 3y ago
I used to be a diehard scrum advocate (though I've always been focused on results and not just process as magic). I've felt in my latest role, scrum doesn't cut it. 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.
deleted 3y ago
[deleted]
nivertech 3y ago
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.

11 points by benkan 3y ago

sharemywin 3y ago

Sounds like the author is advocating for Chaos?

sharemywin 3y ago
if you have any kind of size to a team your going to have to coordinate. If your releasing to production you can't break things or change things without communicating to your customers. batching those things up seems like way to minimize context switching type activities.
- benkan 3y ago
  I guess you're right about that. Do you need cycles of two weeks for that? (Scrum officially doesn't force two-week cycles, but it's still the norm) How do you handle Continuous Deployment then? Only to Staging?
  - sharemywin 3y ago
    or a dev server and you then you can deploy qa server or staging for load testing, integration testing if you have multiple sub systems. and testing for load balancing type issues. 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".
- sharemywin 3y ago
  I would advocate for a 3 month road map. leaving about 20-25% of your time for small request/bug fixes(unscheduled work). Again this is for an existing product with users. For an MVP you just do it with no code/google sheets/email what ever it takes to get something out the door.

Raidion 3y ago

I used to be a diehard scrum advocate (though I've always been focused on results and not just process as magic). I've felt in my latest role, scrum doesn't cut it. 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.

deleted 3y ago

[deleted]

nivertech 3y ago

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.