6 ms·

Scrum proponents (a label I would tentatively apply to myself) would tell you that 'you're doing it wrong' but unfortunately a point-by-point reply to this arti

by cechner 10y ago

Scrum proponents (a label I would tentatively apply to myself) would tell you that 'you're doing it wrong' but unfortunately a point-by-point reply to this article would detract from the general problem here: Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else If youre working on a project where it is important that you have as-accurate-as-is-realistic an idea of the size of the project, or more specifically your progress through that project, then I can't see how a methodology could be any simpler. If having a good idea of the size of your project over time and your progress through that project are not very important from a management perspective, the Scrum artefacts will seem like, and will probably in fact be, needless overhead. 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.

cechner 10y ago
oh and I have attended some of those expensive Scrum 1-week courses and saw the darker side of that community - it definitely has a cult following that give it a bad name, but I've been to similar conventions around design patterns, object-oriented and (to a lesser degree) functional programming so I think that the community problem is not particular to Scrum.
- bbarn 10y ago
  Those with the loudest voices simply have the loudest voices, be they right or wrong.
- wott 10y ago
  The problem is communities.
  - akvadrako 10y ago
    interesting. Do you have an alternative in mind?
humanrebar 10y ago
> 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. Scrum is actually part of the problem, IMO. I've seen many teams turn scrum into a hammer and treat all future problems as nails. Example problem: The foobar story has failed failed for the third sprint in a row. Likely discussed in retrospective (plausibly good ideas, mind you): - We need to break down stories more before we estimate them. - Or we need to stop underestimating foobar stories. - Or we need to focus on unblocking subtasks related to foobar stories. Probably unconsidered: - The foobar code is a mess and needs to be refactored. - Or the foobar subsystem is too coupled to the Fizzbuzz subsystem. - Or the need for some developer tools to increase productivity in the foobar ecosystem. Since scrum is methodology oriented, methodology is the first tool teams reach for when a problem is encountered. And I see this after team leads make it explicitly OK to discuss technical subjects in retrospectives. I'm not a psychologist, so I can't describe why this phenomenon happens, but I see it regularly.
- altcognito 10y ago
  All of the items you listed under unconsidered should be brought up by the dev team. If the dev team is uncomfortable bringing them up, then that's probably a sign of friction between the dev team and management, which is really common.
- the_fury 10y ago
  I've routinely brought up all of the unconsidered comments in retrospectives. Retros are all about making sprints better, and talking about technical problems is integral to that.
bhaak 10y ago
I've seen the "you're doing it wrong" argument so many times (I applied it myself a few times). Scrum is complex and not always possible to follow exactly, so this is to be expected but it makes me wonder, how many successful projects are out there that are following the true Scrum methodology? My guess is that it's a few more than the classic waterfall but I still seem to see far more failure than success stories.
- blub 10y ago
  The very idea of a one-size-fits-all process is unrealistic IMO. Something will always be customised in practice. Regarding success stories, it might be that process doesn't play such a critical role as long as solid engineering techniques are used and the team is competent.
  - bhaak 10y ago
    If your team is competent and solid engineering techniques are being used, you already have a well working process. Forcing any methodology on this will likely result in a deterioration. All those methodologies are for the less stellar programming teams, to get consistent results from those (also to a lesser degree to make good and bad programmers work well along each other). Because you can't always get the best programmers. If Scrum would only work well with good programmers, it would be next to useless.
- xorblurb 10y ago
  Successful big waterfall engineering projects where waterfall is actually applied exist. Want to construct a bridge or a rocket, design a microprocessor? You are not going to do that with "stories". It remains to be seen if big Scrum engineering projects where Scrum is actually applied even exist. I can't even think about one on the top of my head. I'm not even sure Scrum is that well defined for us to be able to judge if is correctly applied or not. And it's yet another story to judge if they are successful or not. In the end it does not matter much. The theoretical vision that nobody ever uses has almost no interest if you are concerned with real world efficiencies.
dasmoth 10y ago
>>> Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else There's slightly more to it than that: it also encodes an assumption that you're working with a single fairly-tightly-integrated group (with synchronisation points at least daily). It's possible that this helps with estimation and scheduling -- it's a lot less clear that it helps get the best outcome in other respects.
- cechner 10y ago
  I agree, it is often not the best approach. But many situations demand a well defined approach to estimation and although the OP tried to preempt this, he didnt provide an alternative
  - dasmoth 10y ago
    I reckon most experienced coders can cope with estimation when it's justified (i.e. "can we realistically get this done before <specific, real and externally-imposed, deadline>? And if not, is there a useful subset we can manage?"). The bigger problems come when estimation isn't about keeping promises, but rather a part of some form of scientific management aimed at "getting velocity up". There's also something of an uncertainty principle here -- more precision of estimation is possible, at the expense of increased expected timescales (partly due to padding, partly due to picking lower-risk approaches).
    - cechner 10y ago
      if its being used to 'get velocity up' instead of measuring velocity then its not being done right. I personally think estimating projects is one of the most difficult things about this industry. Especially if we're talking about delivering many calendar-months worth of effort for a team , unless its just a variant on some other project[s] the team is well experienced at
