7 ms·

The most important part of scrum and the only part that is important is retrospectives, because it allows the team opportunity to step back and make changes to

The most important part of scrum and the only part that is important is retrospectives, because it allows the team opportunity to step back and make changes to their processes. Everything else is mostly arbitrary. Want to stop doing stand ups or change how you manage work? Go for it, nobody is stopping you. Do what works for you.

iLoveOncall 4y ago
Retrospective is when I turn on my personal computer and start playing video games while listening to the meeting. It's completely useless, the only stuff we get is useless recognition like "Thanks iLoveOncall for helping me fix that bug" or "Congrats for your first CR NewJoiner4528". An absolute waste of time.
lostcolony 4y ago
That is also the only meeting (or doc; communal collaboration) prescribed by the Agile manifesto. People get so caught up in the process trappings of "agile" they miss the point.
corrral 4y ago
That's how it works in well-functioning agile teams, but in "Agile" teams the team can't decide on their own to e.g. totally ditch standups. Management won't allow it, or they've set up the project manager to be God of Agile and they get last say on that kind of thing, and so on. "Agile" teams outnumber agile teams by a large margin.
- henrikschroder 4y ago
  If you have a good team with good people, it doesn't matter much which process you're following, because shit will get done anyway. Agile was a way of trying to document how some good teams got shit done, but most of the companies and people trying to implement it didn't understand that you actually need good people, they thought it was the process, and thus "Agile" was born. ...and to the complete mystery of everyone involved, "Agile" teams don't get shit done.
  - Silhouette 4y ago
    This is painfully true and also deeply ironic given one of the lines in the Agile Manifesto itself.
  - quickthrower2 4y ago
    Good people but not just that. Good culture, good management, good business model / funding, and a good sprinkle of luck. And what makes them high performing? What is the metric? Money?
- g051051 4y ago
  That's how it works in well-functioning teams, period. Being "Agile" or "agile" has nothing to do with it.
- digisign 4y ago
  I've tried to explain several times to a client that 20-25 people is too many for a standup.
  - corrral 4y ago
    My "favorite" is when they mix teams working on unrelated things in the same standup. That sucks no matter how many people are in the meeting (thought obviously it's worse the larger the attendance)
  - quickthrower2 4y ago
    The advantage if this is you have now 20 bored people waiting their turn to spit out a sentence. As they tune out their subconscious mind figures out an elegant solution to what they were suck on.
- urthor 4y ago
  I've encountered almost zero agile manifesto teams in my time for back-end software. For 95% of projects, getting non-technical customers & stakeholders to read the manifesto and come demo software fortnightly, in person is impossible. At best we get an intern or underling. Interestingly, if the GUI was changed, they usually come racing.
JTbane 4y ago
>The most important part of scrum and the only part that is important is retrospectives That's funny because my "scrum" team doesn't do retrospectives at all, we just focus on long planning sessions every sprint. We are fully scrumfall.
Gunax 4y ago
I did retrospectives at a job for 2.5 years. I don't think in those ~60 retros, was there one thing we actually changed or accomplished. Certainly much griping happened. But ultimately very little couod be accomlished, because our problems were beyond the team. I would love to see retrospectives that worked, just to know what they are like. But so far I mostly see people forced to contribute to the retro, which results in: 1. Generic pats on the back for every minor thing we did. 'Really good job releasing feature X!' 2. Lot's of social compliments and jokes. 'X joined the team! Yay!' 3. Problems that we know about, but aren't tractable. 'The database schema we made 10 years ago really sucks!' but fixing it isn't practical.
- lostcolony 4y ago
  So there probably were some things during that time the team could change, even if it was out of pure pragmatism (i.e., "well, raising this issue led to a bunch of busy work. Let's not raise that kind of issue any more"). But even if not, there certainly was benefit just agreeing "yeah, this is a problem we can't address", since that builds a stronger team. That said, the situation you describe gets solved by the org adopting a retro itself. The team lead raises the broader issues up at a retro with other stakeholders/higher level management/etc, who -can- fix it.
superfrank 4y ago
I disagree... kind of. Every team is different and will have different strengths and weaknesses. Scrum should act as a framework to get your team to do the things it's not doing, but it should be doing. The most important parts of scrum are the ones that align with your teams weaknesses. If your team is already good about giving feedback to each other and trying new things to improve retros may be completely unnecessary. If your team just carries on doing that same old things because "that's the way it's always been done", then retros could easily be the most important part. One of my favorite teams I ever worked on was great about giving each other feedback and trying new things. Retros were completely unnecessary because we were great about giving feedback in the moment. Stand ups were super important on that team though because we didn't have an EM and our PM was completely checked out, so everyone just kind of did what they wanted. If we didn't check in regularly it completely possible for stuff to fall through the cracks or get forgotten. The team I'm on now, retros are super important because everyone is super agreeable and will hold in complaints. Sprint planning on the other hand is almost completely unnecessary since we have a bunch of long running one person projects that will get done when they get done. Each sprint is basically just everyone going, "I'm continuing what I was working on last sprint". Figure out what the goal of each piece of scrum is. If your team already does that well, throw the process away. Scrum (for your team) should be what is left. Repeat occasionally since teams and people change.
- BlargMcLarg 4y ago
  >If your team just carries on doing that same old things because "that's the way it's always been done", then retros could easily be the most important part. This tends to happen even with retros. Retros assume a lot of things about a team in order to work which just don't hold for a vast majority of teams. That's the problem with almost every methodology. They make assumptions on how a team should work in order for the tool to do its job. If the team doesn't work that way, it's the teams fault. You obviously can't blame a tool, but a tool isn't particularly useful when it doesn't solve the problem, either. Example for retros. They solve agreeableness and bottling things up, in theory. In practice, a lot of people stay agreeable and continue to bottle things up. They don't want to share frustrations. Maybe they try a few times, only to notice what they say doesn't really affect the future, leading to more frustration than just not saying anything. Which then puts the time spent doing the retrospective in question, or worse, it causes frustration because it keeps individuals from burying their problems. There are so many ways retros can be a big nothing burger, none of which are inherently the problem with retros. Then someone comes along saying "have you tried this". No Captain Obvious, I haven't tried using a coconut to smash against the wall instead. I'm sure it will break now, and I won't risk getting coconut splinters in my face.
ldjkfkdsjnv 4y ago
Never seen anything useful actually come from a retrospective. There are open and interesting conversations about what went wrong/could be done better, but those discussions never materially change the team. Generally people are who they are, the work is what it is. How the team will be is relatively static given the same set of people and projects.
- latchkey 4y ago
  This is why Pivotal Labs would rotate people on teams quite often. Nobody gets "stuck" doing the same thing endlessly.
- arnvald 4y ago
  Interesting, I have a very different experience. My team does retrospective once a month (we don't do Scrum, so it's not tied to "sprints") and every month we actually do some improvements. Sometimes the problems are small, let's say our products have inconsistent CLI interfaces for developers, and that slows us down, so we decide to unify it. Sometimes it's big stuff, for example the team feels that we don't have enough clarity about long term of the product, or there are too many interruptions. Then it's my (EM) or PM's role to figure stuff out. Some of the good things we changed as a result of retro: we removed stand-ups, we agreed to meet in the office once a week, we introduced a daily support rotation for our users (we build internal tools). We can't fix everything, but every month we get something done, and that keeps the team motivated to bring new ideas to retros.
- cableshaft 4y ago
  I have the same experience with retros. Generally they've have been a waste of time. Any useful information that could have been gleaned from them were probably already had in an earlier discussion, tend not to be remembered to be brought up again in retros, and at least in the teams I've been on the minutes from the retro meetings don't get recorded anywhere anyway, so there's nothing to refer back to in the future.
  - pas 4y ago
    it seems these teams lack(ed) the drive to consciously change. meetings should have conclusions (action items based on consensus, which are commitments from all members) and it's a typical team dysfunction when members don't honor commitments (someone doesn't do something and then others don't bring this up to hold each other accountable) if the team is so dysfunctional that it just does the same thing over and over again while constantly promising to change then it should be broken up before the members themselves start to suffer the psychological toll of this cognitive dissonance.
latchkey 4y ago
You are right. I miss Friday's at Pivotal Labs where we went as a team to a conference room and wrote a happy face, meh face and sad face on the board. We wrote out things that happened during the week under each column. Everyone votes for what they want to talk about and the items with the most votes get discussed first. Doing this religiously helped with team cohesion and allowed us to develop better products together. Those 30 minutes were a great way to end each week and set us up for a productive new week on Monday.
probotect0r 4y ago
In my experience, most retro meetings I have been in start with the scrum master asking things like "what did we do well this sprint?", followed by complete silence from the team until someone points out a non-point like "we collaborated well...". One team I worked on decided to not pre-schedule retro meetings. Instead we had a 'retro board', which was just a section of a white board where team members would write down specific things that they think would be worth discussing in a future retro meeting. The team would decide to hold a retro meeting once the board had accumulated a few things to talk about. We found this approach was super effective because we knew what we needed to discuss when we held the meeting, instead of waiting for team members to recall something to talk about.
- IshKebab 4y ago
  That's been my experience of regular retrospectives too. There's rarely anything notable to discuss in a 2 week period (or even a month) so it just makes for useless awkward meetings. I like your idea.
- maximus-decimus 4y ago
  We started playing Counter Strike every retro because all we were doing was bitching against things we have no power over.
flir 4y ago
You need measurement too. You need a way to measure the success of the change that was agreed on in the retrospective. Story points, LoC, tickets, whatever.
ratww 4y ago
The most important part is making the changes to processes. Sure, retrospectives are part of it, but when retrospectives become just a place for the team to air their grievances but all suggestions are blocked by management, it is hell on earth. "Having no process at all" beats "Performative Scrum".
adrianmsmith 4y ago
I find one problem with retros is they violate the principle of "praise in public, criticism in private". People instinctively understand that and thus there tends to be more praise. Everyone hears themselves praising the process and thus start to believe it actually is good. Therefore more Scrum gets done, no matter if it's actually good for the team or company or not. Recently I went to a retro where the positives were listed as a great team, great accomplishments in the last sprint, thanks to person X for going the extra mile, and so on. When it came to discuss the negatives, the main one was "the meeting room was hard to find".
zerr 4y ago
In my several years of experience of participating in retrospectives at two different companies/teams - it's a total waste of time. Just one of the ceremonies for keeping "Agile Coaches" employed.
- spelunker 4y ago
  IMO I think it depends on how the team handles it. The team I'm on tends to oscillate between "useless meeting" and "agent for change". I think if there's nothing to talk about why have yet another meeting? Perhaps we'll implement a straw poll about actually holding retrospective... I'll bring it up in the next retro of course.
lcfcjs 4y ago
_the_inflator 4y ago
I agree. I see retros as the only time, a team as a whole sits/works together for around 2 hours at a time. My advice: treat retros as a way to check in with your team or the team itself. Sometimes, if there are no pressing topics, just talking and chilling can be the best use of the time.
WhiskeyTang 4y ago
I completely agree. I was a certified scrum master, scrum master of a team of 6 for 2 years, and was directly coached by an external (and expensive) scrum consultant. We got pretty deep into the scrum process, even going so far as to estimate and track the number of hours each task would take. After all of that, my takeaway is that thoughtful, engaging retrospectives are the only scrum "event" or process that a team should do. Want to do a stand up meeting only once a week? Go for it. You think pointing stories is a waste of time? Cool, spend that hour coding instead. But you have to regularly check in and make sure your process is actually working, and then put some effort into improving it. Also, don't forget to retro your retros. Maybe a 2 hour meeting twice a month is a waste of time because your team is already great at providing feedback and trying new things naturally. Getting rid of the meeting might be the best thing as long as there is a viable alternative way for everyone to provide feedback and suggestions.
- pas 4y ago
  how did you estimate hours? do you mean that the team estimated "story points" and it was so precise and the team was so good at meeting the per-sprint point load that it was basically a nice hour estimate? or did you estimate hours directly?
legulere 4y ago
Retrospectives don't help when your problems are external and you do not have influence on them. If you get how much needs to be done and what needs to be done set fixed from outside the team cannot do much about it. And that what scrum often ends up in a lot of companies: all the responsibility when things go bad but none of the autonomy that would be needed.
- muaddirac 4y ago
  I've noticed a related effect, where every problem discussed in a retro has a "process" solution, because the team's own processes are the only thing the team can fully control. This can lead to both a constant churn in processes and a piling on of additional processes, which bog the team down with an explosion of on-call-like rolls that get rotated through team members.
krzyk 4y ago
In every new team, on first retrospective I test it with a simple: let's get rid of retrospectives (followed by: let's not make demos). If it passes the manager, this is a true retro - never happened.
- jpswade 4y ago
  This seems obnoxious and anarchical, which in a new team probably won’t fly. People don’t like to be tested in this way. I’d probably reevaluate what it is you’re trying to achieve from a retrospective and listen to the team.
