8 ms·

Most of the agile problems I've seen have been organizations cargo-culting things they've read, rather than trying to actually be dexterous. Big-A agile versus

Most of the agile problems I've seen have been organizations cargo-culting things they've read, rather than trying to actually be dexterous. Big-A agile versus, well, "agile". Scrum has been the largest offender - squashing discussion in standups, allowing scrum to erode QA process, rote meetings that take 50% of the week, story points and refusing to discuss timetables in hours when absolutely needed, reporting status multiple times, having others estimate tasks who are not doing those tasks, etc. These organizations that have done so have been some of the least agile, and waterfall-esque organizations can even be better. (They planned up front well, they changed a few minor things in the middle maybe, but cut out the overhead).

warfangle 11y ago
I think most teams that implement/try to implement agile/scrum/xp and end up disliking it / failing at it completely miss the point of the retrospective step - and thus, skip that step. Without the retrospective, it's just modified waterfall.
- mpdehaan2 11y ago
  We had them in about half of the scrum shops. The retrospective, in my experience, was yet another meeting where things didn't get done either. "We are having too many meetings" was usually not popular either. Don't get me wrong, I like good meetings that result in actionable decisions. My personal view on scrum is it attempts to trick a software team into micro-managing itself, and it usually results in feeling like kindergarten as a result. The better shops have been "agile", but not "Agile", and just did what worked, and made changes when they needed to. I don't think a retrospective is essentially required, but the ability to change and throw out things that don't work -- and have only the right amount of meetings and to talk about the things that matter rather than a template - is. When a retrospective is to make the team feel they have a voice to make changes, and in reality, nothing changes, that makes the retrospective itself rather soul-crushing theatre, so everybody just says nice things and hopefully nobody gets thrown under the bus when "what could have gone better" is discussed - but often, that still happens. Scrum is, to me, something people pick when managers don't want to manage. I like release-early release-often, MVP (in small doses), see http://michaeldehaan.net/post/118860078737/the-rock-paper-scissors-of-product-management http://michaeldehaan.net/post/118860078737/the-rock-paper-sc..., and many of those concepts. But I also don't like the idea that requirements constantly shift - which means architecture can't plan ahead. I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. If you have a PM that doesn't allow time for such things, it can be rough. (Not everything fits in two week blocks either)
  - wavefunction 11y ago
    >>I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. Sounds like your teams were underestimating task effort. >>If you have a PM that doesn't allow time for such things, it can be rough. Anything's rough with a shitty PM, which is what you've described.
    - mpdehaan2 11y ago
      Nope, the features always won in priority because the project manager / scrumlords would keep it that way, and didn't value the technical plumbing that would actually increase velocity and reduce churn and improve code quality. But yes, it's a people problem.
    - zelos 11y ago
      I think one problem is that Agile gives a numerical value to how much work has been done: story points. Management get addicted to getting more story points, and any push back from developers that would lower the number in the short term is ignored. Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
      - warfangle 11y ago
        That's a problem with management. All of the agile/scrum resources I've read exclaim, in big bold letters, 'THESE ARE NOT METRICS TO EVALUATE PERFORMANCE; THEY ARE FOR ESTIMATION OF EFFORT'
        emodendroket 11y ago
        Head shops have big signs stating that the goods for sale there are strictly for smoking tobacco too.
      - dragonwriter 11y ago
- Nursie 11y ago
  Retrospective has, in my experience, been a candidate for biggest 'agile' time-sink and a great example of how agile 'evangelists' and scrum masters are so inward-looking and process-focussed that they get in the way of work.
  - brlewis 11y ago
    What happens at these retrospectives? I've only been at ones that work. I don't see how you could ask these questions and have it be a time sink: https://www.scrumalliance.org/community/articles/2014/april/key-elements-of-sprint-retrospective https://www.scrumalliance.org/community/articles/2014/april/...
    - Nursie 11y ago
      You clearly haven't worked with people who like the sound of their own voices quite so much as I have. >> What went well during the sprint cycle? >> What went wrong during the sprint cycle? >> What could we do differently to improve? I have had Agile Evangelists, who are supposed to be good at making this stuff streamlined, turn around and say "Everyone needs to come up with five things in each category, then we'll go through and discuss them all, deciding on the most important things to change at the end" In a team that was already too large (15ish people) I watched that eat an entire afternoon and produce no useful output on more than one occasion. In the team I was on (four, five?) it still seemed to take hours. I know, I know, they were probably doing it all wrong, this is just my experience of one workplace. I'm not saying it can't be done right, just that it doesn't seem to be a magic bullet and can devolve into navel-gazing.
      - warfangle 11y ago
        In that case, part of the retrospective should probably be 'these meetings aren't actually solving anything, are actively getting in the way of getting things done. how can we do this meeting differently?' ;)
        Nursie 11y ago
