4 ms·

>Scrum is not opinionated about the actual development methodology so claims about how it affects the code that is written are themselves a bad smell IMO. Pret

>Scrum is not opinionated about the actual development methodology so claims about how it affects the code that is written are themselves a bad smell IMO. Pretty much every kind of deadline driven development ramps up technical debt. Scrum certainly isn't the worst in this respect (developers make their own deadlines, and conscientious ones will build the time in), but the emphasis on commitment and the pressure to deliver at the end of the sprint puts pressure on developers to cut corners. The worst part though, is that the product owner is usually non-technical and will deprioritize stories to clean up technical debt as a result. IMO for any kind of development methodology to work it must have an opinion on technical debt. Scrum doesn't.

UK-AL 10y ago
Sprints are meant to be based on the previous sprints velocity, so any commitment should get smaller and smaller until you can do it without forcing it.
cechner 10y ago
if pressure is ramping up and quality down the sprints arent serving their purpose. One of the few defining characteristics of scrum is that the developers define how much they can achieve, and this estimation is improved over time. If this is not happening there is something else wrong with the culture and Scrum is being used as a scapegoat.
- crdoconnor 10y ago
  A few defining characteristics of scrum that lead to overly optimistic predictions: * The prediction is made in a meeting while your head is "out of the code". * The prediction is made in a group setting, rendering the decisions more easily subject to peer pressure and groupthink. * The prediction is made up to 2/4 weeks in advance of actually doing the work. * The prediction is made without risk of overshoot attached. Risk is critical metric which scrum conceals. And the main defining characteristic of scrum that leads to pressure, after all of that unwarranted optimism: * The prediction is designated as a commitment.
  - cechner 10y ago
    It sounds as though you objecting to being required to give any estimate at all.
    - wott 10y ago
      I don't know how you manage to read this. He seems to say he would like to be in a situation where he has the means to give good estimate but scrum forbids it and forces to give random and biased estimations.
      - cechner 10y ago
        can we infer that he would like to give his estimates: * while he is actually writing the code (so not up front) * not in a group setting but as an individual, so either one person estimating the whole thing or each person giving different estimates * (third point same as first, dont want to estimate up front) * must incorporate what is often called 'contingency' (which is actually what the whole point of measuring velocity is for!) * and the final point - he doesn't want to have to commit to it how can you _not_ read this into it?
        Chris2048 10y ago
        Assume each person giving different estimates for their own work, but not up front - ongoing as code is written. How is that the same as not being "required to give any estimate at all"? > he doesn't want to have to commit to it why not? an estimate is an estimate, not a commitment. Committing to an estimate makes it a commitment, not an estimate. I might expect a dice roll to be 3.5, I'm not committing to the next roll being 3.5 - analysis should inform policy, in this case expectations informing stated commitments, but the two are not the same. Furthermore, this bullet point actually takes the quote out of context - He specifically doesn't want to commit to the estimate produced under the previous conditions, not that he won't commit to any estimate. The difference is choosing to commit to an estimate you have high confidence in, versus any estimate given automatically being a commitment (where estimates may be required on demand).

UK-AL 10y ago

Sprints are meant to be based on the previous sprints velocity, so any commitment should get smaller and smaller until you can do it without forcing it.

cechner 10y ago

if pressure is ramping up and quality down the sprints arent serving their purpose. One of the few defining characteristics of scrum is that the developers define how much they can achieve, and this estimation is improved over time. If this is not happening there is something else wrong with the culture and Scrum is being used as a scapegoat.

crdoconnor 10y ago
A few defining characteristics of scrum that lead to overly optimistic predictions: * The prediction is made in a meeting while your head is "out of the code". * The prediction is made in a group setting, rendering the decisions more easily subject to peer pressure and groupthink. * The prediction is made up to 2/4 weeks in advance of actually doing the work. * The prediction is made without risk of overshoot attached. Risk is critical metric which scrum conceals. And the main defining characteristic of scrum that leads to pressure, after all of that unwarranted optimism: * The prediction is designated as a commitment.
- cechner 10y ago
  It sounds as though you objecting to being required to give any estimate at all.
  - wott 10y ago
    I don't know how you manage to read this. He seems to say he would like to be in a situation where he has the means to give good estimate but scrum forbids it and forces to give random and biased estimations.
    - cechner 10y ago
      can we infer that he would like to give his estimates: * while he is actually writing the code (so not up front) * not in a group setting but as an individual, so either one person estimating the whole thing or each person giving different estimates * (third point same as first, dont want to estimate up front) * must incorporate what is often called 'contingency' (which is actually what the whole point of measuring velocity is for!) * and the final point - he doesn't want to have to commit to it how can you _not_ read this into it?
      - Chris2048 10y ago
        Assume each person giving different estimates for their own work, but not up front - ongoing as code is written. How is that the same as not being "required to give any estimate at all"? > he doesn't want to have to commit to it why not? an estimate is an estimate, not a commitment. Committing to an estimate makes it a commitment, not an estimate. I might expect a dice roll to be 3.5, I'm not committing to the next roll being 3.5 - analysis should inform policy, in this case expectations informing stated commitments, but the two are not the same. Furthermore, this bullet point actually takes the quote out of context - He specifically doesn't want to commit to the estimate produced under the previous conditions, not that he won't commit to any estimate. The difference is choosing to commit to an estimate you have high confidence in, versus any estimate given automatically being a commitment (where estimates may be required on demand).