11 ms·

Scrum won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.

by brightball 7y ago

colordrops 7y ago
> Commitments and sprints become terribly destructive over time. Could you elaborate?
- anon1m0us 7y ago
  You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. This requires sacrifices like ensuring network connections remain alive, handling exceptions, optimizing queries, abstracting functions for re-use, handling all the data input scenarios, etc. This creates a confusing code-base with lots of IF statements, copy/pasted code, data modifications from several areas of the system, etc. You'll fix a problem with data getting into the database incorrectly and realize a couple sprints later, fixing that bug caused other bugs elsewhere. Automated testing doesn't catch it because automated testing only handled certain scenarios. It's a mess.
  - drngdds 7y ago
    >You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. Well there's your problem. How is that inherent to scrum?
    - barrkel 7y ago
      Because it's a sprint. You've got a finish line and you're racing towards it. Businesses don't function without prediction, and refactoring gets cut before roadmapped features. If feature development is a bottleneck in company growth, debt will grow, quickly.
      - MartinCron 7y ago
        “Sprints” are, pretty much by definition, a non-sustainable pace.
        epage 7y ago
        Agreed. I regularly ask "Why are we running a marathon in a thousand sprints?". Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for "high velocity". There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.
      - verinus 7y ago
        imho a problem with the implementation of SCRUM, but not necessarily restricted to SCRUM. In a perfect SCRUM world you could not be forced to implement this in a time not of your own estimate. A feature that is so big that it takes more than a few days to implement has to be split...but well we all know how this plays our in reality most of the times...
  - rileymat2 7y ago
    >You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. There is something odd with this, if you did the estimation. Shouldn't the story points/sizing/estimates preclude this? Doesn't the team pick the items for the sprint that they think they can complete?
    - Aeolun 7y ago
      You can never take a 4 week story in a two week sprint. When would you ever be able to complete it?
      - rileymat2 7y ago
        By breaking it down into smaller stories?
        klyrs 7y ago
        My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.
        rileymat2 7y ago
        I have not worked in a scrum environment in a couple of years, but when we did it those items were not included in the story. They were part of a definition of done that the team did not really talk about publicly. Refactoring stories were also rare, it was just sort implicit in the task, unspoken as part of doing it. I'd imagine that is why they did not get cut. But yes, management picked feature priorities, but left the implementation up to the team. So at any given time were were working on the "most important" thing from a business perspective.
        pandapower2 7y ago
        The most successful (but still crappy) solution to this that I have seen is developers undertaking guerilla tech debt work. This can be done by bundling maintenance work into an existing task where the two are actually not that related or by simply carving out bits of time between official tasks. While it "works" it is certainly not ideal that people have to go off the reservation to ensure that the project doesn't implode in the future due to the accumulation of buggy code, performance problems and likely security vulnerabilities.
- brightball 7y ago
  Yep. :) https://www.brightball.com/articles/reality-driven-development-fixing-project-management-in-software https://www.brightball.com/articles/reality-driven-developme...
barrkel 7y ago
Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers. I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product won't prioritize refactorings, and sprints are too short for devs to sneak refactoring into the schedule.
- anon1m0us 7y ago
  I was explicitly told not to write unit tests because they took too much time, which required me to spend entire days retesting almost 100 scenarios when the business logic changed. Of course the business didn't know all the scenarios at the beginning of the feature development and didn't care because: iterative development means we'll figure it out later.
  - wpietri 7y ago
    As you've discovered, good automated testing is mandatory for iterative development. If execs tell you to do something unprofessional, it's ok to say no. Indeed, if we're going to think of ourselves as professionals, I think it's mandatory.
    - Chris2048 7y ago
      > if we're going to think of ourselves as professionals We need to unify around these principles, possibly revoke memberships for unprofessional behavior. One dev getting himself fired changes nothing..
      - wpietri 7y ago
        I'd love to see that kind of organizing happen. But one developer quitting rather than do bad work does change something. At the very least, it means that the developer can find another, better job. But it's also an opportunity for companies to learn. And for those who don't, good people refusing to prop up bad companies is a step forward. I'd also add there's a a lot that can happen between refusing to do bad work and quitting/getting fired. Saying no is the beginning of a negotiation. A negotiation that won't happen if we just say yes all the time.
