Summary

In this chapter, we looked at two delivery styles, delivery as a software product and delivery as a software project.

We learned that delivery as a software project was hard to get right for multiple reasons. And giving our team only one shot at delivery gave them little or no chance of fine-tuning their approach. In a novel situation, with varying degrees of uncertainty, this could lead to a fair amount of stress.

There is a better chance of succeeding if we reduce the variability. This includes knowledge of the domain, the technology, and of each of our team members' capabilities. So, it is desirable to keep our project teams together as they move from project to project.

What we learned was that when a long-lived team works on a product, they have the opportunity to deliver incrementally. If we deliver in smaller chunks, we're more likely to meet expectations successfully. Plus, teams that work on products are long-lived and have multiple opportunities to fine-tune their delivery approach.

Those who build software, understand well the complex nature of the work we do and the degree of variability that complexity introduces. Embrace that, and we'll learn to love the new control we can gain from focusing on incremental value delivery in an adaptive system.

In the next chapter, will look at the different Agile methods for software delivery and delve into the mechanics of three of them in particular. See you there.