After over 12 years of developing software professionally, I’ve been on all sorts of projects. In most of them, they used Scrum, or at least something inspired by Scrum. I thought this was normal until I got certified as a Scrum Master. Then I reflected on the problems those projects had and identified some common mistakes while using Scrum for software development.
Allow me to share them with you so your project avoids these pitfalls:
1. Daily Scrum is not a Status Meeting
All over the world, there are Developers answering daily to their managers three famous questions:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
The first two questions are far from what Daily Scrum should be about: Inspect progress towards the Sprint Goal and adapt the work being done in order to accomplish this goal. The Scrum Guide emphasizes on how Daily Scrum is a meeting for empowered and self-managing Developers. But how are you going to be empowered if the meeting is about reporting to your superior?
The third question is more aligned with the purpose of the Daily Scrum. It can lead to technical discussions, but, being a meeting for the Developers, that is good and intended. Also, participation should not be required from everyone.
More appropriate questions for the Daily Scrum could be:
- Does anyone have impediments to their work today?
- Will anyone do something that could impact other developers today?
- Are there any new risks affecting our Sprint Goal?
- Do we need to adjust our plan for the Sprint Goal?
Developers can provide their status to other developers, so the team can inspect the advance towards the sprint goal. Reporting to managers should ideally occur in a different scenario.
Developers are not interested in knowing what his colleagues did yesterday. They want to know if some of that is going to interfere with their own work. Also, once you remove the requirement for everyone to speak, some days the team would not even need to use all the 15 minutes allowed, which is completely fine, in fact, is awesome. The less time spent in useless meetings, the more time to work on awesome stuff.
2. Daily Scrum is not a General Purpose Meeting
The Scrum Guide proposes a lot of flexibility and self-managing to work out the details of Scrum. Nevertheless, none of the events of Scrum are general-purpose meetings, they all have clear objectives, participants, and are time-boxed. In particular, it imposes a time limit for the Daily Scrum of 15 minutes. This could look arbitrary, but is related to another limit that Scrum sets, the size of the team: 10 or fewer people.
That is not a coincidence.
If you are going to have a daily meeting, it needs to be quick. If there are more than 10 persons in a Daily Scrum, most likely you would waste the time of all the Developers hearing details not relevant to them: like project budgeting, meetings with clients or upper management, hiring of new members, technical discussions irrelevant to them, etc.
Of course, big projects need more than 10 people. In those cases, you can create several smaller Scrum teams.
3. Project Manager and Scrum Master are different roles.
Scrum does not consider the role of Project Manager, Scrum is concerned with making projects a reality, not managing all the aspects of a project inside an organization.
A Project or Team Manager usually has to deal with staffing, training, budget, absences, and supporting the development of the project among other responsibilities. On the other hand, Scrum focuses only on the development of the project. So, the primary responsibility of the Scrum Master is to facilitate people to work using Scrum and thus improve the Team effectiveness. This is a clearly defined role that can be done by one of the Developers, or by a designated Scrum expert, not by the team or project manager because then we are introducing subordination of the Developers to the Scrum Master, and that’s when the Daily Scrums become status meetings.
4. Using a subset of Scrum is not Scrum.
I don’t think all projects should use Scrum. I don’t think Scrum is the best or only way of developing a project. But in some projects, they just start removing things from an already lightweight framework, and most of the time, the main reason is they don’t understand Scrum very well.
- “Why have a Sprint goal? Isn’t that just a pretty and void phrase?”
- “Why have retrospectives? Isn’t that just a back-patting meeting?”
- “Why have a Daily Scrum?” I am sure we can save a lot of time if we make it weekly.”
Are the kind of thoughts an inexperienced Scrum Team might have. They skip some of those Scrum Events or Artifacts and, at first, it seems like a great idea. But each sprint, the problems they resolve, start to grow until they explode in one way or another.
In specific for the given examples:
- The Sprint Goal is a pillar of your Sprint. It helps your team to be goal-oriented instead of task-oriented. It provides flexibility but also ensures the team is providing value to the organization at the end of the Sprint.
- Retrospectives are a fundamental part of a process that is incomplete by definition and relies on self-improvement and adaptability. Also, it helps to identify bottlenecks and lets the team blow off some steam after difficult sprints.
- A time-boxed Daily Scrum of 15 minutes implies 75 minutes per week. This is a lot less than the time lost due to miscommunication problems if the Developers discuss only one time per week.
5. Scrum is not Jira, Asana or Trello
Did you know that Scrum Guide mentions nothing about story points, QA team, or Continous Integration?
There are a lot of tools designed to help your team organize your Scrum workflow, but if you just use their features without really understanding Scrum, you might end up giving more importance to some of those software features than to the framework that supports the development of your project.
Scrum is opinionated, it has some strong theories behind it, but not everything in it is obvious or all-purpose ready. It just has been very useful for diverse projects and organizations. So if you do not understand the values, theory, and way of thinking it proposes, you might see no point in some of the things it asks from you and maybe you would not understand how to adapt it to make Scrum work for you, instead of you trying to work out how to use some expensive software.
Also, you risk getting overwhelmed by the gazillion of features these software suites offer. Scrum is easy (the whole Scrum Guide 2020 is just 14 pages long) but mastering all these different tools can be a pain. And what if you become a master in one of these cool tools, but your next project uses a different one? I think most software for helping projects deal with Agile Frameworks provides good value. But let’s not forget that you can be agile just with pen, paper, and post-it notes.
Conclusion
Scrum believes strongly in empiricism, adaptation, and self-managing teams, so it does not tell you how to do everything. When you are using Scrum, the experience of each member becomes an important asset of the process itself, so I hope these problems I have identified in my years working with Scrum can be useful for you too.
If you are a software developer, there’s a good chance you have or will work with Scrum on a daily basis, so it makes all the sense in the world to read the Scrum guide if you have not done it yet. It does not matter how much time you have been working in the industry, I can guarantee you will get some valuable insights from it.
