The daily formal ceremony of the Scrum framework attracted many views throughout the years on how it should or should not be done. The Scrum guide (2016) describes the daily scrum as a time-boxed meeting where the three questions should be answered, but also it says that the daily scrum is an opportunity for the development team to inspect the progress of a sprint and discuss how they are going to work as a team to achieve the sprint goal.
There are people who say that only the three well-known questions should be answered in a stand-up and that any other discussion should be held outside the daily scrum. Yes, that keeps the daily scrum short. But for one, if we follow that pattern, we are increasing the chances of having other meetings outside the stand-up (which is one issue that the daily scrum intends to solve). Secondly, answering just the three questions we are eliminating the chances of good communication in the team in regards to the issues that they should be solved to achieve the sprint goal. Hence, following that pattern, we save more time, but that comes with the price of insufficient transparency.
Since the daily scrum is a planning session for the next twenty four hours, it should be held in a collaborative spirit, where the development team members not only report what they have done yesterday and what they are going to do today, but also interact with each other to plan how to solve the remaining challenges. If testing is behind schedule for example, the development team members could show the appropriate courage to their colleague/s and plan some time throughout the remaining days to do some testing, so that the sprint goal is achieved.
Below you can find an example of a good stand-up and an example of a stand-up which is subject for improvement.
Daily Scrum 1 (as it should be)
John: Yesterday I implemented feature A and now that's pushed to QA. I also had a conversation with the Product Owner and it turns out that we need to improve feature B. The FE needs to improve error handling and that will take most of my time today. David, based on the artefacts that were published yesterday in regards to the error handling, how much more time will you need to allocate on QA?
David: I will need a couple more hours. Probably five hours, as I will have to test the validation on 7 fields, for both desktop, tablets and mobiles. Since it's mid-sprint and we have another two features to test, I may need some help with testing on mobiles for feature A, otherwise we will curry QA debt to the next sprint.
Chris: No problem, I can help with that. Yesterday I finished writing the web service for feature A, so after I finish with the back-end validation rules of feature B, then I will be able to help QA on mobile testing. Also John, could you please send me the JSON format of the error handling object, so that I implement them on the back-end today?
John: Yes, no problem Chris. You will have that before mid-day. Also feature C is still a blocker, as the URL's are still not ready yet. So I would recommend moving that to "blocked" until the support team fixes the issue.
ScrumMaster: Sure, I will remind the support team that the URL issue should be resolved ASAP. John, if you email me the exact error you get when you visit the page, I will pass it on to the support team.
Daily Scrum 2 (the wrong way)
SrumMaster: John, make a start...
John: Yesterday I implemented feature A and now that's pushed in QA. Also today I am going to work on the error handling for feature B. Currently I am blocked on feature C, as the URLs are not ready.
ScrumMaster: Chris...?
Chris: Yesterday I implemented the web service for feature A and today I am ready to start implementing the back-end validation and the JSON response for feature B. No blockers.
ScrumMaster: And you David.
David: Yesterday I finished testing feature A on desktop and today I am going to test it on mobiles as well. Also I will do some automated testing on feature A.
Do you see how transparent the development team at daily scrum 1 is? They don't care if the stand-up lasts 10 minutes or 15 minutes. They care about planning correctly their work and their time for the next twenty four hours. On the other hand, the development team at daily scrum 2, seems to be sacrificing the correct plan of action for the sake of time. Also the team at daily scrum 2 doesn't show the appropriate support and transparency as the team at daily scrum 1.
P.S: Note that the role of the ScrumMaster at daily scrum 1 is more like an observant rather than a person who is leading the stand-up. The Daily Scrum does not need anyone to lead it and the only people who are required to attend it is the development team. The ScrumMaster can write notes on the impediments and the struggles of the team, and the Product Owner to just track the progress.
Top comments (3)
Awesome
I liked the examples. I think this methodology is not complicated to understand, but rather difficult to implement.
Many people make some mistakes. But it's normal I guess.
The important thing is to focus on the sprint, update the team so that everyone is synchronized, and eliminate the impediments as soon as possible.
I wrote an article about the most common mistakes in the daily scrum.
tfsolucoes-tecnologicas.com/14-com...
Take a look. I think it might interest you.
I've been on 4 (ostensibly) Scrum teams.
Team Awesome
The teams where the developers are all working together on the same thing to get it "done done" done, are the one's who have the Scrum stand-up meeting to share what was just done, what is about to be done, and what problems they are running into.
Also incorporated into that Scrum stand-up was the "moving of the columns"... when you said you were done with something, that's when the task card was physically moved on the physical board. By the Scrum Master, acting as a proxy Vanna White. Fabulous!
Team Dreadful
The teams where the developers are all working on separate, independent things, and which the meetings are basically held -- not for the benefit of the development team -- for the benefit of product management (not the product owner... product management), the Scrum stand-up meeting is a status report. Not surprisingly, one of the things eliminated from this sort of Scrum was the position of Scrum Master.
Schwaber and Sutherland would probably have said "You're doing it wrong."
I agree, wholeheartedly. The point of Agile was to use the minimum process to support a team who essentially knew what they were doing. Scrum is increasingly turning into PRINCE-2 for Agile.