In Figure 1, a typical approach to modern software development is shown. The actual solution development can be segregated into three different iterations that are intertwined. During Discovery, the need of the customer is identified. These needs are then implemented in the Development iteration, after which during Delivery the value of the product is actually delivered to the client. All three phases consist of short iterations to keep the feedback cycles as short as possible to ensure the value delivered still matches the actual need of the client. Dependent on the ambition level, this flow of activities can take a couple of weeks, but in certain occasions only a couple of days.
During Discovery, the focus will be on the identification of the actual need. Then, the short- and longer-term roadmap is identified by selecting and prioritizing the right ideas and client wishes. In the early stages of product development, aspects like ideation and experimentation play a major role, empathizing with the (end) customer and collaborating and testing new ideas and insights. Design Thinking and rapid prototyping techniques are most of the time valuable sources for inspiration. Sometimes, as part of the architectural runway, small technical experiments will be executed as well to research technical feasibility of the possible solutions identified.
When the product is already in a more mature state, the focus of this stage will be more about identifying smaller, incremental improvements that can be taken from the actual use of the product. Collecting data about the actual use of features (see Delivery) can be a very valuable source for this. For example when a user of a web shop doesn't finish its order, the most common bottleneck in the process can be found, analyzed and improved.
During Development, the focus will be on the actual development and testing of the proposed functionalities. As organizations strive to deliver more frequent, this requires a high level of automation of the development pipeline to be able to achieve both speed as well as ensuring quality. Therefore, development teams are constantly working on optimizing their development factories to enable automation. To ensure speedy development, making use of Continuous Integration practices are key. Build automation ensures that source code created by multiple developers is integrated correctly. Test automation in these pipelines is the only solution that can provide the risk mitigations that are needed to deliver new functionality at speed. To ensure that security standards are met, many case aspects like security testing are also highly automated.
The purpose of Delivery is to actually deliver the result to the end user. This result matches closely to the wishes and requirements of the end user, with enough flexibility to rapidly improve it further. In doing so, deployments need to be automated as well to increase their speed and quality. A straightforward and repeatable deployment process is important for what is called Continuous Delivery. This means that infrastructure changes are considered part of the delivery process (Infrastructure as Code), where the same versioning that a DevOps team uses for source code is used. This consistency is not only beneficial for speed, but also provides more reliable deployments and thereby also improving compliance, since security, audit, and compliance processes are considered as an integral part of the delivery cycle. After software has been deployed, measurements are executed in the live environment to proactively monitor the application performance as well as to gather information about the actual usage by the end users. All this information can be used to detect issues as early as possible, or can be fed back to the Product Owners to better adapt the product to the needs of the users.
By integrating significant parts of the development process and by creating small cross-functional teams, most organizations today are better capable of delivering business value much faster. Also, as a result of the smaller deliveries, the risk of failure is reduced as the number of different components affected is generally much smaller. Because there is also a lot of focus on rollback scenarios in case of any mistakes or errors during development, the smaller deployment size also has a positive effect on the time for recovery. Similarly, small deliveries result in faster feedback from end users. The combination of these results in lower risk of releases and promotes courage within teams to experiment more often. This in turn empowers the Discovery phase which creates a positive continuous feedback loop.