Scrum Practices: Daily Scrum

Scrum is an agile methodology applicable in principle to nearly any type of project, but with a high rate of adoption in software development. It is suited for projects where requirements cannot be known in advance to their full extent, are changing rapidly and are highly emergent. That is the case for 90% of the software development projects. Agile methodologies, Scrum included, have emerged from the fact that heavy development methodologies, with many processes, procedures and comprehensive documentation have been proven an obstacle in finalizing the project with success. The Agile Manifesto refers exactly to this:

  • individuals and interactions over processes and tool;
  • working software over comprehensive documentation;
  • customer collaboration over contract negotiation;
  • responding to change over following a plan.

While the elements from the right side of the statements are also valuable, more value is found in the elements from the left side.

More simply viewed, Scrum is a set of management practices. Each individual practice can be applied outside a Scrum process, but the maximum value is obtained by the combined usage of all.

Recently I was asked what practice, from the set proposed by Scrum, I would adopt in the context of a non-Scrum project. Without too much thinking, I answered: Daily Scrum. From all Scrum practices, I find this one incredibly powerful and very useful in any situation. Let's dive in a bit to see what it assumes and how should be properly applied.

The Daily Scrum is, as the name implies, a time-boxed daily meeting (10-15 minutes) held by the development team every morning, during a sprint. All team members must attend, including Scrum Master and Product Owner. Anyone else outside the team can only assist without to intervene. Each team member will need to answer three questions:

  • what did you do yesterday?
  • what will you do today?
  • are there any problems you are facing?

At first look, the Daily Scrum might look like a regular status update meeting in which the project manager is collecting information about who is behind schedule. But it isn’t anything like that. The main objective is the team to have an excellent understanding of what work has been done and what work remains. The fact that a programmer says “I will complete this integration today” acts like a commitment to the other team members to complete the work and this is more powerful that any commitment to a customer which is far-off. All the other team members expects that, on the next day, the programmer will say that he has completed to work he assumed a day earlier.

When asked about the problem faced, the team members should not refer only to the technical ones, strictly related to the implementation of their current tasks. Any problem should be mentioned. Scrum Master’s job is to try to solve these problems, or to address them to the appropriate persons who can (from the team or from outside the team), as soon as possible. During the meeting, the problems are recorded but will be addressed later on, in order to keep the meeting short. Another advantage from revealing the problems faced is that someone else from the team might be able to help you (for example, you are having a problem with a framework that your team member is more familiar with).

Scrum Master’s job is to make sure the meeting stays short and does not become a problem-solving meeting. Also he/she needs to make sure that all team members will answer to the three questions, one after the other. There are some variations on this practice: instead of going person by person, it will go from one sprint backlog item to another. In this way, a person might give multiple updates if involved in more than one item at the time (not recommended, but possible). Also, in some cases, the meetings are held standing up, in a circle, away from the offices, in order to ensure that every participant is focusing 100% on the daily scrum and is not distracted by other matters.

The most difficult aspects from implementing this practice is to keep it short and to keep it daily. People either tend to prolong the discussions, or to skip some meetings especially when some urgent issues appear. But the benefits are extraordinary:

  • it builds a stronger relationships between team members since everybody knows what everybody does and/or will do next;
  • it helps problem solving by revealing the problem to the whole team; someone from the team might be able to help on the problem, or, if not, at least everybody will know about it, the Scrum Master will need to act upon it to solve it, while the team can monitor if this is happening, during the next daily meetings;
  • makes all team members aware of other parts from the system developed, not just the ones assigned to them;
  • it gives a very accurate status update.

From all the elements presented above, there is nothing that links this practice only to Scrum. It can be used in any software development methodology, general or custom. Bringing the people together every day improves communication between team member, improves the rate of solving the problems faced during development, and help on building the view of the whole system that every member of the team should have. These are critical aspects in any software development process.