From both sides of the world, we see many rules. Rules can provide demarcation, structure, and safety, but conversely, they can be limiting and restrictive. Rules can therefore be seen as positive as well as negative. We have heard first-hand and read in various places that combining rules with DevOps is not a good thing. “There are no rules for DevOps; it’s iterative.” However, there are rules in DevOps, and they should not limit you but rather give you space.
The iterative element of DevOps lends its origin to Agile and can be found in the Agile Manifesto for software development, among other places. In the Agile Manifesto, there are statements claiming people value ‘things on the left’ more than ‘things on the right’. While the items on the left of each manifesto statement, namely individuals and interactions, working software, customer collaboration, and responding to change, are valued more, the manifesto states there is still value in the items on the right.
The items on the right could be interpreted as relating to rules like processes, contracts, and plans. With both Agile and DevOps, these things certainly do have value. The iterative approach is something that can arise through rules like the demarcation of scope and time. Rules allow one to enable value delivery to customers in an iterative way. If one attempts this without rules, there are no boundaries, and one will be less able to deliver value.
The saying, “Good fences make good neighbors”, could be applied in this context. Knowing the size and location of operational boundaries improves not only relationships but also efficiency. At the heart of DevOps are improved relationships between business, IT, and end-users and some of the best ‘fences’ are those that have been created together by neighbors.
A good basis for rules within DevOps can be found in the DASA DevOps principles. These principles can be essential for DevOps to work, providing direction on what underlies DevOps. From these principles, rules can be created that fit within your organization. However, they will not provide a list you can simply follow to really work DevOps. In a working DevOps environment, the team, including the client, create the ‘fences’ that you agree to work within. There is no step-by-step plan on how to implement DevOps that will fit every organization. There are many variables, like what suits the organization in question and what phase of a DevOps migration they are currently in. Consultants can play a significant role in this. By combining knowledge of and experience in DevOps in combination with consultancy experience, it is possible to apply these principles in a way that suits the organization. It gives substance to the principles by drawing up rules that should facilitate delivering value to the customers.
However, the iterative in DevOps ensures you deal with rules differently. The power of iterative work is that it enables you to respond to changes. This could also mean changes to your rules. It is vital to fully examine whether the rules provide the right demarcation and enable you to deliver value. Therefore, it can help to refer to the DASA DevOps principles to assist in reflecting on the established rules. So, there are rules for DevOps. Work with them in an iterative way and develop them together.
The views, thoughts, and opinions expressed in the text above belong solely to the author(s) and do not necessarily represent the views of DASA.
Join DASA
DASA has developed a flexible approach to membership that suits the size and requirements of each member organisation. All options are designed to address challenges, foster agility, and help in delivering business value more quickly.
