Introduction

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 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 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:

• Dress up the Scrum meetings in cute metaphors – for example, using t-shirt sizes instead of point poker for story effort estimation during sprint refinement. This still leaves it clear that the meetings are exactly what they are, i.e.. overhead to a project that the team members have to trudge through.
• Simply press the benefits of Scrum and appeal to the team members’ professionalism so that they step up and provide the necessary meeting input. Even with the most skilled motivator conducting this speech, it runs the risk of sounding browbeating or haranguing and might conduct the opposite effect of bringing morale down.

Instead…

As much as these attempts may be well-intentioned, they usually do not succeed in raising enthusiasm or buy-in for the meetings. In my opinion, this is due to the thought process behind the endeavors confining itself to the traditional definition of the meetings: they are still held as bog-standard meetings wherein the description for how the ceremony should occur is followed nearly point-by-point. Instead, it’s possible to make these meetings less “painful” for those involved in other ways by employing some outside-of-the-box thinking. For this, I would like to provide two examples from my own experience working at LucaNet of meeting formats that improved engagement while still providing the same desired output.

Expand The Scope: Sprint Demonstrations

At first glance, the objective of the sprint demonstration seems very straightforward: having the project’s teams provide a demonstration of whatever they have accomplished in the past sprint. This usually comes with the added stipulation that these demonstrations be related to the teams’ sprint goals; what if there is no such restraint for the teams? The sprint demonstration could be transformed into a type of internal meet-up, where not only do teams provide an exhibition of what they have worked on for their projects but also present topics that they feel might benefit the other teams as well. For example, a team whose members are inclined to experiment and conduct exploration of performance-related subjects might present their findings of programming language patterns to embrace (or to avoid!), whereas another team could show off a new technology that they have investigated. Aside from allowing developers to present items that genuinely interest them, permitting such presentations has the added benefit of allowing teams that might otherwise be unengaged in such meetings to participate as well, e.g. a tech-support team that would not normally have work that is related to the development sprint. Given that these meetings would undoubtedly take longer to conduct than ones that only presented sprint-related topics, it would be beneficial to adopt other aspects of tech demonstration meet-ups such as providing food and drink for the attendees, allowing voting (and small prizes) for the “best” presentation, and so on.

Remove The Formality: Sprint Retrospectives

It’s possible to take a step even further than before: instead of modifying the meeting’s “permitted” activities, why hold a “business meeting”? The objective of the sprint retrospective is to obtain feedback from a team’s members about how the previous sprint went, what they would retain/improve/eliminate, etc. This requires communication from the team members about their experiences, and such communication about past experiences and the opinions thereof is, in effect, a group conversation. There are other settings in which this kind of group conversation can be cultivated; one such example would be a team meal. As in, the team assembles for a meal – breakfast, lunch, dinner, whichever – and talks about their experiences during the previous sprint while they eat and converse about whatever other topics they might have in mind. Whether this food is provided by the company or by the participants of the meeting is up to the organizer, although having the participants supply the food (aside from being cheaper for the company!) adds the intrigue of a pot-luck wherein the participants can introduce their colleagues to foods that those colleagues might not otherwise be acquainted with, something especially poignant when working on a team with members from different cities or countries. However, the main benefit of this approach is the atmosphere that it helps to create. At its core, the sprint retrospective is an exercise in catharsis: the participants “unload” the feelings – both positive and negative – that they have accumulated during the sprint about how the sprint played out. When converting this meeting into a shared meal, the setting switches from the formal to the informal, and this relaxation of the ambiance can help draw out these feelings from the participants better than in the traditional format of the meeting, meaning more effective feedback and thus more effective input for how to improve further sprints in the future.

Parting Words

A qualifier that needs to be made here is that the practices described above occurred during the pre-COVID era – that is to say, before the widespread adoption of remote work. Some of the practices would undoubtedly need to be adapted for companies whose teams comprise members that never (or almost never) see each other in the physical world – for example, holding team breakfasts via a video call and from the confines of each team member’s own dining room or kitchen – and there is likewise the possibility that the productive effects of the approaches might be different for remote teams compared to in-person teams. Nonetheless, the base principle stands that it may be worthwhile to challenge the conventions of traditional meeting formats to discover whether any modifications to a group’s meetings can result in more productive and engaged teams. Reinventing the wheel does not need to be the be-all and end-all; it may very well be that what is already prescribed is the best solution for the team at hand. However, even such cases would stand to benefit from this exercise, as the end result would still be an introspection as to what truly serves the team well for its development process.