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.
I like your idea.
"Agile" teams outnumber agile teams by a large margin.
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.
And what makes them high performing? What is the metric? Money?
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.
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.
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.
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.
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.
I'm not trying to push any particular part of scrum on anyone. My point was that I think teams should look to agile as a bunch of suggestions and should change or remove things as they see fit. If it's not working, scrap it. If retros assume your team works in one way, and your team doesn't work that way, change how your team does retros or don't do them.
Hell, at one company I worked at that was going through a particularly rough transition, we moved our "retros" to 3pm on Friday, brought beers, and by the 15 minute mark it was usually just a bitch-fest about everything that was going wrong at the company. They weren't the most productive retros ever, but it was what the team needed at that time.
> 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.
I disagree. From what I've seen, people are a lot more willing to speak up if they know they're not the only one feeling that way. It's easier to "yes and" someone else's complaint that speak up on your own. I just ran our retro today, where one of the more quiet members only had positive things to say until one of the other members of the team mentioned how they were having trouble getting reviews on PRs in a timely manner. Once that was out there the quiet team member was happy to hop in and share her issues around the same thing, but I doubt that would have happened if someone else hadn't "popped the cork".
> 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.
This sounds like the real root of your problems. If nothing is coming from your retros, I can see why you would be frustrated (I would be too). Our retros end with us going over the list of action items and assigning owners. Our next retro then starts with us going over that same list and seeing who got what done. For my current team that works really well and we've actually had some pretty great things come out of our retros because of it. I'm not trying to push that on you, but just giving an example of what works for us.
I hope I don't come off as offensive, but it really sounds to me like your team is pretty dysfunctional. I'm not sure there's really any process to get around that. Saying retros are useless when no one on your team cares is kind of like saying power steering is useless when your car is on fire.
Edit: Nvm, I figured it out. I assume you're referring to this?
> 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".
Honestly, not a ton. If we worked in isolation, we could probably drop them and little would change for us. The value that I feel like they bring are:
- It forces developers to agree on and commit to a certain amount of work for those two weeks. If a dev says, I'm going to do these three things and two weeks later they're not done with #1 it's a red flag. They may have a totally legitimate reason, but it at least forces us to ask the question.
- Kind of in the same thought process it helps us break month long projects down into smaller deliverables and communicate the status outward. We could easily do this without sprints, but some sort of break down is needed, so why not sprints?
- Other teams are doing more traditional sprint planning, so it gives us all a common language to communicate in. If we need something from another team, being on the same schedule as everyone else is nice.
- Our release schedule is tied to sprints. Without sprints it'd be much harder to keep track of what is going out when.
Just to give more detail, we do have a sprint planning meeting, but it's basically just all of us meeting and saying what we're working on in the next sprint. Like I said in my original comment, we took the parts that worked for our team and threw away the rest.
I think I have seen 3 types of people
* some get cynical and just don't care about the sprint goals. What doesn't get done this sprint gets carried over to the next one
* others really want to get ticked off everything. So they compromise on quality, pile up technical debt. Eventually they hope the project will be closed or they move one.
* 3rd category burns out themselves. This can end badly, I have seen suicide attempts, people disappearing from their family and of course sick leaves and quitting their jobs.
I don't think planning every 2 weeks is a bad thing. It just makes sure that plans get reviewed, updated, and refocussed frquently enough. Whether the goals have been reached or not I don't care that much. Retros are often a waste of time. Yeah, we underestimated something. We forgot a task. Unforeseen customer support suddenly had higher priority. There is always some reason why things went differently, despite all intentions to do it better every time.
Edit: No I don't think all sprints go just completely wrong. But there is always something that didn't work out. Maybe 30% on average? With my current team we try to mostly look at the 70% that we got done reasonably well and then we move on carrying over what still needs to be done.
Retros are a big waste of time about 95% of the time.
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".
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.
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.
classic Scrum statement - putting the blame again on teams. A team usually has no power to change anything that matters.
I haven't even mentioned it (or even implied that this has something to do with scrum), dysfunctional teams are waaaay more general problem than whatever scrum is/isn't.
Blame implies responsibility, which - like you mentioned - is not that simple. (Depending on personal philosophy maybe each team member has a responsibility toward themselves to get a job where they are not put into the aforementioned loony toones situation, but even with that in mind I honestly think you misinterpreted my comment, because I don't meant to assign blame at the team and its members. You might notice I expressly mentioned that if the team is too dysfunctional it has to be broken up "from above", implying that its not the responsibility of the team.)
After retrospectives we've always had a pretty good idea of what our problems are.
Motivation to fix those issues is a different story. Scrum can't solve for lacking motivation.
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.
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.
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.
People get so caught up in the process trappings of "agile" they miss the point.
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.
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.
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.
"Having no process at all" beats "Performative Scrum".
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.
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
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.
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.
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 :)
I’d probably reevaluate what it is you’re trying to achieve from a retrospective and listen to the team.