4 ms·

Yeah, yeah, yeah - Scrum is bad. That's the fashionable thing to say these days. I figure the people peddling Scrum have run out of people to peddle it to and n

Yeah, yeah, yeah - Scrum is bad. That's the fashionable thing to say these days. I figure the people peddling Scrum have run out of people to peddle it to and now they're trying to convince everybody we need a new paradigm. Then they can sell new training and have fresh material for the Conference Circuit. Here's the thing: I've been developing software for 40 years now and while Scrum definitely has its issues and can be abused - I'm not denying that! - it is loads better than what we were using before! No comparison! Scrum is dumb? Okay. Cool. What's your alternative?

wmf 2y ago
XP? Kanban? There are plenty of alternatives.
syndicatedjelly 2y ago
That's great that you've been doing things a long time, but it's possible to criticize the current state of affairs without invoking the whole "well do you want to just do what we did in 1980 again" argument. What was it that you were doing back then that was so bad? Can we avoid doing that, as well as scrum, and do something else, perhaps?
- taylodl 2y ago
  Yes, and please offer that rather than just come saying "Scrum Bad." Just for a point of reference, people had said "Waterfall Bad" for 25 years before an alternative was presented. It took another 15 years after that before the alternative became wide practiced. Now here we are 15 years after adopting the alternative and saying it's bad. Yes, these discussions and laments go back for decades.
  - bartonfink 2y ago
    So add something to them instead of saying that the problems of Scrum don't exist because of your own dubiously stated experience.
    - triceratops 2y ago
      > saying that the problems of Scrum don't exist What OP wrote: "Scrum definitely has its issues and can be abused"
  - syndicatedjelly 2y ago
    I think a big problem is that people seem to think of development as either "waterfall" or "scrum", with a gradient between the two. Being strictly on either side is seen as bad, and being a blend of waterfall-agile is bad too. All I can think of is to throw both out the window and figure out a different set of metrics to prioritize, other than the business-driven Time-To-Deploy-And-We-Make-Profit. I don't have a perfect solution, but the best one I've implemented so far works only in small teams, and is effectively Kanban-driven development. I try to stay close to The Toyota Way, which I learned while working in medical device (where they, like aerospace, draw a lot of inspiration from our industrial engineering forefathers). I guess my solution is - create many small teams, let them implement "lightweight scrum" where the Kanban board is the main discussion point every day. What tasks are pending, what's next, what is stuck? And finally, let the small teams throw away anything they don't like, including the board, as long as they meet their deliverables defined by the broader team. Is this too Scrum-y still? Maybe. But Scrum has lost its way and its time to just return to the basics and implement stuff that's worked for decades in other industries. Software Engineering had its chance to play around and re-invent the wheel, going all the way back to Fred Brooks Mythical Man-Month. The industry has had 50 years to get its shit together, which is an absolute eternity and inexcusable for how shitty a state of affairs we have now, in terms of program management philosophies. Frankly I'm interested in just using the original wheel at this point, where we assign tasks to teams and estimate them USING REAL TIME ESTIMATES (not story points like we are fucking fairy tales). I care more about making high-quality software and less about management philosophies these days. More about my rant here - https://www.ashwinsundar.com/story-points-stupid/ https://www.ashwinsundar.com/story-points-stupid/
  - wmf 2y ago
    Ironically, the 1970 Waterfall paper proposed a better alternative (that was mostly ignored).
    - taylodl 2y ago
      Many people in the 80s and early 90s tried that alternative. It worked very well for smaller projects, which frankly, was the point. Take the big project and break it into little projects and then utilize a strike team to implement each of the little projects. The approach was decent, and still is!, it's just combining a bunch of little projects into a big project and managing the overall big project is challenging. That's the rub - small projects don't need much management at all, medium projects benefit from existing methodologies (whether they're "good" or "bad"), but large projects are a challenge no matter what you do. You can make them less challenging, but they're still challenging.
aard 2y ago
How about letting engineers do what everyone else at the company does? Get together in teams, divide up the work, and check back later. You are asking for an alternative thing to mandate upon engineers from above -- something formal. I say, just let engineers manage themselves. No mandated process.
- taylodl 2y ago
  Scrum, Waterfall, XP, Kanban - these are the tools engineers created for managing their work. I've never worked at a place where the way your engineering team manages their work has ever been mandated. I've never met a business stakeholder who gives two shits how engineering manages their work - all they care about is when am I going to get it and how much is it going to cost me - and how accurate and reliable are these answers? As far as letting engineers manage themselves - if the scope of work is small enough and there's no dependence on other teams or vendors delivering needed components then sure, do whatever you want. It's often inappropriate to apply much rigor to such small projects. Skunk work projects can also be managed that way.
  - wmf 2y ago
    This is sort of true, but it's common for engineering management to force Scum on their engineers. It's not being forced by a VP but it is still forced.
    - taylodl 2y ago
      "Engineering Management" is still engineering. Nobody outside of the engineering department is telling the engineering department how to manage their work. This is what it means for engineers to manage their own work. If your engineering department is being heavy-handed in how they apply project management to all their projects, then that's on them. But realize it is their job to ensure the work is getting done.

