10 common scrum mistakes that should be avoided

When people think of agile, they think of " Scrum." Scrum is a widely used, or even been abusively used. Scrum is conceptually simple, but it is difficult to use. Here are 10 common Scrum mistakes and how to avoid them.

Converting to Agile/Scrum is easy.

Usually one reads a book about agile or Scrum, then starts to turn requirements into user stories, daily meetings, and develop a software in two or three Sprints, and then they call themselves being agile. It's easy, right? It might bring improvement over time, but this will not last long. When improvements are not so obvious, or when the team cannot keep up with the progress and the software can't meet the user's expectations, agile is considered to be a failure.

Effective agile often happens in corporate culture. It takes time to get ready for the change and fight against the resistance to cultural change.

Do not follow the guidelines

It's easy to launch a Scrum meeting and to choose the right Scrum tool, but it's just a start. Being agile is to make it well practiced and sustainable in the long run. Guidelines are more difficult than practice. This is why many companies don't have any. They do not follow the guidelines. Using agile techniques, they did not think about why they would use them in such a way as to cause setbacks. Agile is related to people, interaction, culture, not processes, practices, tools.

Complicate Agile/Scrum

Do anything you can to make agile simple. Agile projects can be done without the latest and coolest tools. The tasks written in the Kanban, and the burndown charts manually updated mark the work done. Spending your precious time acquiring and running tools, rather than just gathering developers together, is a concern for agile. The Agile Manifesto believes that individuals and interactions are more valuable than processes and tools.

Lead the Scrum team like a project manager

The "command and control" mentality exists in the agile framework. Leaders assign tasks and estimate time is anti-agile. The excellent agile team is self-organizing. The Scrum Master is a service-oriented leader. Team members can work together better through regular inspections and mutual adaptations, and deliver results more efficiently. In general, learning from experience is more effective than being told what to do. Scrum team use their own judgments, make mistakes, learn from themselves, and gain self-satisfaction as an efficient team.

An unprepared to-do list

An unprepared product to-do list is one of the most common causes of sprint failure and team inactivity. This is also the root cause of inefficiency and lack of high output. Most product owners are not effective on their own. They need to be mentored, trained, and hands-on taught at the beginning of several Sprints until they know how to develop and maintain product backlogs and how to evaluate functions of values at the macro level and prioritize these functions with commercial value. Before the next Sprint begins, it is necessary to prepare the to-do list. You don't want the team to do irrelevant work. The team must be the most valuable at that point in time. To be a team leader is time-consuming. Set correct expectations, provide all training, and help product owners maintain value circulation.

Communication through Scrum Master

One of the things that are common in the newly formed Scrum team is that developers pass information to other members through the Scrum Master. For example, a developer has questions about software requirements. Instead of asking the product owner directly, he emails Scrum Master to get the information. A core agile criterion is to communicate face-to-face whenever possible. The questions that are written in a message can be answered directly from the product stakeholders. However, for many developers, face-to-face communication is terrible. They are accustomed to sitting in their own cubicle and not communicating with anyone. This is a problem of programmer culture and it must be overcome. This is a waste of time, and even worse because it increases the risk of poor communication.

The product owner does not participate in the team

Being a product owner is time-consuming. Many rookies is not yet ready for the responsibilities of the team. In the agile world, cooperation is crucial. Managers and developers need to work together to produce the software. They verify or fix it through continuous communication, cooperation, and sprints. The agile practice is that product owners participate in daily agile project activities, and agile review meetings are purely a formality. Because POs have seen several rounds of iterations throughout the sprint, and have led the entire team to develop the software. This is a very wonderful thing.

Daily standup is slack

The daily standup meeting is very important. It enables the development team to communicate with each other for 15 minutes each day, improve exchanges and cooperation, and provide a transparent picture of the project. For such a key meeting, it is necessary to set the expectations, so that team members will take it seriously. This may sound radical, but the attendance of daily meetings is a must. Start on time and end on time. Adhere to three questions (what tasks did I complete the project yesterday, what tasks I will perform today, and what prevents me from completing the work on time). Do not allow other conversations, discussions, or problem-solving at the standup. This makes team members to respect the time of each other, and they can learn to communicate by meeting goals and simplifying their talk.

Not raise the problem encountered asap

The daily standup meeting provides an opportunity to talk about problems in the work. One main responsibility of the Scrum Master is to clear obstacles so that team members can focus on developing software, but Scrum Master cannot help solve them. It is unacceptable to propose it too late to recover. Unless team members are accustomed to talking about problems on time, the Scrum Master needs to remind members at the start of the meeting of any problems or even potential ones. If not, it may stop their work or cause them to fail.

No retrospective meeting after each Sprint

One of the twelve guidelines of the Agile Manifesto is "At a fixed interval, team members need to reflect on how to become more efficient and then adjust their behavior accordingly." Unfortunately, Sprint retrospectives are always considered as add-ons. In fact, being agile is about adjusting and responding to changes everywhere. If we don't think about what needs to be adjusted, we can hardly make changes. Maintaining the status quo is not agile, but continuous improvement is.