The After-Party of Daily Scrum

"Let us not discuss the technical solutioning here, please. This is the Daily Scrum call, and it is only meant to talk about how we are progressing towards the Sprint Goal, and what is stopping us - if anything is." The Scrum Master was right in saying so. However, a developer rightly pointed out "The people I want to discuss the solutioning with, are all available together to me only in this meeting regularly. If I don't discuss it now, I am not sure when will they be available, everyone works on a tight schedule. Classic frogs-on-a-weighing-scale situation!"

The time-box conundrum

Scrum guide has very few strict guidelines specified and one of them is time-box. Daily Scrum Meeting (DSM) works best when time-boxed to fifteen minutes. However, it is very easy for the team to glide into a technical discussion that could derail the DSM from its purpose and take longer than the stipulated fifteen minutes to complete. 

What is the issue if the technical solutioning is discussed in Daily Scrum by extending the time box? This can lead to two practical issues - boredom and resource wastage. 

If the technical solutioning discussion is happening between only a select set of team members regularly, other team members might get bored and decide to skip participating in the Daily Scrum altogether.

The team members who are not involved in - or interested in the solutioning discussion are wasting their important resource of productive time.

So, should we or should we not have technical discussions during DSM? What's the solution to this conundrum?

Meet-after sessions - The optional open-house for technical solutioning

Many Agile frameworks, including SAFe, suggest having meet-after sessions - also named the after-party sessions, that are dedicated to technical solutioning. However, little has been documented in detail about these.

I got a chance to implement the meet-after sessions for one of my clients where I worked as a Scrum Master. Below were some of the points agreed upon by the team before the introduction of the sessions:

• The meet-after sessions happen in quick succession to the DSM, preferably within the first hour of DSM.
• The meet-after sessions happen early in the day, at a fixed time every day. This slot is to be kept unblocked by the team members.
• The meet-after sessions are dedicated to technical solutioning, and no other agenda can be added to these. A dedicated meet-after board is to be the input for these sessions.
• The meet-after sessions are designated as optional open-house sessions. It is not mandatory for every developer to attend. Only those who seek clarifications would join the meeting and pull in the members who would provide clarifications. 
• During the DSM, if there are any technical questions/clarifications, they need to be noted on the meet-after board. These questions/clarifications will need to be taken up and cleared during the subsequent meet-after session(s).
• During the days when no one seeks questions/clarifications, the meet-after sessions do not happen.

Image: A sample meet-after board

Advantages and shortcomings of the meet-after concept

Table: Advantages and shortcomings of meet-after sessions

Conclusion

This article covers a rather important best practice of Agility - the meet-after or the after-party sessions. These sessions support and realize the Transparency, Inspection and Adaptation principles of Empiricism. Although they seem to have a couple of shortcomings, these sessions indeed define a process for keeping DSM away from technical solutioning. They also seem to have effects of unblocking the developers at the beginning of the day which can help achieve the Sprint Goal faster.