5 ms·

There is a step somewhere in there where we waste 30 minutes playing "agile poker" and arguing about the number of story points required to close vim. The whol

There is a step somewhere in there where we waste 30 minutes playing "agile poker" and arguing about the number of story points required to close vim. The whole thing is followed up with a two hour retrospective where we pat ourselves on the back for increasing velocity (due to assigning story points to closing vim). Bonus points if you then are asked to map that back to actual hours so we can estimate completely unrelated future tasks while simultaneously remembering that we don't estimate in hours.

woutr_be 7y ago
It saddens me to say, but this is so familiar. Especially working in a big corporate company where they hire scrum masters who just follow the scrum guide.
- matwood 7y ago
  Scrum has a built in self destruct method - the retrospective. With a little maneuvering, the team should be able to remove most of the annoying things about scrum by using the retrospective. Obviously you can't go scorched earth and drop all the annoying bits at once. But, if scrum is really being followed (I know this is also part of the problem), the retro should allow the team to change the process over time.
  - woutr_be 7y ago
    This obviously only works when your scrum master is willing to take feedback on scrum processes. Which, with most scrum masters is not the case, you’re essentially telling them they’re doing a bad job, and it usually hurts their ego.
    - BenLinders 7y ago
      Something is seriously wrong if the Scrum master doesn't take feedback. That goes against the Agile values and principles.
      - woutr_be 7y ago
        I honestly haven't met many scrum masters who don't just preach the scrum guide. Even if the team is struggling with the way we do Agile, the scrum master will just continue to force the scrum guide onto the team. What I currently see is that our scrum master has sold the business on the agile way, so if a developer complains about it, there's something wrong with the developer. It's probably just a bad scrum master, but I've met multiple of those.
  - mumblemumble 7y ago
    I found that, being a special time set aside specifically for team arguments about how many angels can dance on the head of a pin, the retrospective tends to produce a much more literal version of self-destruction. I showed up long after they implemented it, so I'm not sure how they got there, but the most well-functioning Scrum team I ever participated in had effectively designated the nominal Scrum Master as a BDFL. The retrospective then became a shorter sort of town hall meeting where everyone aired their opinions, but, since we had a BDFL, we had no need to burn energy on consensus-building. Sadly, things quickly went to hell after she left and the team reverted to a more traditional consensus-oriented approach.
  - ljw1001 7y ago
    You can't remove a professional scrum-master who does nothing else in the retrospective as the scrum-master is running the retrospective.
    - woutr_be 7y ago
      Exactly, and those scrum-masters are usually good at talking and getting the business on their sides. There's literally no way to change those processes without making yourself look bad.
    - BenLinders 7y ago
      Disagree: the team owns the retrospective, not the Scrum master. If team members aren't happy with what the Scrum master is doing, that should be addressed in the retrospective.
      - woutr_be 7y ago
        And this is coming from your own personal experience? I've never been in a scrum team where we as developers had any say in what the scrum master was doing. The most we could do was retrospectives with other developers, and try to improve there. However that's rarely enough to make a business work.
  - BenLinders 7y ago
    I would not call it self destruct, rather reconstruct or adjust. If the way the team uses Scrum isn't effective, then the retrospective can be used to explore issues and adjust the way of working.
Rooster61 7y ago
You forgot the conversation on the way back from the retrospective about how velocity is a bullshit indicator of actual productivity and we aren't doing agile correctly at this company.
- deleted 7y ago
  [deleted]

woutr_be 7y ago

It saddens me to say, but this is so familiar. Especially working in a big corporate company where they hire scrum masters who just follow the scrum guide.

matwood 7y ago
Scrum has a built in self destruct method - the retrospective. With a little maneuvering, the team should be able to remove most of the annoying things about scrum by using the retrospective. Obviously you can't go scorched earth and drop all the annoying bits at once. But, if scrum is really being followed (I know this is also part of the problem), the retro should allow the team to change the process over time.
- woutr_be 7y ago
  This obviously only works when your scrum master is willing to take feedback on scrum processes. Which, with most scrum masters is not the case, you’re essentially telling them they’re doing a bad job, and it usually hurts their ego.
  - BenLinders 7y ago
    Something is seriously wrong if the Scrum master doesn't take feedback. That goes against the Agile values and principles.
    - woutr_be 7y ago
      I honestly haven't met many scrum masters who don't just preach the scrum guide. Even if the team is struggling with the way we do Agile, the scrum master will just continue to force the scrum guide onto the team. What I currently see is that our scrum master has sold the business on the agile way, so if a developer complains about it, there's something wrong with the developer. It's probably just a bad scrum master, but I've met multiple of those.
- mumblemumble 7y ago
  I found that, being a special time set aside specifically for team arguments about how many angels can dance on the head of a pin, the retrospective tends to produce a much more literal version of self-destruction. I showed up long after they implemented it, so I'm not sure how they got there, but the most well-functioning Scrum team I ever participated in had effectively designated the nominal Scrum Master as a BDFL. The retrospective then became a shorter sort of town hall meeting where everyone aired their opinions, but, since we had a BDFL, we had no need to burn energy on consensus-building. Sadly, things quickly went to hell after she left and the team reverted to a more traditional consensus-oriented approach.
- ljw1001 7y ago
  You can't remove a professional scrum-master who does nothing else in the retrospective as the scrum-master is running the retrospective.
  - woutr_be 7y ago
    Exactly, and those scrum-masters are usually good at talking and getting the business on their sides. There's literally no way to change those processes without making yourself look bad.
  - BenLinders 7y ago
    Disagree: the team owns the retrospective, not the Scrum master. If team members aren't happy with what the Scrum master is doing, that should be addressed in the retrospective.
    - woutr_be 7y ago
      And this is coming from your own personal experience? I've never been in a scrum team where we as developers had any say in what the scrum master was doing. The most we could do was retrospectives with other developers, and try to improve there. However that's rarely enough to make a business work.
- BenLinders 7y ago
  I would not call it self destruct, rather reconstruct or adjust. If the way the team uses Scrum isn't effective, then the retrospective can be used to explore issues and adjust the way of working.

Rooster61 7y ago

You forgot the conversation on the way back from the retrospective about how velocity is a bullshit indicator of actual productivity and we aren't doing agile correctly at this company.

deleted 7y ago
[deleted]