I may be a little obsessed with incremental delivery. But - in my defense - I do have some excuse for it. After all, Incremental delivery is at the heart of Scrum. The purpose of the Sprint is to deliver a done increment that meets the Sprint goal.
The key word there is done. Every Spint, the team delivers an increment of product that meets the team’s definition of Done. Incremental delivery means that what is delivered is usable. (Still not sure what I mean by incremental delivery? Check out my recent article The value of incremental delivery in Scrum.)
My recent article Debunking 10 Common Objections to Incremental Delivery for Software Teams introduced 10 of the most common objections to incremental delivery. In this article, I introduce - and debunk! - 10 more objections to (you guessed it!) incremental delivery.
1. Objection: But it will take longer to see tangible results!
Debunked: In fact - the opposite is true! The reality is that incremental delivery enables teams to deliver value sooner because we don't have to wait until all features are ready to start using some features. As a result, incremental delivery offers quicker feedback loops and the opportunity to adjust course early on.
2. Objection: Our stakeholders won't understand or support incremental delivery.
Debunked: Incremental delivery is easy to understand. But just like any change to delivery approach, it needs to be communicated to your customers. In my experience, stakeholders appreciate incremental delivery because it gives them the opportunity to have greater visibility into the progress of the product. With each increment, stakeholders can witness tangible progress, fostering confidence and trust in the process. Need help explaining incremental delivery to your stakeholders? Check out our recent article What is Iterative, Incremental Delivery? The Hunt for the Perfect Example for a examples to share with your stakeholders.
3. Objection: It's too risky to release incomplete features.
Debunked: First off, just because we use an incremental approach to value delivery doesn't mean that it has to be released to the customer every time an increment meets the Definition of Done. The Product Owner decides when to release. That being said, why wouldn't you release something that works and adds value? Because even if it isn't everything all in one go - it's something, and it works and is usable. That is the heart of incremental delivery. By delivering - and possibly releasing - work in smaller increments, teams can gather feedback, refine features, and adapt to changing requirements, ultimately reducing the risk of delivering a product that doesn't meet expectations.
4. Objection: Our team isn't equipped to handle incremental delivery.
Debunked: Adopting incremental delivery may require a shift in mindset and practices, but it's a learnable skill for teams. By providing training, guidance, and support, organizations can empower their teams to embrace incremental delivery practices and reap the benefits of increased agility, collaboration, and customer satisfaction.
5. Objection: It's too complex to implement incremental delivery in our environment.
Debunked: Incremental delivery can be tailored to fit various environments, whether they're highly regulated industries, legacy systems, or complex projects. By breaking down work into manageable increments and leveraging techniques such as continuous integration and automated testing, teams can navigate complexities while still realizing the benefits of incremental delivery.
6. Objection: We don't have the necessary tools or infrastructure for incremental delivery.
Debunked: Incremental delivery does expose your Dev Ops problems, which is a good thing, because it gives you a chance to solve them. Things that your team has been suffering with for years become obvious when the organization decides to adopt incremental delivery. And that's not a bad thing. Leadership engagement may be required to help teams find the right tools to enable them to deliver value incrementally. It's been said before that Dev Ops and Agile go hand in hand.
7. Objection: Our development process is too rigid for incremental delivery.
Debunked: I've worked with teams who developed Incrementally in Cobal! If it can be done there, it can be done anywhere. Teams have used incremental delivery for fighter jets, microscopes, and refrigerators.
8. Objection: It will disrupt our existing workflow.
Debunked: While transitioning to incremental delivery may require adjustments to existing workflows, the benefits far outweigh the temporary disruptions. By fostering a culture of continuous improvement and learning, teams can adapt their workflows to accommodate incremental delivery practices, leading to greater efficiency, quality, and customer satisfaction in the long run.
9. Objection: We don't have the bandwidth to adopt incremental delivery.
Debunked: While adopting incremental delivery may require an initial investment of time and resources, the long-term benefits justify the effort. By starting small, focusing on incremental improvements, and leveraging existing resources, teams can gradually transition to incremental delivery without overwhelming their capacity. Over time, the increased efficiency, flexibility, and customer satisfaction enabled by incremental delivery will more than offset the initial investment.
10. Objection: We have to do the work anyway!
Debunked: That’s not the point at all! Incremental delivery is a value in and of itself. Incremental delivery has the following benefits.
Feedback Loop: Incremental delivery allows for early feedback from stakeholders or end-users. By delivering smaller increments of functionality, teams can gather feedback sooner and incorporate it into subsequent iterations. This feedback loop can lead to a more refined and ultimately more successful end product.
Risk Management: Breaking the work into smaller increments reduces the overall risk associated with the project. Instead of investing time and resources into a single large deliverable, teams can mitigate risks by delivering smaller, manageable chunks of work. If something goes wrong, the impact is limited to that specific increment rather than the entire project.
Flexibility and Adaptability: Incremental delivery enables teams to adapt to changing requirements or priorities more easily. By delivering value incrementally, teams can adjust their approach based on feedback, market changes, or new insights without being locked into a rigid plan.
Early Value Realization: With incremental delivery, stakeholders can start realizing value from the project sooner. Even if the full scope of the project is not yet complete, each increment delivers tangible benefits that contribute to the overall goals of the project.
Motivation and Morale: Delivering incremental results can boost team morale and motivation. Seeing progress and tangible outcomes regularly can keep team members engaged and motivated to continue working towards the project's goals.
Conclusion
While the road to embracing incremental delivery may face its share of objections and challenges, the benefits far outweigh the initial hesitations. Incremental delivery offers not only tangible advantages like early feedback, risk mitigation, and adaptability but also intangible yet invaluable benefits such as increased team morale and stakeholder satisfaction.
By addressing and debunking these objections, we shed light on the transformative potential of incremental delivery for software teams. It's not just about completing the work—it's about delivering value consistently, building trust with stakeholders, and fostering a culture of continuous improvement.
Want to engage with others about Scrum ideas? We hope to see you at Scrum Day in Madison, Wisconsin, on October 23, 2024!