It is fair to expect that, at any point in time, there will be one or more improvements that teams want to make to their applications, toolchain, or way of working. To cope with this, it is recommended to not keep changing everything all of the time.

Instead, try to implement changes in batches or a series of well-defined steps. Also, note there is a natural order in things. It is impossible to practice continuous deployment without having a proper continuous integration process first. Also, adopting infrastructure as code will deliver the most value when a continuous deployment process for application code is already in place. Next, automating governance and security measures works best when infrastructure and configuration code is common practice. And once all of these practices have been implemented, new things will come up on the radar—future improvements that may be necessary.

Besides this series of improvements, it is also important to realize that not every team is at the same place in this journey and not every team can move at the same pace and that development is not always this linear.

But this does not mean that it is impossible to track and plan future changes and have learnings from one team applied to other teams as well. One oversimplified approach to tracking this can be a table, as shown here.

Here we see the adoption of different DevOps practices or ideas among five teams. All teams are practicing continuous integration (CI). Some of them are practicing continuous deployment (CD), while team 3 is still working on that (Work in Progress, WIP) and the fifth team has not started yet. Finally, team 2 is already experimenting with infrastructure as code (IaC). Finally, as there is no end state, it is only a matter of time before the next practice or idea will pop up and a team will start experimenting:

If a table, similar to the one shown in the preceding, is updated, evaluated, and expanded upon frequently, this helps to foster continuous learning and improve the way software is created and delivered. Learning and improving will become the standard and this will help to improve the delivery of value to end users. It also shows that adopting DevOps is never done.

It also provides the means to see which teams are at the forefront and which teams are following along. By giving teams who are in the lead more room for experimentation and knowledge sharing with other teams, organizations can encourage their leader teams to improve even more while, at the same time, accelerating other teams as well.

And with this remark about the need to keep learning, experimenting, and pushing yourself, it is a great time to wrap this book up. Let's recap this chapter in the next section.