- bunderbunder 11y ago
  And I think that, in turn, might be a symptom of how large organizations often implement scrum. Scrum's meant to be an alternative to - even an inversion of - the traditional way of running software projects. But as it passes through the kaleidoscope of corporate culture, it's all too easy for scrum to just become a layer of makeup on top of the traditional approach. For example, Scrum has a "scrum master" role that is most certainly NOT that of being a project manager. But usually a project manager gets placed in that role, and is naturally going to interpret the role by finding and then exaggerating analogies between it and the stuff they learned in PMP class. In the more traditional structure that the "project manager" role comes from, the PM owns and dictates a lot of the processes that the team follows, including daily meetings and suchlike. This is in direct conflict with the idea that the entire scrum team owns and collaboratively determines the processes that they follow. And that idea is fundamental to the inspect/adapt process that the sprint retrospective is supposed to facilitate.
- kamaal 11y ago
  >>Without the retrospective, it's just modified waterfall. This is true. But retrospectives will never work in any reasonably sized team, the reason is middle managers don't like being told or like being talked about their work in front of everybody, or being told to change something. Ego plays a big role in these things and they don't like being given feedback or advice, especially because these managers tend to think themselves as people in authority as all knowing and in complete control. This is human psychology, developed over thousands of years. Masters never took feedback from slaves, so why should the modern incarnation of the older masters take advice from the current day slaves?
  - jasonwocky 11y ago
    The mindset enshrined in this comment will certainly kill any attempt to be Agile. But while common, thankfully it's not universal.
  - BenLinders 11y ago
    It takes a different mindset to make changes happen (agile or not). If people resists changing their mindset, nothing will happen and we keep struggling. That's a choice I'd rather not do.
- BenLinders 11y ago
  It's even worse, since you don't retrospect it's not even modified. It becomes a fixed process, and non adaptable processes simply do not work.
