A few words about devops and as an introduction to my next post: Hosted services used to be developed and deployed very similar to how products are released (see figure). There was a development phase, then an integration and test phase, then the component would be released and installed, including going through one or more staging environments. This would be done by an operations team or installed as a product by an IT organisation. With agile, we try to merge development and test, i.e. more testing is done as part of development and at the end of each iteration, while the integration and test phase is compressed (or even eliminated). Still, the product or component will be released through a release process, and then installed just as for the classic process. To pull together various products and services, we do integration testing. A big challenge is to align each team’s cycles so that integration testing is done quickly enough to offer real input into further development and bug fixing.


We are trying to compress the cycle as much as possible, increase the speed of the iterations (between each usable version of a product that can be demoed or integration tested), and we are trying to react quicker to feedback from running the product/service and from customers.  With devops, we are compressing the cycle even more. We want running code in production as soon as possible because it allows us to do small changes very often instead of many, big changes once in a while. This turns our processes and individual roles totally upside down. With this, we increase velocity of new features, reduce the risk of introducing changes as all changes are forced into smaller chunks instead of one big bang. This again allows us to learn quickly what works and what does not work. It is important to understand that this not only changes what we do on a daily basis, it fundamentally changes how we do things, and expectations to other people on our teams. This is challenging enough in one team, but even more challenging when each team is on its own, evolving processes, tasks, and expectations, and then meet other teams that have done it differently!

Read on about the changing roles of the development organisation.

Leave a Reply

Post Navigation