anon1m0us 7y ago
Waterfall was coined by a paper discussing why waterfall wasn't a good way to do software projects. You aren't wrong, either. I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration." That caused so many problems with tech debt. Stories began to take longer due to the increasingly large and discombobulated code base, but the expectation was that we continue to deliver the same number of story points each sprint. Then we got blasted for losing pace. "Why are you under-performing? We are just adding little features. You've already implemented this button on another form before? Why does it take longer the second time? You already know how to do it!" It became absurd and no one could hear or understand what was happening was easily predictable and in fact -- was predicted by several members of the team many months prior. When the project management was informed of these predictions now having come true, the development team was accused of intentionally causing the delays.
- xyzzy_plugh 7y ago
  This mirrors my experiences to a tee. The most upsetting experience in my career thus far was being belittled by an incompetent project manager. "How could it possibly take that long? How do you not know how long it will take?" The happiest times of my career have been when we're lacking a PM -- coincidentally the most successful!
  - forinti 7y ago
    Best PM I ever had dropped by every week or so to ask if we needed anything.
    - allthecybers 7y ago
      That's what the best ones do.
  - mixmastamyk 7y ago
    > "How could it possibly take that long? How do you not know how long it will take?" Well, if they really said that, you can just dismiss the comment as incompetent. A witty retort may be in order if a non-technical manager is in earshot, e.g.: "How long would it take for you to earn a green belt in karate?" "Hmm, what does a green belt entail?" "Exactly, you don't even know what you don't know, yet."
forinti 7y ago
Waterfall with little or no modelling. If you write the wrong system, you are left with nothing. With waterfall you could at least start over with your design artefacts.
RyJones 7y ago
Scrumfall is, sadly, widespread
Aeolun 7y ago
I love these commitments. When my Scrum leaders asks me why we didn’t finish what we ‘committed’ to doing these two weeks I want to strangle him (nothing personal, I do otherwise like the guy :P). The terminology is so incredibly developer hostile.
- Ettvatre 7y ago
  Which is why the scrum handbook went with the term forecast instead. Many years ago.
closeparen 7y ago
Scrum wins out at companies that did not exist in the waterfall era, staffed by developers and engineering managers who have only ever worked in startups. Similarity to existing process may explain a large part of the adoption in places that had existing process, but a lot of Scrum shops didn't.
innocentoldguy 7y ago
I agree. The last "waterfall" company I worked for was Novell. In my opinion, all the Novells of the world glommed onto Scrum because it was shiny and new and allowed them to call all their bloated and unnecessary project managers "Scrum Masters" and all their wasteful status meetings "Stand-ups." It was just the same old garbage with a different name, but hey, We're Scrumming!

Scrum won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.

colordrops 7y ago

> Commitments and sprints become terribly destructive over time. Could you elaborate?

anon1m0us 7y ago
You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. This requires sacrifices like ensuring network connections remain alive, handling exceptions, optimizing queries, abstracting functions for re-use, handling all the data input scenarios, etc. This creates a confusing code-base with lots of IF statements, copy/pasted code, data modifications from several areas of the system, etc. You'll fix a problem with data getting into the database incorrectly and realize a couple sprints later, fixing that bug caused other bugs elsewhere. Automated testing doesn't catch it because automated testing only handled certain scenarios. It's a mess.
- drngdds 7y ago
  >You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. Well there's your problem. How is that inherent to scrum?
  - barrkel 7y ago
    Because it's a sprint. You've got a finish line and you're racing towards it. Businesses don't function without prediction, and refactoring gets cut before roadmapped features. If feature development is a bottleneck in company growth, debt will grow, quickly.
    - MartinCron 7y ago
      “Sprints” are, pretty much by definition, a non-sustainable pace.
      - epage 7y ago
        Agreed. I regularly ask "Why are we running a marathon in a thousand sprints?". Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for "high velocity". There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.
    - verinus 7y ago
      imho a problem with the implementation of SCRUM, but not necessarily restricted to SCRUM. In a perfect SCRUM world you could not be forced to implement this in a time not of your own estimate. A feature that is so big that it takes more than a few days to implement has to be split...but well we all know how this plays our in reality most of the times...
- rileymat2 7y ago
  >You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. There is something odd with this, if you did the estimation. Shouldn't the story points/sizing/estimates preclude this? Doesn't the team pick the items for the sprint that they think they can complete?
  - Aeolun 7y ago
    You can never take a 4 week story in a two week sprint. When would you ever be able to complete it?
    - rileymat2 7y ago
      By breaking it down into smaller stories?
      - klyrs 7y ago
        My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.
        rileymat2 7y ago
        I have not worked in a scrum environment in a couple of years, but when we did it those items were not included in the story. They were part of a definition of done that the team did not really talk about publicly. Refactoring stories were also rare, it was just sort implicit in the task, unspoken as part of doing it. I'd imagine that is why they did not get cut. But yes, management picked feature priorities, but left the implementation up to the team. So at any given time were were working on the "most important" thing from a business perspective.
        pandapower2 7y ago
        The most successful (but still crappy) solution to this that I have seen is developers undertaking guerilla tech debt work. This can be done by bundling maintenance work into an existing task where the two are actually not that related or by simply carving out bits of time between official tasks. While it "works" it is certainly not ideal that people have to go off the reservation to ensure that the project doesn't implode in the future due to the accumulation of buggy code, performance problems and likely security vulnerabilities.
