I write a lot about incremental delivery because it is so central to the success of Agile teams. And - like the Scrum framework itself - it is easy to understand but can be hard to master.
Incremental delivery is the idea that Agile teams should deliver value in smaller pieces of usable product. It's the idea that teams should deliver value frequently so that the team can increase transparency, inspect honestly, and adapt based on what is learned. This approach increases predictability and enables Agile teams to deliver value sooner and reduce risk.
Although people generally agree with the concept of incremental delivery, it's easy to revert to old habits. Even with the best intentions, Scrum teams might embrace the idea of incremental delivery, but still end up working on extensive requirements documents.
To help you identify when your team is deviating from the practice of incremental delivery, here are 4 red flags to watch for.
1. "We Need to Create a Requirements Document."
Red Flag: The team insists on creating a comprehensive requirements document before starting development.
Coaching Opportunity: When a team creates an exhaustive a requirements document, they are locking themselves into an approach at a time when they know the least about customer needs. This approach can create waste because we don't yet know which changes will have a positive impact on customer outcomes.
Instead, start with a high-level understanding and a dose of humility. Plan to deliver something usable each Sprint. Gather feedback about what has been delivered so that you can learn which changes had a positive impact on customer outcomes - and which did not. Use this information to influence what the Scrum team works on next.
2. Planning for One Large Delivery
Red Flag: The team focuses on planning for a single large delivery rather than a series of small improvements to the product.
Coaching Opportunity: As Yoda would put it, "You must unlearn what you have learned." So many of us are used to striving for perfection. For many, it seems wrong to release something that isn't everything that the customer needs.
But the marketplace has shown us that delivering something is better than delivering nothing. For example:
Instagram: Started as a simple photo-sharing app called Burbn, then pivoted to focus solely on photo sharing, leading to massive success.
Minecraft: Initially released in an alpha version, which allowed the developers to continually improve the game based on player input.
Hades: Released in early access, which helped the developers refine the game based on player feedback, leading to widespread acclaim upon full release.
Spotify: Regularly delivers updates and new features to its users, improving the app based on user feedback.
Amazon: Frequently releases new features and updates, continuously enhancing the user experience.
Exploding Kittens: A card game that started on Kickstarter, delivering early versions to backers and using their input to finalize the product.
Rather than one delivery, the Product Owner should focus on what's the most valuable thing to do next. The Product Owner can collaborate together with stakeholders and developers to identify something that can be done every Sprint to add value to the product. The Product Owner then determines when to release to the customer so that customer outcomes can be measured frequently and used to influence what the team will work on next.
3. Exhaustive Up Front Estimation
Red Flag: The team feels the need to provide a full estimate of the project before development begins.
Coaching Opportunity: Agile teams actually do increase predictability because by accepting that we don't know everything, we deliver value in smaller pieces. When value is delivered in smaller pieces, the team learns over time how much work can be completed in a given amount of time. This information can be used to improve the team's ability to predict future delivery.
4. Complete System Before Testing
Red Flag: The team believes they need to build the entire system before any testing can begin.
Coaching Opportunity: Testing early and often catches defects sooner, improves quality, and reduces rework. When defects are caught sooner, they're easier to fix. That's because the code is fresh in the developer's mind, and new work has not been added on top of the defective code which further confuses efforts to find and resolve the defect.
Conclusion
Shifting to an incremental approach from a traditional, waterfall approach is easy to understand, but hard to master. It can take years to unpack all of the habits that were necessary for traditional approaches, but which hold back teams from fully embracing incremental delivery. Remember that changing habits and ways of thoughts happen slowly, and sometimes that's ok. As you begin to work incrementally look for these red flags and take small steps every Sprint to improve the way you work together. Because improvement itself is incremental.
Ready to embrace continuous learning? Join Rebel Scrum at Scrum Day 2024 in beautiful Madison, Wisconsin. This year's Scrum Day conference theme is "Deliver Products with Value" because it doesn’t matter how many tickets the team closes if they aren’t delivering the right thing.