When I first started practicing Scrum, I thought that delivering a done, usable increment each Sprint was the least important part of the framework (spoiler alert: delivering a done, usable increment at least once per Sprint is critically important for reducing risk, enabling faster delivery of business value, reducing the accumulation of technical debt, and facilitating empiricism.) At the time, I was the Scrum Master for a team that was building an online application, and the Product Owner did not intend to release the new application to production until it was complete. What did it matter how we sliced up the work when a certain amount of work had to get done either way?
How wrong I was.
What is Incremental delivery?
An increment is what the Developers deliver each Sprint. So, think of the initiative I mentioned above. Imagine you are building a web application which saves information to a central data store. From a technical standpoint, a web form that saves to a data storage location has three main components:
- User interface: the form that the insurance buyers interact with online
- Data integration layer, or save process: the part of the form that interacts with the database
- Database: where the data is stored
Using traditional development methods, such as waterfall, a development team might first build the database followed by the data integration layer and then the user interface for the entire form. With this approach, nothing is usable until everything is complete.
Using incremental delivery, rather than the above process, Developers build all three things for the first few fields and then the next few fields. How many fields do you build at once? As many as you can get done in one Sprint (iteration) of one month or less. Incremental delivery replaces a detailed plan with a vision, which allows the team to learn more information through the delivery of an increment each Sprint. We can then incorporate these learnings into the product. Using this approach, parts of the overall end deliverable are usable even before the end product is complete.
It’s the same amount of work either way - so why does this matter?
The Scrum Team and its customers benefit from the increased visibility offered by an incremental approach to product delivery, which supports empiricism. Incremental delivery makes the team’s progress transparent and provides opportunities for inspection of what it delivered, which in turn enables it to adapt based on user feedback. As a result, teams are not locked into a plan and can change direction based on new information.
The customers benefit from this way of working because they might be able to use smaller pieces of the system earlier. They don’t have to wait until EVERYTHING is done before using at least a part of the working system. Thus, iterative delivery enables value delivery sooner.
Using Incremental delivery, Developers can thoroughly test the integrated increment at least once per Sprint. For example, suppose the web form cannot connect to the database for some reason (e.g., due to a lack of security permissions or the database is not compatible with the software that the team wants to use). In that case, the Developers know right away, which can prevent rework later. This is just one of the ways that iterative delivery can reduce risk. Another example is that by testing a fully integrated increment at least every Sprint, the Scrum team can identify defects earlier, which usually means that they are easier to fix. Incremental delivery reduces the accumulation of technical debt.
The charts below illustrate how incremental delivery compared to waterfall impacts each of the factors mentioned above.
Visibility
Because the Scrum Team provides a completely done, usable Increment each Sprint, stakeholders have much more visibility into what the Scrum Team is working on and the direction that they are going in. It’s far more transparent. Rather than stakeholders waiting until everything is done to view the product, they can view its progress as the team develops it.
Ability to Change
Because the Scrum Team delivers value incrementally, there is no “un-done” work at the end of each Sprint. Unlike waterfall, this means that if the Scrum Team needs to change direction, they can do so quickly.
Business Value
The business can use each Increment as the team delivers it, rather than waiting for everything to be done before using the product.
Risk
Every Sprint, the team can change direction if necessary because they commit to only one Sprints’ worth of work at any given time. The Sprint’s timebox of one month or less means the financial commitment of an organization is limited to one month or less. By comparison, many waterfall projects have durations of many months or years.
The Result
Returning to our online application example, at first, the Product Owner planned to release the online application only after it was fully complete. However, during the first refinement meeting, the Developers suggested to the Product Owner that they could make the online application process available online immediately by creating a PDF form, which could be printed and mailed in. Doing this would immediately improve the existing application process while the Developers continued building the online application process. The Product Owner agreed, and the Developers added the PDF form to the website.
In the next Product Backlog refinement, the Developers suggested to the Product Owner that applicants could return the form via email rather than postal mail. The Product Owner agreed, and a new email box was created. The Developers modified the PDF form to include alternate instructions for returning the form electronically.
When applicants started using the PDF form on the website, they began sending in questions about using the form. The team discussed these questions during the refinement meeting with the Scrum Team and found they revealed parts of the application process applicants found confusing. Using this information, the Developers on the Scrum Team worked together with the Product Owner to make the application process easier.
When internal business stakeholders learned about the web application, they requested access to it for data entry purposes. It turned out that even though the entire application was not yet complete, what had been done was usable and allowed for a much easier data entry process. By making the application available to internal users for data entry purposes, the business benefited and provided the Scrum Team with feedback on how user-friendly the application was. Based on this feedback, the Scrum Team could adapt the web form further to make it even easier to use.
When the team finally released the online application form, it incorporated design changes identified from customers using the PDF form and feedback from internal users.
And the use of the empirical process of transparency, inspection and adaption did not stop there. The Scrum Team had learned the value of customer feedback. After the form was released in production, the Developers met with the Product Owner to regularly discuss customer feedback, and they continued to modify it for improved user experience.
Frequently asked questions
- Isn’t the Incremental approach wasteful? Developers in the online application example are touching the database multiple different times?
- Answer: Perhaps it would be wasteful if we lived in a perfect world where you know everything about a product from the start, which is rare in complex work. Agile works best in environments where more is unknown than known. In that context, an Incremental approach reduces waste. There are many reasons for this, but most commonly, any integration or testing-related issues the team identifies and resolves early reduces rework in the long run and eliminates the accumulation of technical debt.
- Do we have to release to production after every Sprint?
- Answer: No, the Product Owner decides when to release to production. The Developers are accountable for delivering a done, usable increment each Sprint.
Conclusion
Incremental delivery profoundly impacts a team’s ability to deliver value to the business and the customer. The approach enables value delivery sooner because users can use parts of the product before the entire application is complete. Incremental delivery reduces risk by helping identify any problems sooner, and it also reduces the accumulation of technical debt - or errors - by fostering transparency. Finally, Incremental delivery offers increased visibility, which means that teams can benefit from empiricism. The product’s development is transparent, enabling the team to inspect it and adapt to any findings. That is why it is essential to deliver a done, usable increment at least once per Sprint.
I’d like to know what you think. Please add your thoughts to the comments section below.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.