deleted 10y ago
[deleted]
crdoconnor 10y ago
>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.
afroisalreadyin 10y ago
I agree that Scrum is dead simple, but that doesn't mean it delivers sensible estimates, or allows you to get somewhere with less effort than some other methodology. You might end up doing more (and worse) work because Scrum is trying to be too simple and linear, which I argue is the case in the post. But it's simple, I definitely agree. Regarding development: My main point is that Scrum leans towards agile methods such as XP (testing, CI etc), but it also sucks the time necessary to do those things well. The time Scrum takes off of the devs' working hours could much better be spent on those.
specialist 10y ago
"Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else." More like wandering in the desert, hoping you find the promised land. Been thru scrum master training 3 times, been on many "agile" teams. I've never heard this rationalization. Rather, a common justification for "agile" was you always have a working product. Which might be nice if things worked out that way. Also, PMI style critical path worked just fine for figuring out that "straight line". Scrum and "agile" democratized project management, empowering every poseur to claim expertise and ability. Whereas PMI required real effort to learn and master, Scrum flavored "self help" books can be flipped thru before you finish your coffee and then safely stored in plain sight on a book shelf, never to be touched again, allowing said poseur to claim the daily mutant chaotic dysfunctional mismanagement that they've always done is now "agile".
- cechner 10y ago
  If you're objecting to people who treat scrum (or any project management tool) as a one-stop-shop that will cure all ills I agree with you, but nobody here is saying that. If you are objecting to defining the scope as small tasks and measuring your progress through that over time, then continually re-evaluating this scope as requirements change, then I think you are not working in an environment that would benefit from this kind of tool. Its just a pragmatic set of guidelines, and objecting to it with such ridiculous vitriol makes you sound as foolish as the people I think you're objecting to.
  - specialist 10y ago
    My goal is to ship products that people will buy and use. Scrum and "agile" has only been an impediment. "with such ridiculous vitriol" Emperor, little boy, no clothes. It's thankless work. In opposition, defenders of Scrum et al use the No True Scotsman's fallacy. Because those of us who have tried and failed are just morons.
- UK-AL 10y ago
  Considering failure rate of PMI led projects is even higher then agile projects for software. I really wouldn't hold that up that as the way to go.

by cechner 10y ago

cechner 10y ago

oh and I have attended some of those expensive Scrum 1-week courses and saw the darker side of that community - it definitely has a cult following that give it a bad name, but I've been to similar conventions around design patterns, object-oriented and (to a lesser degree) functional programming so I think that the community problem is not particular to Scrum.

bbarn 10y ago
Those with the loudest voices simply have the loudest voices, be they right or wrong.
wott 10y ago
The problem is communities.
- akvadrako 10y ago
  interesting. Do you have an alternative in mind?

humanrebar 10y ago

> 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. Scrum is actually part of the problem, IMO. I've seen many teams turn scrum into a hammer and treat all future problems as nails. Example problem: The foobar story has failed failed for the third sprint in a row. Likely discussed in retrospective (plausibly good ideas, mind you): - We need to break down stories more before we estimate them. - Or we need to stop underestimating foobar stories. - Or we need to focus on unblocking subtasks related to foobar stories. Probably unconsidered: - The foobar code is a mess and needs to be refactored. - Or the foobar subsystem is too coupled to the Fizzbuzz subsystem. - Or the need for some developer tools to increase productivity in the foobar ecosystem. Since scrum is methodology oriented, methodology is the first tool teams reach for when a problem is encountered. And I see this after team leads make it explicitly OK to discuss technical subjects in retrospectives. I'm not a psychologist, so I can't describe why this phenomenon happens, but I see it regularly.

altcognito 10y ago
All of the items you listed under unconsidered should be brought up by the dev team. If the dev team is uncomfortable bringing them up, then that's probably a sign of friction between the dev team and management, which is really common.
the_fury 10y ago
I've routinely brought up all of the unconsidered comments in retrospectives. Retros are all about making sprints better, and talking about technical problems is integral to that.

bhaak 10y ago

I've seen the "you're doing it wrong" argument so many times (I applied it myself a few times). Scrum is complex and not always possible to follow exactly, so this is to be expected but it makes me wonder, how many successful projects are out there that are following the true Scrum methodology? My guess is that it's a few more than the classic waterfall but I still seem to see far more failure than success stories.

