Scrum is a framework which when adopted in its true sprint will be a major contributor in the success of a project. However it is not a silver bullet and if not implemented properly will not be effective.For scrum to be successful things need not be perfect from day one. As an agile coach it is the responsibility of the Scrum master to help the team identify the shortcomings and empower them to fix it. Following are the top reasons for scrum failure that Scrum masters should watch out . Effectively sorting out these issues will help the Scrum master transform a low performing team to a high performing team delivering value to customers.

Lack of self organized team

The success of a scrum team heavily depends on how self-organised, the development team is. One of the main reasons for Scrum not to take off is lack of self organized team.Most development team members, with a background in traditional software development methodologies are trained to follow instructions and may not be self organized by nature. They rely heavily on Scrum master , Product owner or even leaders within themselves to give instructions or take decisions on their behalf. 

Following are qualities of a self-organised team that the Scrum master should look for in his team:

• The self organized team takes decisions on how to implement the requirement. They will not depend on a ‘ software Architect’ on deciding the architecture. The team may seek advice from expert however the final decision on which advice to accept will be with the development team
• Self organized team pulls backlog items from that backlog themselves instead of a product owner assigning work to them. The team will consider the priority of backlog, scrum goal, their capacity and other dependencies while deciding which backlog items are to be included in the sprint.
• Self organized team doesn’t report to the scrum master or the product owner . They are accountable to and report to each other. 
• On facing any blockers or impediments, they proactively take steps to mitigate it, if it is within their capacity, or seek help from Scrum master to get it sorted.

Team members not practicing scrum values

Scrum has three pillars and five values. Scrum events and artifacts are built to incorporate the three pillars of transparency, inspection and adoption. The values of scrums are personal qualities that the team should inculcate in themself and practice while working in the project. Building a scrum team adhering to all five values of scrum is a big challenge for Scrum master especially when working with a new team. A Scrum team, without the five values of courage, commitment, openness, focus and respect, is like a body without life and soul. In appearance it will look as if it is a perfect Scrum team with it’s roles, events and artifacts, it will seldom achieve what a perfect Scrum team was supposed to achieve. To avoid this from happening the scrum master should make the team understand what the Scrum values are and its importance. In the mentoring stage, the Scrum master should observe the teams behaviour closely and should jump in and correct the team member whenever a breach in scrum value is seen. Following are the Scrum values to be preserved

Courage– The team needs to have the courage for doing things and not to be swayed from the path of scrum. It requires courage to say no where ever required, not hiding unpleasant facts, owning responsibility and so on.

Commitment – When the team members take up a comment they need to try their level best to keep it.

Openness – Openness implies maximum transparency. Nothing is hidden from anyone.

Focus – Team members should take a deliberate effort to stay focused on the sprint goals even if there are internal or external distraction

Respect – Team members should trust and respect each other. 

Diluting scrum framework by bringing in non agile activities 

When people with extensive work experience in traditional software development methodologies, try to adopt scrum there is a high probability that they will try to bring in their old practices to scrum. This could be in the form of unnecessary meetings, documentations or practices. Even though the objective may be to benefit from the best of different methodologies, most of the time it ends up getting the worst of different practices. Such dilutions often lead to unsuccessful implementation of scrum. The Scrum master needs to understand here that there is no middle ground, either there is scrum or not. Whenever there are suggestions from a team member to include non agile practice scrum master should speak up and educate them on why it is wrong

Product owner not able to dedicate enough time to the team

Product owner’s job is a full-time job spending half of the time interacting with the development team and half of the time with stakeholders. However many times the people with the knowledge to become product owner’s are from top management with multiple responsibilities. In such cases often time allocated to the development team is compromised . It is the product owner who identifies and prioritises features that will add value to the user. It doesn’t matter how efficient the development team is, without a properly refined product backlog, the entire effort of the development team will go to waste. This will cause the scrum to fail. The scrum master needs to see that this doesn’t happen. If the product owner is over occupied with other activities, the solution is to find help for the product owner to do other activities so the product owner can fully focus on scrum. Following are some signs the scrum master should look out for, that indicates that the product owner is over occupied and need to free up time for the team:

• There is not enough refined stories for at least two sprint
• Product owner does not show up for important scrum events
• Product owner is not available to provide clarifications to the development team’s queries
• Backlog refinement is not regularly done.
• Product Backlog items which are not adequately refined are being taken up in sprint

Product owner not aligned with the end-users

Product owner’s should dedicate half of their efforts towards interacting with end users and stakeholders to understand the requirements better. This helps them to create and prioritise product backlog items that will really add value to the user. If this doesn’t happen the user will not see the value delivered even if the development teme is working efficiently and all the tasks are completed on time. Scrum will certainly fail in this case. Scrum masters should identify such issues and work with the product owner to understand this problem, thus enabling them to work with users more closely. Following are some signs that the scrum master should look out for:

• Lot of change requests are coming in features thought to be completed
• Stakeholders and end users not invited to sprint review meetings
• Customer releases not happening often
• Little or no feedbacks from end-users
• Product owner themselves not very sure about the requirement

 Not having a solid product Backlog

There should be a healthy product backlog available for the scrum team to be successful. The product backlog can be termed healthy when there is enough refined, estimated and prioritised backlog item for at least two sprint, excluding the current sprint. Following are the issues the team will have to face without a healthy product backlog:

• Team will have limited options in the product backlog, to take up, during sprint planning. This may cause an issue if the team is not totally cross functional. There will be occasions when the team’s capacity cannot be fully utilised.
• Team will have to take up backlog items which are not fully refined causing issues and confusions in the sprint.
• Team will have to take out extra time from the sprint to refine Backlog for the coming sprints.

In order to avoid this from happening, the scrum master needs to monitor the product backlog health regularly . If the Scrum master sees the health of the product backlog deteriorating, he or she should work with the product owner to bring it back to health.

Inappropriate project type for scrum

Scrum does not fit all types of projects and if applied to the wrong type of project it will fail. Scrum maynot be a good choice in the following case:

• The requirement is fixed and will not change
• End users or their representatives are not available for feedbacks
• Partial deployment or testing is not possible or are too expensive
• Repetitive nature of work where innovations and out the box thinking are not required
• Very short duration work

In this case there is not much the scrum master could do since in most cases, the Scrum master is onboard only once the decision has been taken to adopt scrum. However the scrum master should voice his or her concerns to the management and should make his or her voice heard.

Not following agile development practices

Scrum is different from traditional software development where a potentially releasable increment is expected  at the end of each sprint. This means there could be a release every week or fortnight. To achieve this consistently, there are a set of development practices the team needs to follow . Following are some examples:

• Test driven development
• Continuous integration
• Continuous deployment
• Pair programing
• Automated functional testing

Without adopting these practices though short-term impact maynot be felt, but in the medium and long term, will cause issues and could even hamper viability of the project. The scrum master should encourage the team to follow these development practices for long-term success of the project

Closing note

The Scrum guide says that Scrum is simple to understand but difficult to master. It is easy to find a scrum team that follows all scrum practices, but that doesn’t mean it is successful. A smart scrum master can identify reasons that is holding back the team and fix it to create a high performing Scrum team.