Scrum is the most popular Agile framework. According to the latest State of Agile survey from Digital.ai, 90% of teams who are using an Agile framework are using Scrum. I like to think that this is because Scrum is a goldilocks framework… with just enough - but not too much - structure.
Scrum is a framework, which means it’s not a rulebook. It is deliberately incomplete. For example, Scrum includes five events: the Sprint, Sprint Planning, Daily Scrum, Sprint Review and the Sprint Retrospective. The Scrum guide clearly describes the purpose of each of these events, but the Scrum guide doesn’t include a required agenda for any of these events. This is a deliberate omission, because Scrum relies upon the intelligence of those using it to figure out how best to apply Scrum in their unique environment. That is why Scrum can be used in so many different contexts: because of its flexibility and the fact that Scrum provides just enough - but not too much - structure to enable teams to work together to deliver value.
Like any widely adopted framework, Scrum has been surrounded by its fair share of misconceptions. Whenever I hear someone say that Scrum teams must use user stories to document items in their Product Backlog or that Scrum teams must use points to size their work, I say “no!”. Let the team decide what works best for them. That is the power of Scrum. It’s not that user stories are bad - in fact, I find them very helpful - but are they right for this team? That’s a question that only the team can answer.
This is why Scrum myths are such a problem. The Scrum framework is deliberately incomplete, so when teams start to fall for Scrum myths that say you must do this or you must do that, frequently these myths are actually holding the team back from embracing the true flexibility of Scrum. Teams should find out what works best for them, not works best for other people.
Myth 1: Program Increment Planning is part of the Scrum framework
Program Increment (PI) Planning is not a part of the Scrum framework itself, but rather a key component of the Scaled Agile Framework (SAFe). SAFe is a separate framework designed for scaling Agile practices to larger organizations. PI Planning serves as the cornerstone of the Agile Release Train within SAFe, establishing a synchronized cadence for multiple teams to work together towards a common goal. It lays out the roadmap for releases, ensuring that they progress incrementally in a coordinated manner. It's important to note that while SAFe is a popular method for scaling Agile, it is just one of many approaches available. Scrum, on the other hand, is primarily designed for smaller teams and does not include specific provisions for large-scale planning and coordination. Other popular frameworks for scaling Scrum include Nexus, which is the simplest, lightweight framework for scaling Scrum.
Myth 2: You Need a Product Backlog Before You Can Get Started
One popular practice in Scrum that can potentially be harmful for the Scrum team is the excessive use of detailed upfront planning. While planning is a crucial aspect of Agile and Scrum, too much emphasis on detailed upfront planning can lead to rigid plans that may not be adaptable to changing circumstances. This can hinder the team's ability to respond effectively to new information, feedback, or evolving priorities. It's important to strike a balance between having a general plan and remaining flexible enough to adjust based on real-time feedback and emerging requirements. Overly detailed planning can also lead to a sense of false certainty, which may cause frustration and disappointment when plans inevitably need to be adjusted. It's important for Scrum teams to embrace the Agile principle of "responding to change over following a plan" and focus on delivering incremental value in a responsive and adaptive manner.
The Product Backlog does not need to be fully fleshed out before a team can start Sprinting. In reality, the Product Backlog is a dynamic document that evolves over time. It serves as an ordered list of features, enhancements, bug fixes and anything else that might add value to the product. The Product Backlog will never be finished until the Product is sunsetted, because the needs of customers changes over time, as do organizational priorities and technology. Starting with an initial, high-level backlog and refining it as the team moves forwards is not only acceptable but it really is the only way to fully embrace agility. This allows for flexibility and responsiveness to changing requirements and stakeholder feedback.
Myth 3: The Scrum Master is ONLY accountable for ensuring the events take place
It's crucial to dispel the misconception that the role of a Scrum Master is solely centered around facilitating events. While overseeing and ensuring the effectiveness of Scrum events is a part of their responsibilities, the Scrum Master accountability encompasses so much more. A Scrum Master serves as an educator, imparting knowledge about the Scrum framework and elucidating the significance of each event. They are instrumental in fostering a positive and productive environment within the team, ensuring that meetings are timeboxed and constructive. Additionally, they play a pivotal role in promoting collaboration among team members, offering coaching and mentorship to enhance their understanding and application of Scrum principles. Beyond this, the Scrum Master holds the accountability for driving the adoption of Scrum across the organization, striving for continuous improvement in value delivery. Their influence extends far beyond mere event facilitation, as they work towards elevating the overall proficiency and effectiveness of the Scrum team and the organization as a whole. For more on the Scrum Master accountability in Scrum, see our recent article “10 Characteristics of a Great Scrum Master”.
Myth 4: Agile Teams Can't Hit a Deadline
It's a common misconception that Agile teams don't work with deadlines. In fact, Scrum can make it more likely that a team will actually reach a hard deadline because the team can adapt as more is learned. Moreover, Agile frameworks in general emphasize the importance of setting achievable, realistic goals and provide teams the flexibility to find the best way to achieve those goals.
Scrum in particular helps teams to deliver value in smaller increments each Sprint. By breaking down projects into manageable chunks and adjusting priorities based on feedback, Agile teams can meet deadlines by enhancing visibility, maintaining a higher ability to change direction, delivering value sooner and reducing risk.
Myth 5: Agile Is Just for Software
The graph above compares the 2020 and 2021 “State of Agile” reports. This graph shows that the adoption of Agile has seen significant growth in many areas of the business including operations, Marketing and Human Resources.
While Agile frameworks have their roots in software development, Agile principles can be applied effectively to a wide range of complex problems. Agile frameworks tend to enhance collaboration, adaptability, and continuous improvement, making it suitable for any endeavor that requires flexibility in responding to evolving requirements and customer needs. From marketing campaigns to product development and beyond, Agile principles can enhance productivity and deliver value across various domains.
Conclusion
Dispelling these common Scrum myths is crucial for gaining a deeper understanding of Agile frameworks and how they can be applied effectively in various contexts. By recognizing the true nature of Scrum, teams can unlock the full potential of Agile practices to deliver high-quality products while maintaining adaptability and responsiveness in an ever-changing business landscape. Remember, adopting Agile is not about following a rigid set of rules, but about embracing a mindset of collaboration, continuous improvement, and customer-centricity.
Comments