A very common complaint about SCRUM is that there are a lot of Scrum meetings. Another common complaint, often combined with the first mentioned, is that developers feel not productive (enough). Developers feel less productive when they are not bursting large amounts of code. That feels like something from the old days, where people were valued based on the amount of work they could deliver per hour/day/week. Within Scrum, it is more about the team, than the individual. In order to increase quality, knowledge, and productivity, team members should collaborate more. Share your knowledge, experience and insights in the diverse meetings, that’s what they are for. It is part of your daily work and in order to feel productive, you might have to increase the quality of the meetings. An efficient Scrum meeting increases productivity.
Time management
The following calculation will show exactly how much time you should spend on Scrum meetings.
This example takes two weeks for the sprint:
- Sprint planning: 1 x 4 hours
- Daily Scrum: 10 x 15 minutes = 150 minutes = 2,5 hours
- Backlog refinement (or preplanning): 1 x 2 hours
- Sprint review: 1 x 2 hours
- Sprint retrospective: 1 x 1,5 hours
These are all timeboxed meetings, so a total of 12 hours. On an average work week of 40 hours, there are 80 hours in a sprint. (12 / 80) x 100 = 15%. Besides these meetings, there could be several backlog refinement moments. These should be kept as short as possible and well planned and could very well include only some of the team members.
For most of the prescribed meetings, all team members are required to be there. The Daily Scrum is primarily intended for the Development Team and the Sprint planning can be done by the Development Team alone. That’s it.
Focus and dedication
One of the keys to getting more value from Scrum is focus and dedication. An experienced Scrum Master will focus and coach the team to stay on topic, within the time box and might interrupt when people collide. He/she also should teach the team to take a break every once in a while. When the Scrum Master or a team member notices that focus is lost, it is probably a good time to take a break. Go outside, walk for a couple of minutes, go to the bathroom and take a fresh cup of coffee.
Besides focus, there is this thing called dedication. More than often, team members end up in several projects and/or Scrum teams. This leads to double agendas and possibly twice the meetings. Another thing that is seen nowadays is working from home and/or part time. Not that there is anything wrong with that, but there are a couple of downsides. First of all, it makes it harder to plan all the meetings, since the days that everybody is in the office are limited. Second, those who are working fewer days are relatively more in meetings than people who are working more days or full time. And third, but probably the worst in the Scrum philosophy; team members are less often co-located and this reduces chances on collaboration.
Conclusion
It could also very well be that Scrum is not the right process methodology for you and your team. Scrum requires team members that believe in the Scrum framework, or at least are willing to learn and try new things. Being open to new things are important to embrace the rules and ceremonies and really collect the most value out of it. In my previous blog, I already described how to deal with sub-optimal implementations of Scrum.
It is easy to learn Scrum, it can take years to master it. You can come to understandable agreements and set up a decent Definition of Done. But when meetings are seen as a waste of time or obsolete, you will need to step up your game. Both developers, Scrum Masters and Product Owners. Focus, build in breaks and be dedicated.