wmf 2y ago

XP? Kanban? There are plenty of alternatives.

syndicatedjelly 2y ago

That's great that you've been doing things a long time, but it's possible to criticize the current state of affairs without invoking the whole "well do you want to just do what we did in 1980 again" argument. What was it that you were doing back then that was so bad? Can we avoid doing that, as well as scrum, and do something else, perhaps?

taylodl 2y ago
Yes, and please offer that rather than just come saying "Scrum Bad." Just for a point of reference, people had said "Waterfall Bad" for 25 years before an alternative was presented. It took another 15 years after that before the alternative became wide practiced. Now here we are 15 years after adopting the alternative and saying it's bad. Yes, these discussions and laments go back for decades.
- bartonfink 2y ago
  So add something to them instead of saying that the problems of Scrum don't exist because of your own dubiously stated experience.
  - triceratops 2y ago
    > saying that the problems of Scrum don't exist What OP wrote: "Scrum definitely has its issues and can be abused"
- syndicatedjelly 2y ago
  I think a big problem is that people seem to think of development as either "waterfall" or "scrum", with a gradient between the two. Being strictly on either side is seen as bad, and being a blend of waterfall-agile is bad too. All I can think of is to throw both out the window and figure out a different set of metrics to prioritize, other than the business-driven Time-To-Deploy-And-We-Make-Profit. I don't have a perfect solution, but the best one I've implemented so far works only in small teams, and is effectively Kanban-driven development. I try to stay close to The Toyota Way, which I learned while working in medical device (where they, like aerospace, draw a lot of inspiration from our industrial engineering forefathers). I guess my solution is - create many small teams, let them implement "lightweight scrum" where the Kanban board is the main discussion point every day. What tasks are pending, what's next, what is stuck? And finally, let the small teams throw away anything they don't like, including the board, as long as they meet their deliverables defined by the broader team. Is this too Scrum-y still? Maybe. But Scrum has lost its way and its time to just return to the basics and implement stuff that's worked for decades in other industries. Software Engineering had its chance to play around and re-invent the wheel, going all the way back to Fred Brooks Mythical Man-Month. The industry has had 50 years to get its shit together, which is an absolute eternity and inexcusable for how shitty a state of affairs we have now, in terms of program management philosophies. Frankly I'm interested in just using the original wheel at this point, where we assign tasks to teams and estimate them USING REAL TIME ESTIMATES (not story points like we are fucking fairy tales). I care more about making high-quality software and less about management philosophies these days. More about my rant here - https://www.ashwinsundar.com/story-points-stupid/ https://www.ashwinsundar.com/story-points-stupid/
- wmf 2y ago
  Ironically, the 1970 Waterfall paper proposed a better alternative (that was mostly ignored).
  - taylodl 2y ago
    Many people in the 80s and early 90s tried that alternative. It worked very well for smaller projects, which frankly, was the point. Take the big project and break it into little projects and then utilize a strike team to implement each of the little projects. The approach was decent, and still is!, it's just combining a bunch of little projects into a big project and managing the overall big project is challenging. That's the rub - small projects don't need much management at all, medium projects benefit from existing methodologies (whether they're "good" or "bad"), but large projects are a challenge no matter what you do. You can make them less challenging, but they're still challenging.

aard 2y ago

How about letting engineers do what everyone else at the company does? Get together in teams, divide up the work, and check back later. You are asking for an alternative thing to mandate upon engineers from above -- something formal. I say, just let engineers manage themselves. No mandated process.

taylodl 2y ago
Scrum, Waterfall, XP, Kanban - these are the tools engineers created for managing their work. I've never worked at a place where the way your engineering team manages their work has ever been mandated. I've never met a business stakeholder who gives two shits how engineering manages their work - all they care about is when am I going to get it and how much is it going to cost me - and how accurate and reliable are these answers? As far as letting engineers manage themselves - if the scope of work is small enough and there's no dependence on other teams or vendors delivering needed components then sure, do whatever you want. It's often inappropriate to apply much rigor to such small projects. Skunk work projects can also be managed that way.
- wmf 2y ago
  This is sort of true, but it's common for engineering management to force Scum on their engineers. It's not being forced by a VP but it is still forced.
  - taylodl 2y ago
    "Engineering Management" is still engineering. Nobody outside of the engineering department is telling the engineering department how to manage their work. This is what it means for engineers to manage their own work. If your engineering department is being heavy-handed in how they apply project management to all their projects, then that's on them. But realize it is their job to ensure the work is getting done.