Incremental Delivery — An Encouragement
I have had the privilege to work with a handful of diverse development teams in companies of different sizes, with many different perspectives and experiences in the delivery of software value. Throughout my experience, I have become familiar with iterative delivery in modern software development. Although the term is well known, and the concept in general is accepted, there are many gaps between the theory as I know it, and reality I have experienced. There remains a wide range of understanding and assumptions when it comes to the iterative delivery perspective.
The Basics
Iterative delivery refers to the perspective and processes needed to deliver increments of value to the stakeholders in small, frequent planned efforts. To benefit the stakeholders, managers, and developers alike, a change in perspective in the development process from traditional project development is necessary.
Stakeholders, who are paying for the delivered value, want to see progress and return on their investment as soon as possible. Instead of delivering the end solution after 6 months, providing, say 10 units of value, an incremental delivery approach provides 1 unit of value in month 1, then 2, 3, 5, 8, and 10 in subsequent months. Added value is delivered throughout the process. Even if the overall project timeline is extended somewhat, the process delivers more value over time back to that Stakeholder.
For management, who monitor the project and report on the team’s progress, the benefit of incremental delivery is improved visibility into the entire development lifecycle, providing added predictability and forecasting for the project as a whole. When the team runs through smaller backlog stories, and more frequent deployments, the milestones and stepping stones are closer together, thus leading to fewer unknowns in the meantime. Fewer concerns about the unknown means less stress and more confidence in the team’s delivery.
The benefits to the developers exist as well. The most impactful benefit is the psychological and emotional impact that iterative delivery has on the developer. By designing smaller, incremental deliverables, each milestone can be planned, worked, achieved, celebrated, and reflected on in rapid succession. This fast turnaround provides confidence and satisfaction in the work being accomplished, because there are more frequent opportunities for reflection, redirection, and collaboration. I have seen the frustration and demoralization of a developer struggling under a massive project, and I have also seen the frequent affirmation of progress and achieved learning that accompanies incremental delivery. The difference is well worth it for the success of the individual, as well as the team.
Impact to workflow
This added benefit comes at what’s the cost? A quote from Jez Humble in Continuous Delivery, “if it hurts, do it more often”. In this case, the dreaded paperwork and logistics of deployment so often avoided within a project is instead embraced. By forcing the team to repeatedly go through the process of delivery, they will begin to find shortcuts and improvements to reduce their own pain and frustration, thus improving it for everyone. Smaller delivery content may seem less impressive to a stakeholder at any specific point, but this allows for deeper dive into the requirements and solution designs to be implemented. With this increase in communication, there is less heads- down coding and more collaboration.
Stakeholders have more engagement with the development team in this model, as each feedback loop occurs more often. There is added direction to the development because they can see the incremental results of their requirements playing out, and they have more opportunities to steer the ship along the way. In exchange for this added accuracy, the end result may take a little longer to achieve. The trade-off provides both short term results as well as long term product satisfaction.
For managers, the impact to their workflow is mostly around communication. With the cycle frequency increase, visibility to the development teams’ progress and current state is more frequent, and delivery to the stakeholder and communication coordination is more fluid and ongoing. One additional impact to managers is the frequent team-level recognitions and retros, allowing for relationships to build more quickly. Managers must remain engaged to a higher degree for this communication to be successful.
Developers also need to change their approach, as this perspective has the most impact on their workflow, both operationally and strategically. For starters, the solution as a whole needs to be thought of through the eyes of many separate, smaller deliverables. The improved value to the developer by incremental delivery is seen throughout their entire experience, not just the completion of the project. As an example, designing the solution with smaller, decoupled components allows for more flexibility of delivery, thus supporting increments and changes throughout the solution lifecycle. One challenge that comes up with this approach is the need for architecture and design fluidity. As the solution evolves over time, some design aspects will go in and out of the solution. Similarly, even component architecture may change with the iterations. Developing with the expectation of temporary modules can be a shift of perspective for some, but is necessary in the overall incremental plan. Rework can sometimes feel like a bummer, but in this incremental delivery model, there is an expectation of some rework by design. The extra effort is well worth the added value for everyone involved.
How to Rethink
Despite being in management now, I am still a developer at heart. Sometimes it still feels like the solution isn’t done until it works end to end, and I bite off more than I can handle from the start. On the other hand, sometimes it can be satisfying to prove out a single technical component, but it’s hard to explain the connection between that piece and the solution as a whole. This has caused some friction for me personally in projects over the years. For incremental delivery however, the goal is not from the developer’s perspective, but the stakeholders’. As such, they see value when they can achieve some business task or at least experience the business deliverable taking shape, in some tangible way. The below image shows the concept of delivering a ‘vertical slice’ of the solution, which provides that value to the stakeholder.
Some examples of this approach include:
- Create short term finish lines that represent work done towards the final solution, such as a UI layout, or buttons to additional dummy screens.
- Show something that points towards the solution, such as dummy data, to help prepare the audience for what is expected
- Demonstrate technology that will be a part of the final solution, providing white paper explanations as needed.
- Walk through a workflow that will be a part of the final solution, such as delivering only the happy path first.
- Provide documents connecting the overall vision and goals to both temporary modules as well as persistent components.
Conclusion
Incremental delivery requires thinking differently, stepping away from just the goal, and considering the experience along the way. In the end, the stakeholder is more content, management is more informed, and the developer is more satisfied. Try this perspective shift in your own life, not just in software development, and you may find this same outcome to be true for you as well.
For more information on this concept, take a look at these great resources:
