7 ms·

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 -

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
      > I think one problem is that Agile gives a numerical value to how much work has been done: story points. Agile does not. Even a number of the defined methodologies sold as "Agile" do not (Scrum, for instance, does not mention either user stories or story points -- it does indicate that backlog items will have estimates that are less-specific when the item is farther out in the tail of the work queue and more refined when it is near the head of the queue, but doesn't specify the terms in which those estimates should be gathered.) > Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number. If it is fairly stable (which should also be measured if it is going to be used), it is a meaningful number for planning what items are within capacity for a sprint. It may not be meaningful for other purposes even then.
- eropple 11y ago
  > Scrum is, to me, something people pick when managers don't want to manage. This is a really good observation, I think, and lines up with my own experiences--every incapable manager I've ever had thought Scrum was a great idea. The ones I've known have been very linear thinkers with a tendency towards restricted domains of thinking, and Scrum reminds me a little bit of Orwell's "if you can't say it, you can't think it" idea. Scrum gives you a vocabulary that, if you hide in it, requires you to confront many fewer things and make fewer choices. They're almost all the wrong choices, I think, but there are strains of manager that find choices anathema in the first place and so I can see the appeal.
- warfangle 11y ago
  > Don't get me wrong, I like good meetings that result in actionable decisions. Which is what a retrospective _should_ be! "what went wrong, what went right, how can we change our process to keep those wrong things from happening again?" It doesn't necessarily need to be a meeting. The introspection needs to happen, though. No matter what type of process you have - if it's not being constantly reevaluated for efficacy, it's just cargo cult.
  - BenLinders 11y ago
    Very true, it's not the format but the goal of adapting that matters. If you can discuss and fix your problem in a stand-up, do it. If you need to sit down for half an hour, take time for it. If you need 1/2 day to really understand what is happening and get a shared view to decide what to do, plan it. But make sure that you take action.
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.

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
    > I think one problem is that Agile gives a numerical value to how much work has been done: story points. Agile does not. Even a number of the defined methodologies sold as "Agile" do not (Scrum, for instance, does not mention either user stories or story points -- it does indicate that backlog items will have estimates that are less-specific when the item is farther out in the tail of the work queue and more refined when it is near the head of the queue, but doesn't specify the terms in which those estimates should be gathered.) > Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number. If it is fairly stable (which should also be measured if it is going to be used), it is a meaningful number for planning what items are within capacity for a sprint. It may not be meaningful for other purposes even then.
eropple 11y ago
> Scrum is, to me, something people pick when managers don't want to manage. This is a really good observation, I think, and lines up with my own experiences--every incapable manager I've ever had thought Scrum was a great idea. The ones I've known have been very linear thinkers with a tendency towards restricted domains of thinking, and Scrum reminds me a little bit of Orwell's "if you can't say it, you can't think it" idea. Scrum gives you a vocabulary that, if you hide in it, requires you to confront many fewer things and make fewer choices. They're almost all the wrong choices, I think, but there are strains of manager that find choices anathema in the first place and so I can see the appeal.
warfangle 11y ago
> Don't get me wrong, I like good meetings that result in actionable decisions. Which is what a retrospective _should_ be! "what went wrong, what went right, how can we change our process to keep those wrong things from happening again?" It doesn't necessarily need to be a meeting. The introspection needs to happen, though. No matter what type of process you have - if it's not being constantly reevaluated for efficacy, it's just cargo cult.
- BenLinders 11y ago
  Very true, it's not the format but the goal of adapting that matters. If you can discuss and fix your problem in a stand-up, do it. If you need to sit down for half an hour, take time for it. If you need 1/2 day to really understand what is happening and get a shared view to decide what to do, plan it. But make sure that you take action.

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.