brightball 7y ago
Yep. :) https://www.brightball.com/articles/reality-driven-development-fixing-project-management-in-software https://www.brightball.com/articles/reality-driven-developme...

barrkel 7y ago

Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers. I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product won't prioritize refactorings, and sprints are too short for devs to sneak refactoring into the schedule.

anon1m0us 7y ago
I was explicitly told not to write unit tests because they took too much time, which required me to spend entire days retesting almost 100 scenarios when the business logic changed. Of course the business didn't know all the scenarios at the beginning of the feature development and didn't care because: iterative development means we'll figure it out later.
- wpietri 7y ago
  As you've discovered, good automated testing is mandatory for iterative development. If execs tell you to do something unprofessional, it's ok to say no. Indeed, if we're going to think of ourselves as professionals, I think it's mandatory.
  - Chris2048 7y ago
    > if we're going to think of ourselves as professionals We need to unify around these principles, possibly revoke memberships for unprofessional behavior. One dev getting himself fired changes nothing..
    - wpietri 7y ago
      I'd love to see that kind of organizing happen. But one developer quitting rather than do bad work does change something. At the very least, it means that the developer can find another, better job. But it's also an opportunity for companies to learn. And for those who don't, good people refusing to prop up bad companies is a step forward. I'd also add there's a a lot that can happen between refusing to do bad work and quitting/getting fired. Saying no is the beginning of a negotiation. A negotiation that won't happen if we just say yes all the time.

anon1m0us 7y ago

Waterfall was coined by a paper discussing why waterfall wasn't a good way to do software projects. You aren't wrong, either. I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration." That caused so many problems with tech debt. Stories began to take longer due to the increasingly large and discombobulated code base, but the expectation was that we continue to deliver the same number of story points each sprint. Then we got blasted for losing pace. "Why are you under-performing? We are just adding little features. You've already implemented this button on another form before? Why does it take longer the second time? You already know how to do it!" It became absurd and no one could hear or understand what was happening was easily predictable and in fact -- was predicted by several members of the team many months prior. When the project management was informed of these predictions now having come true, the development team was accused of intentionally causing the delays.

xyzzy_plugh 7y ago
This mirrors my experiences to a tee. The most upsetting experience in my career thus far was being belittled by an incompetent project manager. "How could it possibly take that long? How do you not know how long it will take?" The happiest times of my career have been when we're lacking a PM -- coincidentally the most successful!
- forinti 7y ago
  Best PM I ever had dropped by every week or so to ask if we needed anything.
  - allthecybers 7y ago
    That's what the best ones do.
- mixmastamyk 7y ago
  > "How could it possibly take that long? How do you not know how long it will take?" Well, if they really said that, you can just dismiss the comment as incompetent. A witty retort may be in order if a non-technical manager is in earshot, e.g.: "How long would it take for you to earn a green belt in karate?" "Hmm, what does a green belt entail?" "Exactly, you don't even know what you don't know, yet."

forinti 7y ago

Waterfall with little or no modelling. If you write the wrong system, you are left with nothing. With waterfall you could at least start over with your design artefacts.

RyJones 7y ago

Scrumfall is, sadly, widespread

Aeolun 7y ago

I love these commitments. When my Scrum leaders asks me why we didn’t finish what we ‘committed’ to doing these two weeks I want to strangle him (nothing personal, I do otherwise like the guy :P). The terminology is so incredibly developer hostile.

Ettvatre 7y ago
Which is why the scrum handbook went with the term forecast instead. Many years ago.

closeparen 7y ago

Scrum wins out at companies that did not exist in the waterfall era, staffed by developers and engineering managers who have only ever worked in startups. Similarity to existing process may explain a large part of the adoption in places that had existing process, but a lot of Scrum shops didn't.

innocentoldguy 7y ago

I agree. The last "waterfall" company I worked for was Novell. In my opinion, all the Novells of the world glommed onto Scrum because it was shiny and new and allowed them to call all their bloated and unnecessary project managers "Scrum Masters" and all their wasteful status meetings "Stand-ups." It was just the same old garbage with a different name, but hey, We're Scrumming!