4 ms·

Do retros allow you to throw out agile and retros? In practice I find retros to be a special place where engineers can vent their discontent and nothing will e

Do retros allow you to throw out agile and retros? In practice I find retros to be a special place where engineers can vent their discontent and nothing will ever be done about it.

mrkeen 7y ago
I worked somewhere where we made a conscious decision at a retro to not do them so often. But to be honest that was probably the most agile place I've been at. But perhaps good retros are the exception, not the rule. At the place I worked, we started with a pretty regimented scrum - Monday morning planning poker, fixed-length sprints, which were closed and groomed, etc. I hated that crap. There was also a tech lead bully that insisted on doing things his way, and would use the code review process to keep other people's code out of the system. It was a real death march. By the time we had the basics of the system running, it was a dozen layers of synchronous blocking code where simple REST requests would take between 2 and 60 seconds to complete. Eventually the bully left, and after that we eventually wore our (non-tech) team lead down into getting rid of discrete sprints and planning poker, and the devs tended towards just 'working on the next thing'. I think the biggest factors we had in our favour were: 1) The team lead (pretty much the boss, too) was not technical, so he had no choice but to leave the tech decisions to us. 2) The tech bully left us in such a shitty state that it became obvious we'd need big changes, rather than token ones. 3) We got quite a bit of rapport happening and eventually the team lead understood that we actually wanted to get the system working nicely. The devs also got better at pitching ideas, like why a certain large changes were necessary. I can't imagine we would have gotten to steer the ship in any meaningful way without a bunch of factors lining up like that.
EdwardDiego 7y ago
In practice I found retros very useful in my last Scrum team because we iterated on our process to make retros useful. #1 was clustering similar sad faces. #2 was as a team, agreeing on actions we could take on those clusters. #3 was tracking how well we did on performing those actions. If it's just venting, it's not overly useful.
UK-Al05 7y ago
In theory if the retros arnt providing anything useful then yes. I would try to fix the retros though or have some kind of alternative to allow the team to change the process.

Do retros allow you to throw out agile and retros? In practice I find retros to be a special place where engineers can vent their discontent and nothing will ever be done about it.

mrkeen 7y ago

I worked somewhere where we made a conscious decision at a retro to not do them so often. But to be honest that was probably the most agile place I've been at. But perhaps good retros are the exception, not the rule. At the place I worked, we started with a pretty regimented scrum - Monday morning planning poker, fixed-length sprints, which were closed and groomed, etc. I hated that crap. There was also a tech lead bully that insisted on doing things his way, and would use the code review process to keep other people's code out of the system. It was a real death march. By the time we had the basics of the system running, it was a dozen layers of synchronous blocking code where simple REST requests would take between 2 and 60 seconds to complete. Eventually the bully left, and after that we eventually wore our (non-tech) team lead down into getting rid of discrete sprints and planning poker, and the devs tended towards just 'working on the next thing'. I think the biggest factors we had in our favour were: 1) The team lead (pretty much the boss, too) was not technical, so he had no choice but to leave the tech decisions to us. 2) The tech bully left us in such a shitty state that it became obvious we'd need big changes, rather than token ones. 3) We got quite a bit of rapport happening and eventually the team lead understood that we actually wanted to get the system working nicely. The devs also got better at pitching ideas, like why a certain large changes were necessary. I can't imagine we would have gotten to steer the ship in any meaningful way without a bunch of factors lining up like that.

EdwardDiego 7y ago

In practice I found retros very useful in my last Scrum team because we iterated on our process to make retros useful. #1 was clustering similar sad faces. #2 was as a team, agreeing on actions we could take on those clusters. #3 was tracking how well we did on performing those actions. If it's just venting, it's not overly useful.

UK-Al05 7y ago

In theory if the retros arnt providing anything useful then yes. I would try to fix the retros though or have some kind of alternative to allow the team to change the process.