eropple 11y ago
Scrum has the particularly noxious side effect of driving underground any sort of drive to improve and to learn new things. An engineer in a Scrum team is an engineer, has his or her lane, and is largely expected to stay in it. Learning? Branching out? No, get your promised tickets done this week. That concerns me; while it's possible for a Scrum-based shop to invest in its people, it's not part of Scrum to really do so. And the people are what matter, at the end of the day, so I find it rather dehumanizing. (This is a big part of why I'm moving towards consulting--so I can invest in me more often.)
- wnevets 11y ago
  why is this "Scrum" specific? Sounds like working a 9-5 at most companies regardless of their development process.
  - dragonwriter 11y ago
    > why is this "Scrum" specific? Scrum's pre-committed units of work across the team promotes this; its one of the reasons that many groups prefer flow-based methods (which can support regularly-timed releases simply by shipping the features that are ready at the time of the release cutoff) rather than Scrum's cycle-based method.
    - jasonwocky 11y ago
      I don't see how this is true. If you're building slack into your cycle there should be regular investment time available that a pure flow-based system wouldn't have. If there's no slack in your sprint schedule, well there's your problem.
      - eropple 11y ago
        In my experience, Scrum's work-unit factorization encourages thinking of developers as spherical cows that need no personal development, with slack as a concession to reality that patches the damage Scrum itself causes. And Slack is generally considered to be for technical investment, though, not personal investment. A good manager could think past that, for sure, but I've never encountered a good manager that felt Scrum was good or necessary for their teams.
nimblegorilla 11y ago
I've never seen an agile article recommend rote meetings taking 50% of the week. Anyone even remotely interested in agility would call that an anti-pattern. I don't think it's a case of organizations blindly cargo-culting, but rather an inability to embrace agile.
- s73v3r 11y ago
  Nobody who has any kind of interest in selling or implementing Agile anywhere would. That doesn't mean that the reality of the situation doesn't cause it to happen.
s73v3r 11y ago
"squashing discussion in standups" No, that's one of the really good things it's done. Half the time I'm not involved in any way in those discussions, so moving them out of the status meeting means I don't have to stand around listening to stuff that doesn't concern me.
- mpdehaan2 11y ago
  This makes the meetings basically useless to me, especially when there are so many other meetings important things don't get discussed. It's oppressive.

warfangle 11y ago

I think most teams that implement/try to implement agile/scrum/xp and end up disliking it / failing at it completely miss the point of the retrospective step - and thus, skip that step. Without the retrospective, it's just modified waterfall.

mpdehaan2 11y ago
We had them in about half of the scrum shops. The retrospective, in my experience, was yet another meeting where things didn't get done either. "We are having too many meetings" was usually not popular either. Don't get me wrong, I like good meetings that result in actionable decisions. My personal view on scrum is it attempts to trick a software team into micro-managing itself, and it usually results in feeling like kindergarten as a result. The better shops have been "agile", but not "Agile", and just did what worked, and made changes when they needed to. I don't think a retrospective is essentially required, but the ability to change and throw out things that don't work -- and have only the right amount of meetings and to talk about the things that matter rather than a template - is. When a retrospective is to make the team feel they have a voice to make changes, and in reality, nothing changes, that makes the retrospective itself rather soul-crushing theatre, so everybody just says nice things and hopefully nobody gets thrown under the bus when "what could have gone better" is discussed - but often, that still happens. Scrum is, to me, something people pick when managers don't want to manage. I like release-early release-often, MVP (in small doses), see http://michaeldehaan.net/post/118860078737/the-rock-paper-scissors-of-product-management http://michaeldehaan.net/post/118860078737/the-rock-paper-sc..., and many of those concepts. But I also don't like the idea that requirements constantly shift - which means architecture can't plan ahead. I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. If you have a PM that doesn't allow time for such things, it can be rough. (Not everything fits in two week blocks either)
- wavefunction 11y ago
  >>I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. Sounds like your teams were underestimating task effort. >>If you have a PM that doesn't allow time for such things, it can be rough. Anything's rough with a shitty PM, which is what you've described.
  - mpdehaan2 11y ago
    Nope, the features always won in priority because the project manager / scrumlords would keep it that way, and didn't value the technical plumbing that would actually increase velocity and reduce churn and improve code quality. But yes, it's a people problem.
  - zelos 11y ago
    I think one problem is that Agile gives a numerical value to how much work has been done: story points. Management get addicted to getting more story points, and any push back from developers that would lower the number in the short term is ignored. Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.
    - warfangle 11y ago
      That's a problem with management. All of the agile/scrum resources I've read exclaim, in big bold letters, 'THESE ARE NOT METRICS TO EVALUATE PERFORMANCE; THEY ARE FOR ESTIMATION OF EFFORT'
      - emodendroket 11y ago
        Head shops have big signs stating that the goods for sale there are strictly for smoking tobacco too.
    - dragonwriter 11y ago
Nursie 11y ago
Retrospective has, in my experience, been a candidate for biggest 'agile' time-sink and a great example of how agile 'evangelists' and scrum masters are so inward-looking and process-focussed that they get in the way of work.
- brlewis 11y ago
  What happens at these retrospectives? I've only been at ones that work. I don't see how you could ask these questions and have it be a time sink: https://www.scrumalliance.org/community/articles/2014/april/key-elements-of-sprint-retrospective https://www.scrumalliance.org/community/articles/2014/april/...
  - Nursie 11y ago
    You clearly haven't worked with people who like the sound of their own voices quite so much as I have. >> What went well during the sprint cycle? >> What went wrong during the sprint cycle? >> What could we do differently to improve? I have had Agile Evangelists, who are supposed to be good at making this stuff streamlined, turn around and say "Everyone needs to come up with five things in each category, then we'll go through and discuss them all, deciding on the most important things to change at the end" In a team that was already too large (15ish people) I watched that eat an entire afternoon and produce no useful output on more than one occasion. In the team I was on (four, five?) it still seemed to take hours. I know, I know, they were probably doing it all wrong, this is just my experience of one workplace. I'm not saying it can't be done right, just that it doesn't seem to be a magic bullet and can devolve into navel-gazing.
    - warfangle 11y ago
      In that case, part of the retrospective should probably be 'these meetings aren't actually solving anything, are actively getting in the way of getting things done. how can we do this meeting differently?' ;)
      - Nursie 11y ago
bunderbunder 11y ago
And I think that, in turn, might be a symptom of how large organizations often implement scrum. Scrum's meant to be an alternative to - even an inversion of - the traditional way of running software projects. But as it passes through the kaleidoscope of corporate culture, it's all too easy for scrum to just become a layer of makeup on top of the traditional approach. For example, Scrum has a "scrum master" role that is most certainly NOT that of being a project manager. But usually a project manager gets placed in that role, and is naturally going to interpret the role by finding and then exaggerating analogies between it and the stuff they learned in PMP class. In the more traditional structure that the "project manager" role comes from, the PM owns and dictates a lot of the processes that the team follows, including daily meetings and suchlike. This is in direct conflict with the idea that the entire scrum team owns and collaboratively determines the processes that they follow. And that idea is fundamental to the inspect/adapt process that the sprint retrospective is supposed to facilitate.
kamaal 11y ago
>>Without the retrospective, it's just modified waterfall. This is true. But retrospectives will never work in any reasonably sized team, the reason is middle managers don't like being told or like being talked about their work in front of everybody, or being told to change something. Ego plays a big role in these things and they don't like being given feedback or advice, especially because these managers tend to think themselves as people in authority as all knowing and in complete control. This is human psychology, developed over thousands of years. Masters never took feedback from slaves, so why should the modern incarnation of the older masters take advice from the current day slaves?
- jasonwocky 11y ago
  The mindset enshrined in this comment will certainly kill any attempt to be Agile. But while common, thankfully it's not universal.
- BenLinders 11y ago
  It takes a different mindset to make changes happen (agile or not). If people resists changing their mindset, nothing will happen and we keep struggling. That's a choice I'd rather not do.
BenLinders 11y ago
It's even worse, since you don't retrospect it's not even modified. It becomes a fixed process, and non adaptable processes simply do not work.

eropple 11y ago

Scrum has the particularly noxious side effect of driving underground any sort of drive to improve and to learn new things. An engineer in a Scrum team is an engineer, has his or her lane, and is largely expected to stay in it. Learning? Branching out? No, get your promised tickets done this week. That concerns me; while it's possible for a Scrum-based shop to invest in its people, it's not part of Scrum to really do so. And the people are what matter, at the end of the day, so I find it rather dehumanizing. (This is a big part of why I'm moving towards consulting--so I can invest in me more often.)

wnevets 11y ago
why is this "Scrum" specific? Sounds like working a 9-5 at most companies regardless of their development process.
- dragonwriter 11y ago
  > why is this "Scrum" specific? Scrum's pre-committed units of work across the team promotes this; its one of the reasons that many groups prefer flow-based methods (which can support regularly-timed releases simply by shipping the features that are ready at the time of the release cutoff) rather than Scrum's cycle-based method.
  - jasonwocky 11y ago
    I don't see how this is true. If you're building slack into your cycle there should be regular investment time available that a pure flow-based system wouldn't have. If there's no slack in your sprint schedule, well there's your problem.
    - eropple 11y ago
      In my experience, Scrum's work-unit factorization encourages thinking of developers as spherical cows that need no personal development, with slack as a concession to reality that patches the damage Scrum itself causes. And Slack is generally considered to be for technical investment, though, not personal investment. A good manager could think past that, for sure, but I've never encountered a good manager that felt Scrum was good or necessary for their teams.

nimblegorilla 11y ago

I've never seen an agile article recommend rote meetings taking 50% of the week. Anyone even remotely interested in agility would call that an anti-pattern. I don't think it's a case of organizations blindly cargo-culting, but rather an inability to embrace agile.

s73v3r 11y ago
Nobody who has any kind of interest in selling or implementing Agile anywhere would. That doesn't mean that the reality of the situation doesn't cause it to happen.

s73v3r 11y ago

"squashing discussion in standups" No, that's one of the really good things it's done. Half the time I'm not involved in any way in those discussions, so moving them out of the status meeting means I don't have to stand around listening to stuff that doesn't concern me.

mpdehaan2 11y ago
This makes the meetings basically useless to me, especially when there are so many other meetings important things don't get discussed. It's oppressive.