4 ms·
> The whole point of agile is to adapt the process to the team's needs - if you're doing dogmatic agile, you're not actually doing agile. But what Scrum seems t
by apocalyptic0n3 4y ago
> The whole point of agile is to adapt the process to the team's needs - if you're doing dogmatic agile, you're not actually doing agile. But what Scrum seems to add on top of the agile manifesto seems to be mainly dogma.
I oversee (i.e. just making sure they're running well and on schedule) a bunch of different project teams and this is a frequent debate I have with the leads on those projects. If x and y is working for you, but z isn't, why don't you meet with your team and adjust z to make it work with the project and, more specifically, your personnel better? The response is almost always "But then it's not Scrum." They get in this mindset that if they don't follow the Scrum workflow to a T, then they're failing as leaders. That the workflow should be a rock that you beat your team against until they conform to it. It's a struggle backing them down from that edge and convincing them that Scrum doesn't work in all (many) cases, but a few minor tweaks to it will make your team function more effectively pretty easily. A lot of them struggle to accept that the "few minor tweaks" is always different between projects and teams, too.
Retros are essential for running an effective agile workflow, whether it be Scrum, Kanban, near-Scrum, or something else. You need to take a step back, view the process from the outside with your team, and figure out how to more effectively function going forward. Trying to appease the Scrum gods or your manager by adhering to every single character of Scrum as if it is scripture doesn't make any project better, in my opinion. Everything has to be flexible to some extent, including you, your team, and your processes.
- andrekandre 4y ago> Retros are essential for running an effective agile workflow retros are very difficult to get right: many issues brought up cant be fixed by those attending (company policies, group okrs, platform issues, immovable deadlines etc), so the result many times is either self-flagellation or "improvement plans" that don't go anywhere... the end result being even more demotivating for a team.... if retros arent going to be effective at real improvement, then its better not to do them imo* *there are other ways to improve teamwork/processes anyways
- bluGill 4y agoMy team always puts a 'general complainy pants' column on our retros so we can acknowledge things we have no control over and move to things we can.
- apocalyptic0n3 4y agoYeah, that's fair. I guess "Effective retros are essential" would be more accurate. It's just like any other step of the process: if the retro isn't working, figure out a different way to get the feedback. Nothing needs to be set in stone. You pick a starting point (i.e. Scrum + Retros) and make changes until things work as well as you need them to.
- icedchai 4y agoI've been in software development for just over 25 years. "Scrum" didn't start becoming a major thing until 2010-ish. Since that time, I could count the number of useful "retros" on one hand. It is almost always a waste of time. "What should we stop doing?" "This." (The retro.)
- siva7 4y agoSeems more like you never experienced a good scrum process. The retros were one of the most valuable things that always resulted in concrete actions taken otherwise i agree that it would be a waste of time.