- xcambar 4y ago
  As a manager, I’d just think you’re being provocative and short-sighted. As an IC, I’d think you’re big-mouthed, in a bad way. In any case, even if you were right, I’d be the kind of colleague you’d have to work your way up to retrieve trust after such a stunt.
  - krzyk 4y ago
    Really, a stunt? If I can't change such things what can I change in a retro? It is usually either patting on the back or complaining on things that don't change.(late requirements, we forgot about one more dependency etc.) None of the negative things I have seen on retros in the last 10 years did get changed. So now I see it as a pointless meeting that takes away time to do coding. Fortunately. With all the WFH in the last 2 years I don't need to really listen to it.
    - xcambar 4y ago
      > In every new team, on first retrospective I test it with a simple: let's get rid of retrospectives Trying to get rid of something, in any new context, at first encounter is sending the signal that you think you know better without actually even willing to see for yourself in said new context. That's why I used the term "stunt". Do the same thing after a quarter, where you have gained knowledge, experience and feedback, and I'd happily use a much more appreciative term :)
SkyPuncher 4y ago
Everything needs to reflect to the team's needs. I'm a very big advocate of scrum, but I rarely have my teams run pure scrum. One thing I absolutely love is introducing the concepts of sprints and watching conversations switch from bickering about single day deadlines on a multi-week project to "sounds like it'll take X sprints". There are essentially two times you should try to follow scrum perfectly: * During a fire/emergency. This should be rare. It helps keep the response moving without unnecessary overhead. Yes, the meetings are overhead - but they often cut out other other head. * When gelling a new team. Scrum is really helpful in getting the team to mesh quickly. Routine contact, flexibility, small iteration, all good stuff. Outside of that, roll scrum back to match the team. For us, that's: * Bi-weekly retrospectives. * 1 to 3 standups per week (depending on the team's need) ----- Basically, we ask for 4 hours of people's time over 2 weeks. We find this ends up saving well over 4-hours of 1-off and random meetings.
andrekandre 4y ago
it depends on if the retro itself is rigid or not many times retros are done in the same fashion: 1. everyone writes their pain points 2. everyone writes what went well (this is usually ignored) 3. everyone votes on the pain points 4. take the top 3 and discuss 5. write up some todo for the top 3 --- the above looks good on paper, but in reality many times a free flowing discussion is much more productive, and this can be done by just normal team meetings to discuss such issues

