4 ms·

I've worked agile for quite some years now. Please repeat after me: 1. The sprint goal is not a contract. The mental and physical well being of the developers

I've worked agile for quite some years now. Please repeat after me: 1. The sprint goal is not a contract. The mental and physical well being of the developers always takes precedence over the sprint goal. The sprint goal is merely a guidance. 2. Not completing all stories at the end of the sprint should not make you feel bad. A sprint is always filled using estimates which never will be correct, and are often way to ambitious and not considering severe issues. 3. Retrospective meetings should primarily allow developers to say how they could work better. It's not an occasion for the the product owner or the Scrum Master to belittle developers for mistakes and missed goals.

jwestbury 3y ago
> 3. Retrospective meetings should primarily allow developers to say how they could work better. It's not an occasion for the the product owner or the Scrum Master to belittle developers for mistakes and missed goals. When I was running retros, I created a document which recorded reasons tasks weren't finished. If you had more than 1-2 points left at the end of a sprint, you edited the doc, and either added a new reason, or just increased the tally on an existing reason. The doc didn't have edit history enabled, so it was (mostly) anonymous. We'd review it every retro, and look for ways we could improve. A huge problem was not accounting for personal issues. We had people who were trying to take an entire normal load of tasks during the week when they were moving to a new apartment. We had true unlimited time off at this company, so there was no reason not to just take a day off. So, new explicit guideline: Take time off for your personal life. Stop trying to cram in a full week's work when you know you'll be distracted. The team will get by fine without you, and you'll be happier when you come back. The trouble, of course, is that these sorts of things require a high level of respect amongst the team, and sometimes that's missing. So, really, you need to work on culture before you can adopt these tools.
agloe_dreams 3y ago
lol on #2: We had a funny situation where leaders were mad that tickets were getting carried over every sprint. We would then say that the velocity works out to the original planned velocity, the reason tickets would get carried over was that the devs would complete their tasks, then pull in tickets while the tasks went to QA for verification. Next sprint's ticket that would get pulled in would get done when it was supposed to: Next sprint. The leaders were like "Why are you pulling in tickets you can't complete!?!" Which led to the hilarious exchange of trying to explain that they stated that devs can only work on tickets pulled in, but because QA happens before the ticket gets marked as done, the only way no work flows over is if the dev, after handing their last ticket to QA, sat on their hands for two days. They just couldn't wrap their head around it.
- peteradio 3y ago
  Lol, honestly how fucking stupid. Here you have managers failing to understand the most fundamental basic part of their job.
cosmotic 3y ago
It's remarkable how many people hurt themselves and their teams by considering sprint goals as must-complete. "We must complete the work we committed to!"
- sys42590 3y ago
  There are so many reasons sprint goals are abused, it can be it bad management culture trickling down, people in charge not understanding even the simplest points of the Agile Manifesto, or even weird companywide KPIs linked to Scrum or Kanban completion metrics that you can so easily pull out of most agile management software (e.g. Jira).
  - peteradio 3y ago
    Our scrum lord told us his bonus is tied to these metrics so you can guess why managers and scrum lords behave the way they do in spite of the manifesto. Throw the manifesto out the window its complete bullshit because they say one thing and do another.
    - sys42590 3y ago
      Indeed, Scrum looks nice in theory, and can be nice in practice (from my personal experience), because in theory it is about self-organizing of teams and collaboration with the product owner. In practice however in so many companies it is totally twisted and used as a method of control, and applying pressure, as you said by e.g. making metrics bonus relevant.
    - jacknews 3y ago
      "scrum lord" lol. Scrum is great when it's run by and for the dev team. As soon as it's co-opted by management as an easy way to 'inspect' performance, as a developer confessional/inquisition, etc, it becomes a living nightmare.
bick_nyers 3y ago
Sounds like every team also needs a therapist to do agile correctly. Only half joking!
- sys42590 3y ago
  The issue is that agile was once (back in the days of the manifesto) a grass roots effort to make life for developers better, but in many companies it has been perverted and twisted from a framework for collaboration and self-organization to controlling and pressuring development teams in a fortnight cycle. Of course this gives Scrum a bad rep. May an on-site therapist help more than just replacing attrition? If it would (in terms of net profits), many companies would have started to do so.
