Think Different: 3 Best Practices to Avoid Scrum Breakdown
Many scrum masters in their everyday work have faced situations where scrum has produced not so ideal results (some type of Scrum failure), not because the agile methodology is wrong, but because the company hasn’t understood, or disrespected, how scrum should work.
In some cases, minimal time is spent for the development of user stories and the team has to make presumptions, since the business stakeholders were unavailable. If the team is close to completion, the stakeholders will appear and will expose more business rules that require not only extra engagement but also re-work of things that were already completed, including global changes to the company’s frontend and backend. The influence to the business is not accordingly analyzed, and when the new feature was developed, the total value was negative, causing refunds and conclusively – a financial loss.
In reality, such scenarios can also happen to your project. The scrum methodology is a great choice for situations with frequent changes, but many companies can hardly find the right approach to implement and manage those changes. Scrum collapses when teams don’t build a shared consensus on which principles should form their definition of agile delivery, or fail to teach everyone involved – on how the agile processes should work. The basic issue that can bring problems is the core agile artifact – the Sprint. Many teams spend a long day of planning only to run into an executive who wants to add something to the sprint.
1. Choose a convenient Sprint length
The most important issue is to determine the sprint length that is suitable for your company. It is recommended that organizations new to scrum should avoid 1 week and 4-week sprints. 1- week sprints move could be too fast for new teams and are very intensive with meetings. On the other side – 4-weeks sprint teams face a problem to focus on the sprint plan, especially new teams who don’t fully understand the impact of changing priorities in the middle. It may be a case when four-week sprints could work, but in most cases, a 4-week sprint length makes it difficult to keep the team on track.
Cycles of two weeks have traditionally been the preferred length for agile practitioners. When the team works on a project where code will not be moved to production at the end of the sprint, a 2- week sprint duration works fine; however, some production teams prefer three week sprints, because they can develop new features in the first 2 weeks and use the last week to do preparation work for production. No matter which length is chosen, it should be adapted to work with your product environment. E.g. if you currently use 3-weeks sprints, and your scrum master is permanently trying to keep the sprint plan, then maybe a 2-week Sprint plan would be more convenient.
2. Teach your stakeholders
When your company will decide about the sprint length, informing of the stakeholders is essential. You can expect stakeholders to work with implementing scrum only if you can help them to understand how it should work. Sending them the sprint calendar is a good first step. Stakeholders should be explained the role of the product owner’s (and how they will help them in clarifying their requests) and the requirements priority in the product backlog. You will get benefit by this since many stakeholders who want to apply the product backlog don’t understand that some high priority functions have not yet been accomplished.
You should be able to decide which feature is more important to be developed at a certain moment. That decision will save you many efforts as a scrum master. Some stakeholders will need to have a view on the backlog and will not bother the team to stop work on ongoing tasks. If their request is of a high priority item at a certain moment, you should start analyzing the desired behavior. Until the next scheduled sprint meeting – the team will have a much better idea what the requirement is about and will be more likely to complete the function with the value described by the client.
3. Build Confidence
Finally, and also important, the team must enforce confidence between the stakeholders. This will have a big influence on the scrum teams and will stop most emergency requests. Teams can build confidence by defining objective sprint goals and by fulfilling those goals on a consistent basis. The stakeholders should know – what is planned and what is done, so they will gain more confidence that their requirement will be accomplished in best order. This is a rather complex task, but it can be completed by improving sprint planning.
The most effective way to improve sprint planning, and one that is sometimes neglected, is performing a sprint retrospective. In this event – the project team reviews the team performance during the sprint and decides how should they continue and which tasks have to be improved. At this stage the team decides which items will make the largest influence on the next sprint and discuss for ways to improve. The retrospective is recommended since it can help the team to decide what to change and to establish habits for permanent improvement.
You can also establish trust in your environment by communicating changes to the plan early and sincerely. So the stakeholders will know why there were changes to the plan – is it because of wrong estimates, or because of changed priorities in the middle of the sprint. When the stakeholders will understand the impact to the project progress, they will also support the team in going ahead.
If you manage the scrum accordingly – you will get great benefits, but team members and stakeholders should work together in the implementation of the scrum steps.