iLoveOncall 4y ago

Retrospective is when I turn on my personal computer and start playing video games while listening to the meeting. It's completely useless, the only stuff we get is useless recognition like "Thanks iLoveOncall for helping me fix that bug" or "Congrats for your first CR NewJoiner4528". An absolute waste of time.

lostcolony 4y ago

That is also the only meeting (or doc; communal collaboration) prescribed by the Agile manifesto. People get so caught up in the process trappings of "agile" they miss the point.

corrral 4y ago

That's how it works in well-functioning agile teams, but in "Agile" teams the team can't decide on their own to e.g. totally ditch standups. Management won't allow it, or they've set up the project manager to be God of Agile and they get last say on that kind of thing, and so on. "Agile" teams outnumber agile teams by a large margin.

henrikschroder 4y ago
If you have a good team with good people, it doesn't matter much which process you're following, because shit will get done anyway. Agile was a way of trying to document how some good teams got shit done, but most of the companies and people trying to implement it didn't understand that you actually need good people, they thought it was the process, and thus "Agile" was born. ...and to the complete mystery of everyone involved, "Agile" teams don't get shit done.
- Silhouette 4y ago
  This is painfully true and also deeply ironic given one of the lines in the Agile Manifesto itself.
- quickthrower2 4y ago
  Good people but not just that. Good culture, good management, good business model / funding, and a good sprinkle of luck. And what makes them high performing? What is the metric? Money?
