Our DevOps culture
With the emergence of agile methods over the last few decades (Agile Manifesto - February 2001), it is now accepted among developers that our job is to deliver value quickly through an iterative approach coupled with continuous improvement.
We can discuss the fluctuating level of maturity of developers who put "Agile / Scrum" on their CV (the most mature will understand: Scrum != Agile) but it is undeniable that they have understood the interest of iterations and the feedback loop.
Indeed, if there is one thing to remember in this post, it is the importance of this feedback loop: the earlier a problem is discovered, the less expensive it is to solve.
This avoids the tunnel effect and allows us to deliver value to our client from the first iteration. Interesting collateral effect, if our project stops (budget, politics, pandemic, ...), the value delivered is usable and so whatever happens we get value for money.
After such an idyllic picture one might think that now it's just a matter of helping developers mature their understanding of the agile culture.
But the reality is quite different. Most of you are confronted with it on a daily basis: we do 2 week iterations but we deliver 4 times a year in production. So forget the nice speech about added value every fortnight, the feedback loop on the release of code produced on average 2 months ago, etc... 20 years of evangelism to get there? Why is this?
The answer is simple: to optimise, we were separated! We were inspired by mass production techniques to push output to the maximum, such as Taylorism.
In a world where division of labour is already the norm, to achieve conditions to provide maximum output within an organisation, Taylorism advocates:
a detailed and rigorous analysis - hence the emphasis on the term "scientific" - of production methods and techniques (gestures, rhythms, rates, etc.);
the establishment of the "one best way" to produce (definition, delimitation and sequencing of tasks);
setting more objective and motivating pay conditions. This is what gives Taylorism its name
However, what is true for the production of thousands of cars (deterministic approach), is not true for our business: to bring value to my client so that he can differentiate himself from competitors (empirical approach). Each of my clients has its own specificities.
With industrialisation, we set up a production chain that is very expensive. This is profitable when you produce several thousand cars. Otherwise it is better to make them by hand. In our business we do not produce several thousand identical cars. However, we are faced with the eternal problem of costs, which forces us to find solutions. So I automate some tasks but I keep the flexibility to reorganise the whole process every day. This automation takes on various aspects (continuous integration, continuous deployment, architecture patterns, reuse of bricks, cloud, etc.).
We are not industrialising but automating!
So this industrialisation has divided us, which has had the perverse effect of making us less responsible: you only have to talk to the different teams to quickly understand that the culprit is always the other. Each person's objective is to do his or her task as well as possible without worrying about the other. The developer's goal is to produce code, build an architecture, ensure maintainability and now make changes. The ops' goal is stability, security, making sure everything runs. This separation means that there is a latent misunderstanding between developers and operational staff. But above all we have forgotten our common goal: to deliver value to the business!
DEVOPS culture is about breaking down this wall of confusion to impose our joint responsibility. It is about finding a fast feedback loop on the entire life cycle of an application (and not just its construction). It means working together.
How ?
Purists will tell you to put ops and dev together. Unfortunately, it will take some convincing because having one network administrator per development team will not help to rationalise costs.
Others will create a third team whose objective is to get the other two to talk. We can then ask ourselves if the creation of an additional team really makes exchanges more fluid and improves the feedback loop?
Finally, there are those who put a tool in place (docker at random) and hope that by magic the rest will follow. Indeed, the automation axis will be well addressed but the most difficult part remains communication. Be careful not to confuse DEVOPS tools with DEVOPS culture, even if both are important.
There is no simple answer. You need to create your DEVOPS culture by empowering your teams and giving them the means to automate and streamline the life cycle of your applications as much as possible in order to have the shortest possible feedback loop. That's all there is to it...
Those who have already tried this measure the difficulty. In order to address this, we at CROSS, have divided DEVOPS into 5 major practices. This way we can audit each practice and, depending on your objectives, measure your DEVOPS maturity. Following this analysis, we can identify bottlenecks and help you work on areas for improvement.
In addition to these 5 practices, it is important to also address security issues (DEVSECOPS).
In future articles we will go into more detail on each of these practices in order to better understand what they cover and how to improve your feedback loop.
