Back-and-forth questions in daily stand-up meeting

Question

In the context of daily stand-ups in scrum meetings, when the banter gets too heinous, what criteria should a scrummaster set for back-and-forth questions?

Say for instance, there's a developer and a tester working on the same thing, and the tester has questions for the developer about what they did the previous day (one is on the phone, so you can't just give 'em nasty looks or step on their feet), which are usually pertinent to the goals of the entire team and they keep it pretty quick (about 30 seconds to a minute).

What should a scrummaster or a member of the scrum team do? Is it not within their rights as fellow team members to ask clarifying questions of each other?

If it is even appropriate, when could these questions be asked? Right after the first person finished their piece or when the second person's turn comes around?

Answer 1

If the information is useful to the entire team, the discussion isn't stopping the standup from completing within the timebox, and the standup is achieving its purpose to inspect progress toward the goals and plan the day, there isn't a problem with discussions in a standup. Ultimately, everyone should continue to get better and providing relevant information to all present parties so that this back-and-forth isn't needed. If there are things that the tester needs as a task moves from development to testing, then the developers should understand what the testers need so they can provide it. Alternatively, the required information can be provided in the ticket so that the tester has fewer questions.

If there is a need for extended discussion, the best thing to do is to have those discussions immediately following the standup, between the people who are required to be in the discussion. Unless someone has an engagement immediately following the standup, it should generally work.

Answer 2

One thing I have noticed over the years is that some Scrum Team members feel that the daily scrum is the primary time they should communicate with other team members. This is particularly true in distributed teams.

As a Scrum Master I will encourage the teams to talk frequently as a part of their normal activities. The value of the daily scrum is that it tends to pick up communications that have been missed during a normal day. Perhaps one developer was making a change and hadn't bothered to communicate it because they felt it had no impact. But at the daily scrum they mention it and it is picked up by other team members as something they need to know about.

The daily scrum really shouldn't be a substitute for routine daily team conversation. If it is then I would act to improve things by:

• Raising the topic at retrospectives
• Checking to see if the team is happy with the tools they use for communication (text chat, phone, audio conferencing, etc.)
• Highlighting at the daily scrum where a conversation could have been had as a part of the normal daily routine

Answer 3

This is a great question highlighting an issue that many (especially inexperienced) Development Teams face.

During the Daily Scrum the Development Team members should be inspecting progress toward the Sprint Goal, noting impediments that need to be raised, and adapting their plan for the current day's work through a discussion. Focused questions in creating that plan are necessary. Conversations regarding details of how work was done or will be done are not meant for the Daily Scrum event.

Experience and/or coaching can help the Development Team reach a consensus on a technique to identify and address discussions that need to be tabled for later, after the function of the Daily Scrum has been fulfilled. As previously mentioned, a 30 second or minute rule can be helpful. As the Development Team members conduct the event, topics can be mentioned to be placed on a list to be discussed immediately following the Daily Scrum.

More importantly, as was also pointed out, this is indicative of a problem of a lack of collaboration by the Development Team members throughout the day; pair programming can help improve this disconnect. The opening post spoke in terms of developers and testers. While each person has distinct strengths, removing these roles and cross-training can also help reduce the risks.

Remember, as a Scrum Master your role is to teach the Development Team to conduct the Daily Scrum within the 15 minute time-box, not be a participant in the event. It would be fruitful to observe the event as needed (more frequently for a less experienced team) in order to identify possible areas for improvement to be suggested at another time such as during the Sprint Retrospective event.

While one result of the Daily Scrum is a shared understanding of progress, it is not a status meeting. Remove that term from the language. Remove practices such as pass-the-baton that result in such an event. It should feel like a planning discussion rooted in the three questions.