g051051 4y ago
That's how it works in well-functioning teams, period. Being "Agile" or "agile" has nothing to do with it.
digisign 4y ago
I've tried to explain several times to a client that 20-25 people is too many for a standup.
- corrral 4y ago
  My "favorite" is when they mix teams working on unrelated things in the same standup. That sucks no matter how many people are in the meeting (thought obviously it's worse the larger the attendance)
- quickthrower2 4y ago
  The advantage if this is you have now 20 bored people waiting their turn to spit out a sentence. As they tune out their subconscious mind figures out an elegant solution to what they were suck on.
urthor 4y ago
I've encountered almost zero agile manifesto teams in my time for back-end software. For 95% of projects, getting non-technical customers & stakeholders to read the manifesto and come demo software fortnightly, in person is impossible. At best we get an intern or underling. Interestingly, if the GUI was changed, they usually come racing.

JTbane 4y ago

>The most important part of scrum and the only part that is important is retrospectives That's funny because my "scrum" team doesn't do retrospectives at all, we just focus on long planning sessions every sprint. We are fully scrumfall.

Gunax 4y ago

I did retrospectives at a job for 2.5 years. I don't think in those ~60 retros, was there one thing we actually changed or accomplished. Certainly much griping happened. But ultimately very little couod be accomlished, because our problems were beyond the team. I would love to see retrospectives that worked, just to know what they are like. But so far I mostly see people forced to contribute to the retro, which results in: 1. Generic pats on the back for every minor thing we did. 'Really good job releasing feature X!' 2. Lot's of social compliments and jokes. 'X joined the team! Yay!' 3. Problems that we know about, but aren't tractable. 'The database schema we made 10 years ago really sucks!' but fixing it isn't practical.

lostcolony 4y ago
So there probably were some things during that time the team could change, even if it was out of pure pragmatism (i.e., "well, raising this issue led to a bunch of busy work. Let's not raise that kind of issue any more"). But even if not, there certainly was benefit just agreeing "yeah, this is a problem we can't address", since that builds a stronger team. That said, the situation you describe gets solved by the org adopting a retro itself. The team lead raises the broader issues up at a retro with other stakeholders/higher level management/etc, who -can- fix it.

superfrank 4y ago

I disagree... kind of. Every team is different and will have different strengths and weaknesses. Scrum should act as a framework to get your team to do the things it's not doing, but it should be doing. The most important parts of scrum are the ones that align with your teams weaknesses. If your team is already good about giving feedback to each other and trying new things to improve retros may be completely unnecessary. If your team just carries on doing that same old things because "that's the way it's always been done", then retros could easily be the most important part. One of my favorite teams I ever worked on was great about giving each other feedback and trying new things. Retros were completely unnecessary because we were great about giving feedback in the moment. Stand ups were super important on that team though because we didn't have an EM and our PM was completely checked out, so everyone just kind of did what they wanted. If we didn't check in regularly it completely possible for stuff to fall through the cracks or get forgotten. The team I'm on now, retros are super important because everyone is super agreeable and will hold in complaints. Sprint planning on the other hand is almost completely unnecessary since we have a bunch of long running one person projects that will get done when they get done. Each sprint is basically just everyone going, "I'm continuing what I was working on last sprint". Figure out what the goal of each piece of scrum is. If your team already does that well, throw the process away. Scrum (for your team) should be what is left. Repeat occasionally since teams and people change.

BlargMcLarg 4y ago
>If your team just carries on doing that same old things because "that's the way it's always been done", then retros could easily be the most important part. This tends to happen even with retros. Retros assume a lot of things about a team in order to work which just don't hold for a vast majority of teams. That's the problem with almost every methodology. They make assumptions on how a team should work in order for the tool to do its job. If the team doesn't work that way, it's the teams fault. You obviously can't blame a tool, but a tool isn't particularly useful when it doesn't solve the problem, either. Example for retros. They solve agreeableness and bottling things up, in theory. In practice, a lot of people stay agreeable and continue to bottle things up. They don't want to share frustrations. Maybe they try a few times, only to notice what they say doesn't really affect the future, leading to more frustration than just not saying anything. Which then puts the time spent doing the retrospective in question, or worse, it causes frustration because it keeps individuals from burying their problems. There are so many ways retros can be a big nothing burger, none of which are inherently the problem with retros. Then someone comes along saying "have you tried this". No Captain Obvious, I haven't tried using a coconut to smash against the wall instead. I'm sure it will break now, and I won't risk getting coconut splinters in my face.

ldjkfkdsjnv 4y ago

Never seen anything useful actually come from a retrospective. There are open and interesting conversations about what went wrong/could be done better, but those discussions never materially change the team. Generally people are who they are, the work is what it is. How the team will be is relatively static given the same set of people and projects.

latchkey 4y ago
This is why Pivotal Labs would rotate people on teams quite often. Nobody gets "stuck" doing the same thing endlessly.
arnvald 4y ago
Interesting, I have a very different experience. My team does retrospective once a month (we don't do Scrum, so it's not tied to "sprints") and every month we actually do some improvements. Sometimes the problems are small, let's say our products have inconsistent CLI interfaces for developers, and that slows us down, so we decide to unify it. Sometimes it's big stuff, for example the team feels that we don't have enough clarity about long term of the product, or there are too many interruptions. Then it's my (EM) or PM's role to figure stuff out. Some of the good things we changed as a result of retro: we removed stand-ups, we agreed to meet in the office once a week, we introduced a daily support rotation for our users (we build internal tools). We can't fix everything, but every month we get something done, and that keeps the team motivated to bring new ideas to retros.
cableshaft 4y ago
I have the same experience with retros. Generally they've have been a waste of time. Any useful information that could have been gleaned from them were probably already had in an earlier discussion, tend not to be remembered to be brought up again in retros, and at least in the teams I've been on the minutes from the retro meetings don't get recorded anywhere anyway, so there's nothing to refer back to in the future.
- pas 4y ago
  it seems these teams lack(ed) the drive to consciously change. meetings should have conclusions (action items based on consensus, which are commitments from all members) and it's a typical team dysfunction when members don't honor commitments (someone doesn't do something and then others don't bring this up to hold each other accountable) if the team is so dysfunctional that it just does the same thing over and over again while constantly promising to change then it should be broken up before the members themselves start to suffer the psychological toll of this cognitive dissonance.

latchkey 4y ago

You are right. I miss Friday's at Pivotal Labs where we went as a team to a conference room and wrote a happy face, meh face and sad face on the board. We wrote out things that happened during the week under each column. Everyone votes for what they want to talk about and the items with the most votes get discussed first. Doing this religiously helped with team cohesion and allowed us to develop better products together. Those 30 minutes were a great way to end each week and set us up for a productive new week on Monday.

probotect0r 4y ago

In my experience, most retro meetings I have been in start with the scrum master asking things like "what did we do well this sprint?", followed by complete silence from the team until someone points out a non-point like "we collaborated well...". One team I worked on decided to not pre-schedule retro meetings. Instead we had a 'retro board', which was just a section of a white board where team members would write down specific things that they think would be worth discussing in a future retro meeting. The team would decide to hold a retro meeting once the board had accumulated a few things to talk about. We found this approach was super effective because we knew what we needed to discuss when we held the meeting, instead of waiting for team members to recall something to talk about.

IshKebab 4y ago
That's been my experience of regular retrospectives too. There's rarely anything notable to discuss in a 2 week period (or even a month) so it just makes for useless awkward meetings. I like your idea.
maximus-decimus 4y ago
We started playing Counter Strike every retro because all we were doing was bitching against things we have no power over.

flir 4y ago

You need measurement too. You need a way to measure the success of the change that was agreed on in the retrospective. Story points, LoC, tickets, whatever.

ratww 4y ago

The most important part is making the changes to processes. Sure, retrospectives are part of it, but when retrospectives become just a place for the team to air their grievances but all suggestions are blocked by management, it is hell on earth. "Having no process at all" beats "Performative Scrum".

adrianmsmith 4y ago

I find one problem with retros is they violate the principle of "praise in public, criticism in private". People instinctively understand that and thus there tends to be more praise. Everyone hears themselves praising the process and thus start to believe it actually is good. Therefore more Scrum gets done, no matter if it's actually good for the team or company or not. Recently I went to a retro where the positives were listed as a great team, great accomplishments in the last sprint, thanks to person X for going the extra mile, and so on. When it came to discuss the negatives, the main one was "the meeting room was hard to find".

zerr 4y ago

In my several years of experience of participating in retrospectives at two different companies/teams - it's a total waste of time. Just one of the ceremonies for keeping "Agile Coaches" employed.

spelunker 4y ago
IMO I think it depends on how the team handles it. The team I'm on tends to oscillate between "useless meeting" and "agent for change". I think if there's nothing to talk about why have yet another meeting? Perhaps we'll implement a straw poll about actually holding retrospective... I'll bring it up in the next retro of course.

lcfcjs 4y ago

_the_inflator 4y ago

I agree. I see retros as the only time, a team as a whole sits/works together for around 2 hours at a time. My advice: treat retros as a way to check in with your team or the team itself. Sometimes, if there are no pressing topics, just talking and chilling can be the best use of the time.

WhiskeyTang 4y ago

I completely agree. I was a certified scrum master, scrum master of a team of 6 for 2 years, and was directly coached by an external (and expensive) scrum consultant. We got pretty deep into the scrum process, even going so far as to estimate and track the number of hours each task would take. After all of that, my takeaway is that thoughtful, engaging retrospectives are the only scrum "event" or process that a team should do. Want to do a stand up meeting only once a week? Go for it. You think pointing stories is a waste of time? Cool, spend that hour coding instead. But you have to regularly check in and make sure your process is actually working, and then put some effort into improving it. Also, don't forget to retro your retros. Maybe a 2 hour meeting twice a month is a waste of time because your team is already great at providing feedback and trying new things naturally. Getting rid of the meeting might be the best thing as long as there is a viable alternative way for everyone to provide feedback and suggestions.

pas 4y ago
how did you estimate hours? do you mean that the team estimated "story points" and it was so precise and the team was so good at meeting the per-sprint point load that it was basically a nice hour estimate? or did you estimate hours directly?

legulere 4y ago

Retrospectives don't help when your problems are external and you do not have influence on them. If you get how much needs to be done and what needs to be done set fixed from outside the team cannot do much about it. And that what scrum often ends up in a lot of companies: all the responsibility when things go bad but none of the autonomy that would be needed.

muaddirac 4y ago
I've noticed a related effect, where every problem discussed in a retro has a "process" solution, because the team's own processes are the only thing the team can fully control. This can lead to both a constant churn in processes and a piling on of additional processes, which bog the team down with an explosion of on-call-like rolls that get rotated through team members.

krzyk 4y ago

In every new team, on first retrospective I test it with a simple: let's get rid of retrospectives (followed by: let's not make demos). If it passes the manager, this is a true retro - never happened.

