I honestly haven't met many scrum masters who don't just preach the scrum guide. Even if the team is struggling with the way we do Agile, the scrum master will just continue to force the scrum guide onto the team.
What I currently see is that our scrum master has sold the business on the agile way, so if a developer complains about it, there's something wrong with the developer. It's probably just a bad scrum master, but I've met multiple of those.
I would not call it self destruct, rather reconstruct or adjust. If the way the team uses Scrum isn't effective, then the retrospective can be used to explore issues and adjust the way of working.
Disagree: the team owns the retrospective, not the Scrum master. If team members aren't happy with what the Scrum master is doing, that should be addressed in the retrospective.
And this is coming from your own personal experience? I've never been in a scrum team where we as developers had any say in what the scrum master was doing. The most we could do was retrospectives with other developers, and try to improve there. However that's rarely enough to make a business work.
Moving from traditional project management to agile is a paradigm shift. This article discusses the role that management plays in organizations that have decided to adopt agile.
InfoQ interviewed Fred George about how make microservices as small as possible, challenges when implementing microservices and how to deal with them, why programming style matters, and what developers can do to develop their code writing skills.
These are clear symptoms of not having retrospectives facilitated in a proper Wat. A good facilitator uses different exercises, has people focused on a fixed scope or time period to catch learning points, supports a team in coming up with actions that they can do immediately and that are small enough to finish on a short notice.
It takes a different mindset to make changes happen (agile or not). If people resists changing their mindset, nothing will happen and we keep struggling. That's a choice I'd rather not do.
Very true, it's not the format but the goal of adapting that matters. If you can discuss and fix your problem in a stand-up, do it. If you need to sit down for half an hour, take time for it. If you need 1/2 day to really understand what is happening and get a shared view to decide what to do, plan it. But make sure that you take action.
I think that one of the key things to make retrospectives valuable is to use suitable exercises. By valuable I mean exercises that help teams to better understand what has happened and to take action. Suitable will often depend on the team and situation at hand.
The retrospective facilitator (often the scrum master) should have a toolbox of retrospective techniques, and be able to pick the most effective one. Some of the techniques to do retrospectives are asking questions, state your feelings with 1 word, 5 times why (Root Causes) or asking why, solution focused/strengths and retrospective of retrospectives.
@BenLinders
Co-author Getting Value out of Agile Retrospectives
