If your company is new to Agile development, there is a chance that some roles and ceremonies will be interpreted wrongly. Most companies are rooted in waterfall project management methodologies, but Scrum differs vastly from traditional concepts of product development and it takes time to get used to a whole new set of principles. In this article, we will give you common mistakes we came across that people tend to do while working in a Scrum.
1. Daily Stand-Up is a status report
While it is true that attending the daily stand-ups you can get a grasp on how things are coming along in the sprint, their purpose is more focused on the future than the past. Attending the daily stand-up is about sharing useful information between team members and discussing what is coming next.
Often those meetings become a status report where everyone is stating what ticket numbers they completed. Those meetings don’t benefit the team and they perceive them as time-wasters.
2. Daily Stand-Up is 15min long
There is a maximum duration that a stand-up meeting can last but there is not a minimum one. If the team has not much to report, it is ok to end the meeting fast. It is still good for everyone to attend the meeting because if someone has no issues they want to discuss, maybe there is someone who could use their help. Also, it shows respect to other colleagues. Keeping the meetings short as possible will underline the fact that the team has a good grasp of Agile principles of which one of the most important ones is “eliminate waste”.
3. Tasks in the ongoing sprint are locked in
It is preferable to have things planned out before the sprint start, but it can happen that some new information can cause the sprint to change. Agile is all about flexibility and it is more important to respond to change than sticking to some rules. On the other hand, if those changes happen constantly that you can not plan a week in advance, then maybe Scrum is not the best choice for your project. Luckily, there are other Agile frameworks like Kanban that could help you out in those situations.
4. Retrospectives are a luxury and are held if there is time
It is not rare that a company sees retrospectives as a luxury and a time-waster. There will always be a time crunch, but we should not put retrospectives to the side. Maybe a solution to eliminating that constant time deficit can be discussed over a retrospective meeting. One principle in the Agile Manifesto states that the team has to reflect on itself to be more effective. Having retrospective meetings is critical. Without them, you are doomed to make the same mistakes over and over.
5. The retrospective is just a way to clear some air
Even when everyone understands the importance of a retrospective meeting, it rarely makes the impact it should. Often it is a meeting where everyone is telling their side of the story and a Scrum Master writing everything down without immediate action.
To avoid that, add concrete actions in the form of tasks to the sprint backlog, and set a due date on the tasks so they don’t dwell in the backlog forever. This way the retrospective is not just a way for the team to get relief by telling what bothers them, it is also a powerful tool for self-improvement and adaptation.
6. Sprint Review is just for developers to show their work
While Sprint Review IS a meeting where developers present the work completed in the last sprint, it is also an opportunity to discuss the overall status of the project. Product Owner can show velocity charts and discuss the estimated time of delivery. The entire team can collaborate and discuss how the market has changed and what would be the best thing to deliver next. Timeline, budget, and marketplace can all be points to discuss at the Sprint Review meeting. Reviewing things constantly is in the spirit of Agile methodologies, and Sprint Review meetings are a perfect opportunity for the team to review where the project is heading.
7. Scrum Master acting as a mediator between the Development Team and Product Owner
This mostly happens in companies that recently adopted the Scrum framework. It takes time to accept that there is no hierarchy in Scrum and that we are all part of the same team. If a developer has questions about a task, he should go directly to the Product Owner and vice versa.