jpswade 4y ago
This seems obnoxious and anarchical, which in a new team probably won’t fly. People don’t like to be tested in this way. I’d probably reevaluate what it is you’re trying to achieve from a retrospective and listen to the team.
xcambar 4y ago
As a manager, I’d just think you’re being provocative and short-sighted. As an IC, I’d think you’re big-mouthed, in a bad way. In any case, even if you were right, I’d be the kind of colleague you’d have to work your way up to retrieve trust after such a stunt.
- krzyk 4y ago
  Really, a stunt? If I can't change such things what can I change in a retro? It is usually either patting on the back or complaining on things that don't change.(late requirements, we forgot about one more dependency etc.) None of the negative things I have seen on retros in the last 10 years did get changed. So now I see it as a pointless meeting that takes away time to do coding. Fortunately. With all the WFH in the last 2 years I don't need to really listen to it.
  - xcambar 4y ago
    > In every new team, on first retrospective I test it with a simple: let's get rid of retrospectives Trying to get rid of something, in any new context, at first encounter is sending the signal that you think you know better without actually even willing to see for yourself in said new context. That's why I used the term "stunt". Do the same thing after a quarter, where you have gained knowledge, experience and feedback, and I'd happily use a much more appreciative term :)

SkyPuncher 4y ago

Everything needs to reflect to the team's needs. I'm a very big advocate of scrum, but I rarely have my teams run pure scrum. One thing I absolutely love is introducing the concepts of sprints and watching conversations switch from bickering about single day deadlines on a multi-week project to "sounds like it'll take X sprints". There are essentially two times you should try to follow scrum perfectly: * During a fire/emergency. This should be rare. It helps keep the response moving without unnecessary overhead. Yes, the meetings are overhead - but they often cut out other other head. * When gelling a new team. Scrum is really helpful in getting the team to mesh quickly. Routine contact, flexibility, small iteration, all good stuff. Outside of that, roll scrum back to match the team. For us, that's: * Bi-weekly retrospectives. * 1 to 3 standups per week (depending on the team's need) ----- Basically, we ask for 4 hours of people's time over 2 weeks. We find this ends up saving well over 4-hours of 1-off and random meetings.

andrekandre 4y ago

it depends on if the retro itself is rigid or not many times retros are done in the same fashion: 1. everyone writes their pain points 2. everyone writes what went well (this is usually ignored) 3. everyone votes on the pain points 4. take the top 3 and discuss 5. write up some todo for the top 3 --- the above looks good on paper, but in reality many times a free flowing discussion is much more productive, and this can be done by just normal team meetings to discuss such issues