thiht 3y ago
> The sprint goal is not a contract I kinda disagree with that. We recently switched to a sprint mode « undercommit, overdeliver ». The objective is to not commit to a lot for the duration of the sprint (ie. something we 100% know we can achieve), but we commit strongly to it. And this gives us time to handle production issues if any, or to deliver on « surprise » features of we have time to kill, or work on DX, CI, etc. We need this « strong commitment » because we’re an early stage startup, and our sales need to know exactly what to sell to the clients, what will be available later this week. We also take 1h every Friday to demo our work, _deployed in prod_. No demo in local/dev.

jwestbury 3y ago

> 3. Retrospective meetings should primarily allow developers to say how they could work better. It's not an occasion for the the product owner or the Scrum Master to belittle developers for mistakes and missed goals. When I was running retros, I created a document which recorded reasons tasks weren't finished. If you had more than 1-2 points left at the end of a sprint, you edited the doc, and either added a new reason, or just increased the tally on an existing reason. The doc didn't have edit history enabled, so it was (mostly) anonymous. We'd review it every retro, and look for ways we could improve. A huge problem was not accounting for personal issues. We had people who were trying to take an entire normal load of tasks during the week when they were moving to a new apartment. We had true unlimited time off at this company, so there was no reason not to just take a day off. So, new explicit guideline: Take time off for your personal life. Stop trying to cram in a full week's work when you know you'll be distracted. The team will get by fine without you, and you'll be happier when you come back. The trouble, of course, is that these sorts of things require a high level of respect amongst the team, and sometimes that's missing. So, really, you need to work on culture before you can adopt these tools.

agloe_dreams 3y ago

lol on #2: We had a funny situation where leaders were mad that tickets were getting carried over every sprint. We would then say that the velocity works out to the original planned velocity, the reason tickets would get carried over was that the devs would complete their tasks, then pull in tickets while the tasks went to QA for verification. Next sprint's ticket that would get pulled in would get done when it was supposed to: Next sprint. The leaders were like "Why are you pulling in tickets you can't complete!?!" Which led to the hilarious exchange of trying to explain that they stated that devs can only work on tickets pulled in, but because QA happens before the ticket gets marked as done, the only way no work flows over is if the dev, after handing their last ticket to QA, sat on their hands for two days. They just couldn't wrap their head around it.

peteradio 3y ago
Lol, honestly how fucking stupid. Here you have managers failing to understand the most fundamental basic part of their job.

cosmotic 3y ago

It's remarkable how many people hurt themselves and their teams by considering sprint goals as must-complete. "We must complete the work we committed to!"

sys42590 3y ago
There are so many reasons sprint goals are abused, it can be it bad management culture trickling down, people in charge not understanding even the simplest points of the Agile Manifesto, or even weird companywide KPIs linked to Scrum or Kanban completion metrics that you can so easily pull out of most agile management software (e.g. Jira).
- peteradio 3y ago
  Our scrum lord told us his bonus is tied to these metrics so you can guess why managers and scrum lords behave the way they do in spite of the manifesto. Throw the manifesto out the window its complete bullshit because they say one thing and do another.
  - sys42590 3y ago
    Indeed, Scrum looks nice in theory, and can be nice in practice (from my personal experience), because in theory it is about self-organizing of teams and collaboration with the product owner. In practice however in so many companies it is totally twisted and used as a method of control, and applying pressure, as you said by e.g. making metrics bonus relevant.
  - jacknews 3y ago
    "scrum lord" lol. Scrum is great when it's run by and for the dev team. As soon as it's co-opted by management as an easy way to 'inspect' performance, as a developer confessional/inquisition, etc, it becomes a living nightmare.

bick_nyers 3y ago

Sounds like every team also needs a therapist to do agile correctly. Only half joking!

sys42590 3y ago
The issue is that agile was once (back in the days of the manifesto) a grass roots effort to make life for developers better, but in many companies it has been perverted and twisted from a framework for collaboration and self-organization to controlling and pressuring development teams in a fortnight cycle. Of course this gives Scrum a bad rep. May an on-site therapist help more than just replacing attrition? If it would (in terms of net profits), many companies would have started to do so.

thiht 3y ago

> The sprint goal is not a contract I kinda disagree with that. We recently switched to a sprint mode « undercommit, overdeliver ». The objective is to not commit to a lot for the duration of the sprint (ie. something we 100% know we can achieve), but we commit strongly to it. And this gives us time to handle production issues if any, or to deliver on « surprise » features of we have time to kill, or work on DX, CI, etc. We need this « strong commitment » because we’re an early stage startup, and our sales need to know exactly what to sell to the clients, what will be available later this week. We also take 1h every Friday to demo our work, _deployed in prod_. No demo in local/dev.