Before talking about daily scrum, we must say that Scrum is a framework applicable in principle to nearly any type of project, but with a high rate of adoption in agile software development. It is suited for projects where requirements cannot be known (this is what the Agile mindset is all about) in advance to their full extent, are changing rapidly and are highly emergent. T
hat 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 projects with success.
The Agile Manifesto refers exactly to this:
While the elements from the right side of the statements are also valuable, the elements from the left side are more valuable in terms of the successful completion of the project.
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 it 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 (preferably, but not necessarily), during a sprint. All the team members must attend, including the Scrum Master and the Product Owner. Anyone else outside the team can only assist without intervening. Each team member will need to answer three questions:
All these questions will evolve along with the growth of the team.
At first glance, 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 that the team has 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 as a commitment to the other team members to complete the work and this is more powerful than any commitment to a customer which is far-off. All the other team members expect 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. The 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 of 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).
The 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 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 he/she is not distracted by other matters.
The most difficult aspect of 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.
The benefits are extraordinary. It:
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 members, improves the rate of solving the problems faced during development, and helps in building the view of the whole system that every member of the team should have. These are critical aspects of any software development process.
This article is part of a bigger topic called: Agile Software Development
Implement light Lean-Agile in Enterprise in your business create the ability to deliver highly profitable products …
Scrum Framework Fundamentals is designed to help get new teams up and running. If you want …
The Leading Empowered Teams course that teaches the foundations of great Agile leadership. It presents the …
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
