4 ms·

I know scrum and sprints get a lot of hate, but I've found them to be extremely effective tools for combating this.

by SkyPuncher 5y ago

greenyoda 5y ago
Could you describe more about how scrum/sprints can help combat burnout for you? That hasn't been my own experience.
- bsedlm 5y ago
  they set boundaries? i.e. the set explicit limits to activities, provide structure, make responsibilities clear from the get-go, ...
  - greenyoda 5y ago
    In my experience, whatever boundaries are set within an agile engineering group can be overridden by the priorities, roadmaps, etc. that are imposed from above by the corporate executives. Responsibilities can change overnight as staff are reorganized or laid off by powers beyond their control.
    - bsedlm 5y ago
      well, my answer is theoretical. My own experience is similar to yours: "your team is no longer following scrum in a mad-rush attempt to deliver the deadline." and then everything gets even worse
    - salt-thrower 5y ago
      Every scrum team I've ever been on fell into that pattern eventually. Companies adopted Scrum because it became the trendy way to signal that you're a modern company. Not because of any actual commitment to its framework. In reality, Scrum went from "empower engineers" to "allow managers to micromanage their employees even more, but we call it Agile so you can't push back against it because then you're challenging the orthodoxy."
  - SkyPuncher 5y ago
    Yes. This is exactly it. * We track velocity as the key capacity planning metric. We don't use it for performance or anything else (e.g. we don't care if it creeps or if two different teams have two different velocities). * We then break down all of our work and estimate it. This gives us a scope. * From there, we have a conversation with our PM. Here's the timelines you want to hit. Given the data, we need X. Do you want to cut scope or extend timelines? ----- Lastly, we focus a lot on making decisions that maximize velocity over a medium-term (typically 4 to 12 weeks). There is little value in pushing hard in one sprint if it's going to have an opposite reaction in the next sprint.
pietrovismara 5y ago
Agree to disagree. Nobody does scrum "correctly". Generally only the parts that are supposed to squeeze the most short term value from the employees are picked.
- ravenstine 5y ago
  It's a scam at every level. There's no reason why anyone should need to be "certified" for a methodology to be applied. There isn't even a reason why SCUM methodology should be applied as a sort of universally applicable process. The funniest thing about SCUM is that every diagram someone makes of it looks nearly identical to the straw man that is "Waterfall." https://en.wikipedia.org/wiki/Scrum_(software_development)#/media/File:Scrum_Framework.png https://en.wikipedia.org/wiki/Scrum_(software_development)#/... I mean, tell me that you couldn't change some of the jargon on that diagram and fool just about everyone into thinking it describes Waterfall. The only thing potentially differentiating between SCUM and Waterfall is that the former has (in theory) a smaller iteration window and has liaisons between development and management. But the latter argument is nonsense because generally non-agile teams still self-organize into having liaisons and middle-managers. And as you pointed out, the answer to why SCUM fails always comes down to not doing it "correctly". If no one can do it correctly, that's because it sucks. I've seen agile principles applied in different ways successfully, but I've never seen SCUM actually work any better than no formal methodology at all.
  - geodel 5y ago
    Thanks for calling it what it actually is. We are having developers hired/not-hired on their descriptions of Agile/Scrum/TDD etc in interviews. Imagine that!
- SkyPuncher 5y ago
  Nobody does it "correctly" because they try to use it for a bunch of things that it shouldn't be used for - like performance comparsions. Scrum is only a capacity planning tool. Within a certain context, track velocity. When new work comes in, estimate it then compare to velocity. If you don't have the timelines you want, then you need to consider changing scope.

I know scrum and sprints get a lot of hate, but I've found them to be extremely effective tools for combating this.

greenyoda 5y ago

Could you describe more about how scrum/sprints can help combat burnout for you? That hasn't been my own experience.

bsedlm 5y ago
they set boundaries? i.e. the set explicit limits to activities, provide structure, make responsibilities clear from the get-go, ...
- greenyoda 5y ago
  In my experience, whatever boundaries are set within an agile engineering group can be overridden by the priorities, roadmaps, etc. that are imposed from above by the corporate executives. Responsibilities can change overnight as staff are reorganized or laid off by powers beyond their control.
  - bsedlm 5y ago
    well, my answer is theoretical. My own experience is similar to yours: "your team is no longer following scrum in a mad-rush attempt to deliver the deadline." and then everything gets even worse
  - salt-thrower 5y ago
    Every scrum team I've ever been on fell into that pattern eventually. Companies adopted Scrum because it became the trendy way to signal that you're a modern company. Not because of any actual commitment to its framework. In reality, Scrum went from "empower engineers" to "allow managers to micromanage their employees even more, but we call it Agile so you can't push back against it because then you're challenging the orthodoxy."
- SkyPuncher 5y ago
  Yes. This is exactly it. * We track velocity as the key capacity planning metric. We don't use it for performance or anything else (e.g. we don't care if it creeps or if two different teams have two different velocities). * We then break down all of our work and estimate it. This gives us a scope. * From there, we have a conversation with our PM. Here's the timelines you want to hit. Given the data, we need X. Do you want to cut scope or extend timelines? ----- Lastly, we focus a lot on making decisions that maximize velocity over a medium-term (typically 4 to 12 weeks). There is little value in pushing hard in one sprint if it's going to have an opposite reaction in the next sprint.

pietrovismara 5y ago

Agree to disagree. Nobody does scrum "correctly". Generally only the parts that are supposed to squeeze the most short term value from the employees are picked.

ravenstine 5y ago
It's a scam at every level. There's no reason why anyone should need to be "certified" for a methodology to be applied. There isn't even a reason why SCUM methodology should be applied as a sort of universally applicable process. The funniest thing about SCUM is that every diagram someone makes of it looks nearly identical to the straw man that is "Waterfall." https://en.wikipedia.org/wiki/Scrum_(software_development)#/media/File:Scrum_Framework.png https://en.wikipedia.org/wiki/Scrum_(software_development)#/... I mean, tell me that you couldn't change some of the jargon on that diagram and fool just about everyone into thinking it describes Waterfall. The only thing potentially differentiating between SCUM and Waterfall is that the former has (in theory) a smaller iteration window and has liaisons between development and management. But the latter argument is nonsense because generally non-agile teams still self-organize into having liaisons and middle-managers. And as you pointed out, the answer to why SCUM fails always comes down to not doing it "correctly". If no one can do it correctly, that's because it sucks. I've seen agile principles applied in different ways successfully, but I've never seen SCUM actually work any better than no formal methodology at all.
- geodel 5y ago
  Thanks for calling it what it actually is. We are having developers hired/not-hired on their descriptions of Agile/Scrum/TDD etc in interviews. Imagine that!
SkyPuncher 5y ago
Nobody does it "correctly" because they try to use it for a bunch of things that it shouldn't be used for - like performance comparsions. Scrum is only a capacity planning tool. Within a certain context, track velocity. When new work comes in, estimate it then compare to velocity. If you don't have the timelines you want, then you need to consider changing scope.