blub 10y ago
The very idea of a one-size-fits-all process is unrealistic IMO. Something will always be customised in practice. Regarding success stories, it might be that process doesn't play such a critical role as long as solid engineering techniques are used and the team is competent.
- bhaak 10y ago
  If your team is competent and solid engineering techniques are being used, you already have a well working process. Forcing any methodology on this will likely result in a deterioration. All those methodologies are for the less stellar programming teams, to get consistent results from those (also to a lesser degree to make good and bad programmers work well along each other). Because you can't always get the best programmers. If Scrum would only work well with good programmers, it would be next to useless.
xorblurb 10y ago
Successful big waterfall engineering projects where waterfall is actually applied exist. Want to construct a bridge or a rocket, design a microprocessor? You are not going to do that with "stories". It remains to be seen if big Scrum engineering projects where Scrum is actually applied even exist. I can't even think about one on the top of my head. I'm not even sure Scrum is that well defined for us to be able to judge if is correctly applied or not. And it's yet another story to judge if they are successful or not. In the end it does not matter much. The theoretical vision that nobody ever uses has almost no interest if you are concerned with real world efficiencies.

dasmoth 10y ago

>>> Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else There's slightly more to it than that: it also encodes an assumption that you're working with a single fairly-tightly-integrated group (with synchronisation points at least daily). It's possible that this helps with estimation and scheduling -- it's a lot less clear that it helps get the best outcome in other respects.

cechner 10y ago
I agree, it is often not the best approach. But many situations demand a well defined approach to estimation and although the OP tried to preempt this, he didnt provide an alternative
- dasmoth 10y ago
  I reckon most experienced coders can cope with estimation when it's justified (i.e. "can we realistically get this done before <specific, real and externally-imposed, deadline>? And if not, is there a useful subset we can manage?"). The bigger problems come when estimation isn't about keeping promises, but rather a part of some form of scientific management aimed at "getting velocity up". There's also something of an uncertainty principle here -- more precision of estimation is possible, at the expense of increased expected timescales (partly due to padding, partly due to picking lower-risk approaches).
  - cechner 10y ago
    if its being used to 'get velocity up' instead of measuring velocity then its not being done right. I personally think estimating projects is one of the most difficult things about this industry. Especially if we're talking about delivering many calendar-months worth of effort for a team , unless its just a variant on some other project[s] the team is well experienced at

deleted 10y ago

[deleted]

crdoconnor 10y ago

>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.

afroisalreadyin 10y ago

I agree that Scrum is dead simple, but that doesn't mean it delivers sensible estimates, or allows you to get somewhere with less effort than some other methodology. You might end up doing more (and worse) work because Scrum is trying to be too simple and linear, which I argue is the case in the post. But it's simple, I definitely agree. Regarding development: My main point is that Scrum leans towards agile methods such as XP (testing, CI etc), but it also sucks the time necessary to do those things well. The time Scrum takes off of the devs' working hours could much better be spent on those.

specialist 10y ago

"Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else." More like wandering in the desert, hoping you find the promised land. Been thru scrum master training 3 times, been on many "agile" teams. I've never heard this rationalization. Rather, a common justification for "agile" was you always have a working product. Which might be nice if things worked out that way. Also, PMI style critical path worked just fine for figuring out that "straight line". Scrum and "agile" democratized project management, empowering every poseur to claim expertise and ability. Whereas PMI required real effort to learn and master, Scrum flavored "self help" books can be flipped thru before you finish your coffee and then safely stored in plain sight on a book shelf, never to be touched again, allowing said poseur to claim the daily mutant chaotic dysfunctional mismanagement that they've always done is now "agile".

cechner 10y ago
If you're objecting to people who treat scrum (or any project management tool) as a one-stop-shop that will cure all ills I agree with you, but nobody here is saying that. If you are objecting to defining the scope as small tasks and measuring your progress through that over time, then continually re-evaluating this scope as requirements change, then I think you are not working in an environment that would benefit from this kind of tool. Its just a pragmatic set of guidelines, and objecting to it with such ridiculous vitriol makes you sound as foolish as the people I think you're objecting to.
- specialist 10y ago
  My goal is to ship products that people will buy and use. Scrum and "agile" has only been an impediment. "with such ridiculous vitriol" Emperor, little boy, no clothes. It's thankless work. In opposition, defenders of Scrum et al use the No True Scotsman's fallacy. Because those of us who have tried and failed are just morons.
UK-AL 10y ago
Considering failure rate of PMI led projects is even higher then agile projects for software. I really wouldn't hold that up that as the way to go.