In the list of activities in the Scrum software development life cycle ranked by their popularity amongst developers, “attending meetings” is perhaps locked in a perpetual battle only with “writing documentation” for the position of last place. It’s quite understandable: meetings can easily become very boring — especially when a participant does not have anything to contribute to the meeting at hand — and are often perceived as having little value (if at all) compared to conducting actual code-writing in the software development project. However, these Scrum meetings can and do provide value to the project, even if the members of the team do not perceive it:
- Sprint refinements enable a product owner and the team to plan out development tasks in the weeks/months to come as well as identify whether any task might need further examination and/or design.
- Sprint plannings define what work the team should be set to accomplish in the given sprint period.
- Sprint demos provide visibility to other teams and/or project stakeholders into what a team is working on and has accomplished and permits questioning for clarity regarding the work (or even challenges to ensure that the produced work is robust and has fulfilled all objectives).
- Sprint retrospectives allow a team to identify factors in the previous sprint that were well-received, could be addressed for improvement or elimination, etc.
This is, of course, merely reciting from the doctrine of Scrum. Whatever benefits these meetings may hope to provide will not appear if the participants of the Scrum meeting are not interested in “playing their part” in said meetings — execution, after all, eats strategy for breakfast. What can be done, then? One could: