Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Keeping a watch over the Daily Scrum not lasting for more than 15 minutes ..

We were having a discussion (a discussion among fellow Scrum Masters) and were trying to resolve 2 contradictory principles that we held dear, related to the Daily Scrum. One of the principles that we held dear to the Daily Scrum was about the length of the Scrum – it should not be more than 15 minutes. Why 15 minutes ? Well, the assumption is that if you stick to what should be stated by team members to each other in the Daily Scrum:
– What did the team member do the previous working day
– What is the team member planning to do on the current day
– Are there any impediments that would block the team member from getting the task done or makes it more difficult
The calculation is that if team members stick to these statements and do not try to get into speeches or start enumerating the technical issues that they are facing with diagrams and other explanations, these together from all the team members should not take more than 15 minutes. Teams enforce many sort of rules to ensure that these end in 15 minutes, which also includes ensuring that they start at the appointed hour and do not get delayed. As a result, there are rules and penalties enumerated by the team that apply to anybody who is late for a meeting or misses the meeting (without a sufficiently valid reason, even if the people are remote), teams are also known to hint to people who take more than their estimated amount of time for enumerating these 3 items. At the same time, the Scrum Master also keeps a watch when team members start taking up more time, or when there are impediments that can take more time than the short period of time that each team member would have. If this starts to happen on a regular basis, a good Scrum Master would try to analyse what is happening, see whether this is because of specific team members or there are other structural / design / infrastructural issues because of which these are starting to happen. One result of meetings starting to get longer is that people start to feel that things are getting out of control, that their time is getting wasted (even more so when they feel that they are following the principles and somebody else is not).
This sounds fine, so what is the other side ? Well, the above principle sounds right, but the catch is about whether the team is comfortable or not. In some cases, where there is a lot going on, where there is the need for a lot of cooperation between team members, or whether the work is fairly complex, simple matters such as being able to explain what was done, what was going to be done, and issues that are affecting them can take time is that more than 15 minutes. If the team is fine with this, and you do not see any discomfort on the part of the team members for longer Daily Scrum meetings, should the Scrum Master try and do something ? That would conflict with the concept that the Scrum Master is not supposed to enforce his / her own thoughts and principles on the team, and instead work with the team and thus figure out what is going right and what is going wrong. The Scrum Master can do some analysis on whether everything is going right or not, but if turns out that this is the way that the wants it and is comfortable with it, then this is the way it should be.
These are 2 conflicting principles, and we had a number of discussions; in the end, however, it seemed to be that a majority of people turned towards the second viewpoint, where if the team is fine if the Daily Scrum is going over 15 minutes and the Scrum Master cannot figure out some problems that is making it so, then that should be the preferred method. What do you folks think ?

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>