6 ms·

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 connection

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.

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.