Scrum should work for you. Don’t work for scrum.

Daily scrums may not be the most efficient way to disseminate information for every team

A common argument leveled against criticism of scrum is “You are doing scrum wrong; that is not how scrums work”. However, if habits and human behavior are frequently breaking down a system, it’s more reasonable to change the system than forcing everyone else to be rational and disciplined.

If we think about the cons of scrums:

• Many scrum participants are zoned out when someone is speaking about something that does not affect them.
• Anyone who misses a scrum session does not know what was discussed in that scrum session unless the additional step of summary emails is taken.
• Scrum indirectly discourages research and planning because nobody wants to say they are researching something for the second straight day.
• Most employees stop working 5–10 minutes before the scrum because they don’t want to start working on something that will be paused soon.
• Employees who work on multiple teams have to join multiple scrums which take over a significant part of their day.
• Employees who do not enjoy public speaking do not speak much during scrums and do not disseminate everything that is required.

There are some positive behavioral effect of scrums as well:

• Enables management to track what is being completed on a daily basis.
• Creates a sense of accountability as everyone states that they intend to complete ‘x, y or z’ today.
• Enables participants to ask for any assistance or information required every morning, instead of sending messages or waiting till someone is available to help
• Hard for employees to avoid because everyone is expected to present and participate in some form.

If we take a step back for a second and ask ourselves what the purpose of a scrum is, it’s to get people on a team to communicate with each other.

Teams can mainly communicate through two ways:

1. asynchronously (via email, messaging, pre-recorded video)
2. synchronously (in-person, messaging, video calling).

Once a team has decided how to communicate, they also have to decide what they want to communicate. By choosing to conduct scrums, a team not only decides to communicate synchronously, but also gets a list of three items to be communicated during the scrum:

1. what was completed yesterday
2. what will be completed today
3. anything preventing members from completing tasks

If a team decides scrum is not working for them, they can choose to:

1. communicate synchronously but communicate different information, or
2. communicate asynchronously but communicate the same information, or
3. communicate asynchronously and communicate different information

Now that we have recognized the four different ways teams can communicate, we can rearrange the pros and cons of scrum.

Based on the cons, an ideal system would:

• Not take too much of the team’s time.
• Not encourage participants to lie or leave a task partially incomplete.
• Have a record for people to look back on what was discussed.
• Not only broadcast information, but ensure that it was heard.

We would also want to retain some of the pros:

• Ensure all employees participate.
• Ensure any assistance required is communicated.
• Teams are aware of what tasks are being completed.

Making people feel accountable and allowing management to track development isn’t something which should be done on a daily basis. If daily updates are necessary, that team has bigger fish to fry than doing daily scrums.

If I were to design a system for teams to communicate information, it would:

1. Begin with all team members messaging a project manager listing all tasks they have completed and begun by the end of day, including what they need help with and which team member would be most helpful.
2. If a team member has been working on the same task throughout the day, without a change in status, and they do not need help, they do not need to send a message.
3. The project manager aggregates all of the messages and sends out a message every morning listing all the tasks that have been completed, begun and items which require assistance along with the requested helper.
4. The helper is responsible for contacting the helpee regarding their availability or assigning someone else the task.

In an ideal scenario, the project manager message sends the message out via a messaging system that the team does not used for any other purpose. This would avoid a scenario where the project manager sends out a daily email that gets buried in everyone’s inboxes. Following these steps would not only be asynchronous enough to save time, but would contain enough information for everyone to do their jobs.

There are some teams which currently implement daily scrums and have success with their approach to it. If a team has an excellent scrum master who is able to keep everyone’s updates brief and keep everyone engaged, or a team is comprised of members who are good communicators and listeners, they would be better off sticking with Scrum. For everyone else, it would be best to find a messaging service not being used by the team and use it to send updates instead of pointlessly waiting around every morning.