As the saying goes, it’s not about the destination, it’s about the journey. The same could be said about DevOps and its implementation in an organization. Yes, the result is magic since it aims to deliver daily business value, but the journey is even more interesting. This journey is full of organizational, technological, but especially human discoveries.
In the last few years, I have accompanied companies that has begun or has already begun their transition to agility and most of these clients, without explicitly saying so, wanted to put in place a DevOps culture in their organization. While others were directly asking me the question: How do I implement a DevOps culture?
In all projects and companies, I saw a "pattern" emerge that has become, over the years, an order to implement a DevOps practice. It's certainly not the only approach, far from it, but it's the one I've seen working with many customers.
Here is what I call the DevOps Cake…
By explaining this "pattern" in the past few weeks, I have drawn what looks like a wedding cake, so here's the reason behind its name ... As a cake, each step relies on the previous steps to be solid and to give the best result.
Step 1 – Continuous Integration
This first step is the foundation, or even the cornerstone, of everything that will follow afterwards. The reason why this is the first is that generally the implementation of agility always begins at the level of one or more development teams and continuous integration is often the first thing a Scrum team is going to do. Continuous integration will only disorganize that development team and will spare the rest of the organization thus making this step a strategic option.
During this stage, the team will be forced to design and develop in such a way that they can integrate on a daily basis or otherwise will greatly complicate their work and even become a blocker. Unfortunately, it is at this stage that several organizations will be blocked because the next step, design by testing, is the first step that will bring changes outside the team.
Step 2 – Automated testing and design by the tests
This second step is one of my favorites for several reasons. First, this stage validates whether design and development follow good agile practices. Secondly, it validates whether the organization understands and believes in agility because the previous stage only jostled the development team, this step will widen the disturbances and this at several levels:
- This step will upset the management, accustomed to a past velocity not including the development of automated tests, the new velocity of the teams will disrupt their planning.
- The automated acceptance tests will upset the business people, example the product owner. The introduction of this practice, if it is to be successful, will force them to cut out their stories in a different way and think in use case. Then, to allow the development team to properly design the upstream tests, acceptance criteria should be well defined for sprint planning.
It is often during this stage that Scrum takes a hit and that the compromises will begin not to upset the ways of doing or to put people in a situation of discomfort but of learning. It is for this reason that several organizations remain at this stage or even completely stop the practice of automated testing. By doing this, their perception and understanding of the practice remains tainted with the cost of rising skill without ever benefiting from the positive results.
This step is one of my favorites because it is often during this stage that the click happen with the development team. It is during this stage that the team realizes the real value of continuous integration and the benefits of having a good battery of automated tests, both unitary and acceptance.
Step 3 – Integration of databases into the iterative development
When the Scrum team has reached a good level of maturity with the previous two steps and this can be observed when in the retrospectives, the team begins to identify the databases as being a blocker to deliver business value faster. This is especially true in organizations where modeling and changes in databases can be done only by DBAs (database administrators). One of the reasons why this problem does not emerge earlier is that the development teams, in the two previous stages, are learning a lot which allows the DBA to keep up with Scrum teams while keeping their way how.
Aside from the arrival of NoSQL databases, the world of databases has not changed much in its way of doing compared to other spheres of software development, which is why this step will bring different challenges for the DBA:
- With the cadence of sprints, development teams will not always be able to anticipate several weeks or several days ahead the modifications they need in the models. This will cause the DBAs to be overloaded with requests at the start of the sprint and this overload will become a blocker for development teams. It is therefore essential that development teams be autonomous to make changes to the database schema since providing the modifications several sprints ahead is not the solution. A potential solution is to add an item to the definition to terminate for a DBA to look at the schema changes, like the code review.
- Since database changes can be made by any member of the development team, these changes must follow the same rules as the rest of the code: be automated, versioned, and merged daily.
So asking them overnight to change their way of doing their job and often their tools to be able to keep up with the pace Scrum teams can be insecure. I believe they have everything to gain from making the change to let the organization benefit of their knowledges rather than being responsible for designing and running SQL scripts. This step is crucial for the next one if you want to be able to automate the entire deployment process to include databases.
Step 4 – Continuous Delivery
The next step for a Scrum team and an organization that aims to implement DevOps is automating the deployments. Usually this step makes its appearance when the team or teams reach a mature level with the previous steps and want to include deployment in their value delivery process or definition of done.
After the introduction of the DBAs with the previous step, this time we introduce the infrastructure team in the broad sense. Like the DBA teams, the infrastructure team must change their way of working, which means giving more flexibility to the development teams. What I mean by that is that the infrastructure teams, the Ops, have to define the recipes or containers, but leave the development teams, the Devs, free to put what they want. So to have an infrastructure that meets their need and not a "one size fit all" infrastructure that is typically seen in organizations.
This step is often not a technical but more organizational challenge, apart from the learning curve of automated deployment tools, since usually as in most organizations, there is a history between Dev and Ops. It is for this reason that it is at this stage that we see the dysfunctions which will be the future challenges to the implantation of DevOps in an organization.
The infrastructure team (including managers) should no longer see infrastructure as their property, but rather as a vehicle for development teams to deliver business value more quickly. Being responsible for the container and not the content, it is imperative that the Ops teams change their way of looking at things, thus respecting their goals as well as those of the development teams. At this stage, usually the infrastructure for each stage (development, staging and production) will be created manually, but deployments will be automated. This will lead, in some cases, to inconsistencies between stages, but above all an enormous pressure on the Ops team which, by the manual approach, will have difficulty following the cadence of the Scrum or Kanban teams. Unfortunately, to move on to the next stage, much like the DBA, it is the pressure or the desire to learn and to improve that will make the Ops move towards the automation of the creation of the whole infrastructure.
Step 5 – "Infrastructure as code"
This is the last step, and this is the stage where technology will be the solution to reduce the pressure on a team, that of the Ops and at the same time accelerates the delivery cycle of the Devs. As I said earlier, before we get to this stage, both the organization and the Ops must see that the old ways of doing things, which are not bad in themselves, but not adapted to keep pace of agility. Typically, during this stage the Devs and the Ops of the organization, go together to set up the tools and techniques to respect the mission of each one who, as I said in another post, goes the opposite of each other. And it is only after that than a DevOps practice can be implemented throughout the organization. These tools and methods will enable the Ops to produce automated technology recipes, which they will make available to development teams. Thus the infrastructure will be immutable and defined as a whole by the Ops while allowing the Devs to use them and to deploy the software increments prioritized according to the business value.
Organizations, in their adventure towards DevOps or just to improve the implementation of agility, usually follow this cycle and as you can see, there are several steps to get there. And every time, it is when the people become mature with everything that involves the current stage they will be pushed to move on to the next. It is for this reason that I often say that we cannot be agile, it is rather an ideal to which we must tend, since there is always something that can be improved, whether it be us or our ways of doing things.
I have not spoken explicitly but it is a agile framework, like Scrum or Kanban, that stimulates the continuous improvement essential for DevOps's culture. When we look carefully at the sequence of steps, we can detect 3 elements strongly linked together, the agile process, the tools and the people. And at the base it is this continuous loop that allows to pass the 5 stages and at the same time to obtain gains for the whole organization.
When you reach the last stage it is not finished, far from it!
The challenge now is to decrease the cycle time of the entire organization. What I mean by this, is to reduce the time between the emergence of an idea or the identification of a new need until its deployment in production. And this becomes possible by continuously inspecting and adapting our process with the help of an agile framework such as Scrum or Kanban.
As I said at the beginning of my post, the implantation of DevOps is a journey of discovery, discovery of dysfunction throughout the organization. It may sound negative, but it is far from being so, since these dysfunctions are only opportunities for learning and improvement for the organization and at the same time for the people involved. Then it is the ability of an organization to inspect and adapt that allows not to get stuck at a stage and thus not to reach the full potential of the implantation of DevOps or even agility.
In my next post I will talk more about the technological and technical aspects of each stage, good trip!