Agile Software Development: Why Can’t We Finish Our Sprint?
This article was written based on a discussion with Susan Miller, VP, Strategic Partnerships at BridgeView IT. Susan has held prominent senior leadership roles in several SaaS enterprise software companies. She is an Agile expert with a deep history of successfully implementing Agile software development principles and helping organizations troubleshoot issues in their Agile process. To learn more about Susan, visit her LinkedIn page.
Adopting the Agile software development methodology holds great promise for a company. It can create synergy, helping to reach unprecedented levels of production and quality. Agile development can reduce software bugs and can even increase customer satisfaction, improving the end-user experience. However, these benefits cannot be realized if sprints repeatedly go unfinished. Unfortunately, missed sprints can create the perception of lack of discipline and a failure to meet business objectives. When a team cannot complete what they committed to in an Agile sprint, it is typically the result of four root causes.
Your Stories Are Too Large
Stories play an integral role in setting a foundation for the success of the sprint. A great deal of planning and sprint grooming must go into determining what stories will look like and how big they will be. Problems arise when this story planning or grooming process produces an inaccurate picture of what needs to be developed. That often results in accepting a story into a sprint without realizing it is too large or ill-defined to realistically complete in the given time frame.
Large stories should be broken down from the beginning and that requires good team communication. In such cases, there should have been more discussion between all team members to determine and agree on the right story size. However, the Agile process is one that encourages continuous improvement and learning from one sprint to the next. Talk through this issue in real-time to address why the story is too large. Despite missing the current sprint, don’t be discouraged. Better grooming will alleviate the same issue in the next sprint.
You Are Too Optimistic
The Agile methodology is exciting for companies because it promises to revolutionize their software delivery. A side effect of this is an inflated sense of optimism that ultimately becomes a major characteristic of missed sprints. Positive thinking is a wonderful thing, but too much optimism can invite multitasking which can actually cause delays.
When a developer is overly optimistic about the sprint, they might decide to focus on two stories at the same time. After all, if they can conduct the back-end work for two stories simultaneously, it would increase efficiency. Unfortunately, this is rarely true. With switching context between the two stories and underestimating how long multitasking can take, that developer may end up with two unfinished stories in a sprint as opposed to one completed story. It’s nearly always better for the Agile team to complete a single story at a time prior to moving on. Keeping the entire team realistic and focused will help avoid this Agile speedbump.
Your Teams Separate Themselves
Agile software development relies on a cohesive team effort. Strongly defined lines between team members can create sprint problems and delays. For an example, consider a front-end developer working on five stories with similar UI components. At the same time, a back-end developer is working on the query portion of those same stories. What happens when the front-end work takes less time? It’s possible at the end of the sprint, all the front-end work might be complete, but the back-end developer has only completed four stories out of five.
This issue can be alleviated by instilling the idea of shared-team ownership. In the above example, if there were greater communication and teamwork, that front-end developer could recognize that the back-end tasks may not be completed and offer to assist. Perhaps those two teammates could work on stories at the same time, moving forward on each one together. Everyone on an agile team has their own specialty, but by thinking more as generalists in the big picture, individuals can discover opportunities to assist in areas outside of their silo. A shared ownership model will quickly result in better team velocity as well.
Your Stand Ups Aren’t Effective
The role of the scrum master is a crucial one for fostering the shared-team ownership model, and it’s specifically during daily stand ups where issues and opportunities for improvement should be uncovered. If a scrum master recognizes that a back-end developer is likely to miss a deadline on a task, then they can use time during the stand up to see who is available to assist. Effective stand ups realize issues in real-time, so rather than missing a sprint deadline and then trying to figure out how that happened, problems can be discovered and solved throughout the course of the sprint.
Stand ups are the best opportunity to bring a cohesive sense of teamwork to the Agile process. Individuals must feel comfortable describing their blockers (why they are struggling to complete a certain task), and others should be ready to help whenever possible. This provides the opportunity to shed light on issues faster and enhances the ability to collaborate. The scrum master’s role is to keep these individuals connected and engaged, which subsequently helps to avoid communication break down and encourages cross-team synergy.
Learning from Missed Sprints
Above all, remember this: a missed sprint is OK. It will happen and should be openly discussed during team retrospectives. Discover the root cause for a missed sprint, likely one of the above four points, and use it to improve the process. Take that lesson into the next story grooming and sprint planning session. A foundational principle of Agile is to fail fast. Sometimes that failure is not in the code or feature being developed, but in the process itself. It’s the way that organizations and teams respond to missed sprints that dictates overall success or failure.
For additional guidance on how to improve your agile development processes, reach out to us here.