Scrum - use the good parts too!
Scrum is like democracy - it is not great, but nothing better has been invented yet. It is also like REST - everyone is saying that they are doing it, but no one has implemented it by-the-book (the REST police might send me to jail for saying this). All of that is fine, but if you are doing it, don’t end up by just using the bad parts of it - embrace the goodies too!
So what are the bad parts of Scrum?
Daily meetings - sure, they can be useful, but often they are very dull, and people don’t really listen to what others are saying.
The demo - again, can be fun, and useful for knowledge sharing, but it can also drain a lot of energy from the presenter who needs to prepare it.
The retrospective meeting - of course, it is great to look back and try to improve, but sometimes there is not much to talk or retrospect about.
The grooming/refinement meeting - it is necessary, but again, can be quite dull.
All of these revolve around the same topic - too many meetings. The cure for these might be obvious - you don’t need to do them every time!
Consider demo only once per month?
No dailies on Fridays - a meeting-free Friday is a great practice!
Retrospective - after each sprint, do a small poll and see if people want it or not.
The grooming/refinement - use half of the booked time to vote on and discuss tickets opened by the team members, outside of business - these can be technical improvements or investigations.
The story-points and estimations are often debated and misused. What is a point and how much time does one story point take?! Teams often struggle with this, but it can be solved with simple, straightforward rules. For example, say that 5 points is how much an average contributor can do in one sprint, and make sure that people are reminded about it. Or, skip the points, and just use hours. Whatever you choose, make sure to respect it in velocity planning. No need to obsess about it, just use it as a rough estimate on how much the team should take in one sprint. Another approach is to try planning points/hours per person, and not per team - this is quite controversial per scrum rules, but I think it works better in practice.
MVP at the end of each sprint - I think this only works for early-stage, small products, and that it cannot work in more mature/bigger environments - so just ignore it!
OK, enough of the annoying stuff, so what are the good things about Scrum?
The sprint - yeah it is stressful having to deliver every 2/3 weeks, but at least - you shouldn’t be interrupted by the new stuff before the next planning. It is important to have a culture where sprint is uninterruptible, unless in urgent/special cases - like dropping a database in production.
The Scrum master role - it can become quite a bureaucratic job, but it can also be very helpful for the team, if done well. The main role of this person is to push back on business when the team feels it is necessary. If the team is burnt-out or if there are a lot of stability issues, it is often a good idea to stop with new business requirements and focus one or more sprints on improvements and fixes. This can be quite healing for both the team and the product. Another important point is to limit the meeting durations/agendas and productively navigate through them.
When no one wants to take this role - you can try a rotating scrum master, where every sprint another team member takes the role.
That’s all folks, hope that it helps someone!