06/30/2015 | Delivery Leadership | Thought Leadership
In my years of experience as a scrum master, I’ve encountered numerous situations where scrum has resulted in less-than-ideal outcomes—not because the agile framework is flawed, but because the company didn’t understand, or disregarded, how scrum is supposed to work.
For example, I was once a scrum master for an e-commerce website production team where a new feature was considered so critical that it was prioritized over everything else in the backlog. Minimal time was taken for the development of user stories and my team had to make assumptions because the business stakeholders were unavailable. When we were nearing completion, the stakeholders came out of hiding and identified more business rules that required not only additional work, but some re-work of things that were already completed, including global changes to the company’s customer-facing website. The impact to the business had not been appropriately analyzed, and when the new feature was rolled out, the value delivered was negative, causing refunds and ultimately financial loss.
Sadly, scenarios like these are not uncommon. The scrum framework is ideal for situations where priorities change often, but many companies struggle with finding the right rhythm to implement and manage those changes. Scrum fails when companies don’t build a shared consensus on which principles should form their definition of agile delivery, or fail to educate everyone involved on how the agile processes should work. One very common example involves the most basic of agile artifacts: the sprint plan. I can’t tell you how many times I’ve completed a long day of planning only to run into an executive who wants to add something to the sprint. This is where understanding the methodology and sticking to it are important, especially because changing the sprint plan will impact your team’s morale, as well as its productivity. As much as we love our stakeholders, they should not swoop in at the last minute and bypass the product owner.
For those unfamiliar with scrum terms, the product backlog identifies the longer term priorities for a project or product team. The sprint backlog determines current sprint priorities and sets a shared goal for delivery team execution. Product backlog priorities can (and should) change all the time, but sprint backlog priorities should be locked down for the duration of the sprint. At the beginning of each sprint the team participates in a planning meeting where the highest priority stories are pulled from the product backlog and reviewed. The final output of a planning meeting is a prioritized sprint backlog that represents the plan for the sprint. Once the sprint plan is determined, it should be protected. There are always exceptions, but to ensure scrum works, the scrum master must protect the plan as much as possible.
So, how can you make sure your team moves as fast as possible but can still address changing priorities? Below are a few lessons I’ve learned:
1. Determine the Appropriate Sprint Length
First, and most importantly, determine a sprint length that is appropriate for your organization. I would recommend that companies new to scrum should avoid one week and four week sprints. One week sprints move too fast for new teams and are too heavily burdened with meetings. Four week sprint teams have a hard time staying with the sprint plan, especially new teams who don’t fully understand the impact of changing priorities mid-sprint. I’m not saying that four week sprints never work, but I find that a four week sprint length makes it difficult to keep the team on track. Two week cycles have traditionally been the preferred length for agile enthusiasts. When I’ve worked on project teams where code will not be moved to production at the end of the sprint, a two week sprint duration works well; however, my production teams seem to prefer three week sprints because they can develop new features in the first two weeks and use the last week to do production preparation work. Whatever length is chosen, it needs to work with your product environment. For example, if you’re currently running three week sprints but your scrum master is constantly having to battle to protect the sprint plan, then maybe a two week plan would be more appropriate.
2. Educate Your Stakeholders
Once the organization finds the appropriate sprint length, educating stakeholders is essential. How can we expect stakeholders to work with implementing scrum when we don’t help them understand how it should work? Actually communicating the sprint calendar is a good first step. Stakeholders also need to understand the product owner’s role and how they will assist them in assigning their requests the appropriate priority in the product backlog. This can be quite beneficial as many stakeholders who desire to add to the product backlog don’t realize that other higher priority features may not have been completed yet. Working with the product owner provides an impact analysis for the overall product. Sometimes it’s as easy as saying, “Is this more important than x?” Just that simple question has saved me many times as a scrum master. Sometimes stakeholders just want to get the request on the backlog and don’t mean for everyone to stop work on current priorities. If the request is determined to be the highest priority item at the time, then analysis of the desired behavior can begin. By the time the next sprint planning meeting happens the team will have a much better idea what the request is about and will be more likely to complete the feature with the value envisioned by the requestor.
3. Build Trust
Lastly, and perhaps most importantly, the team must build trust among the stakeholders. This has had a huge impact on my scrum teams and has stopped most emergency requests. Teams build trust by setting realistic sprint goals for themselves and then accomplishing those goals on a consistent basis. If the stakeholders know what is planned will get done, they have much more confidence that their request will be completed in a timely manner. This is not an easy task but can be accomplished by improving sprint planning.
The most effective way to improve sprint planning, and one that I find is often ignored, is utilizing the sprint retrospective. This is where the entire team reviews their performance during the sprint and discusses what went well and should continue and what areas need improvement. The team then decides what one or two things will make the most impact on the next sprint and brainstorm for ways to improve. The retrospective works well because the team decides what to change and begins to build a culture of continuous improvement. As far as agile benefits go, this is one of the most impactful to organizations.
Another way to build trust is to communicate changes to the plan early and honestly. Let stakeholders know why there was an adjustment to the plan. Was it due to a bad estimate? A delayed approval? Changing priorities mid-sprint? Once stakeholders start seeing the impact they have on the progress, they can assist the team in moving faster too.
The Result
When properly implemented, scrum can realize amazing benefits, but scrum teams and stakeholders have to work together to understand and implement the scrum procedures.
Here’s another true story: When I was a scrum master for another website project team, we had to halt development based on a third party delay. Because we were using scrum, this was no problem—we closed out the last sprint, complete with a proper demo, and the next day held our sprint planning meeting. We started a completely different project that was estimated to take approximately three months, matching the estimated delay for our primary project. We worked with a new product owner and successfully implemented the new feature as planned. The revenue generated from the feature was estimated to pay back the development costs in less than a year, and when completed, the team was able to return to the primary project.
That’s how scrum is supposed to work.
