It’s always a shock to discover just to what extent a big organization can silo activities to the point where engineers lose the meaning and understanding of their work’s overall value, thus plunging them into a form of alienation that ends up establishing itself as an organizational and social norm (this is a never ending sociological topic!). I was recently involved in an agile transformation by intervening exclusively on the operations side. I was surprised that I was asked to carry out this kind of assignment, I had been more used to the organization of product management and development. But I have always been more or less involved in the operational part, in order to roll out, size and prepare infrastructures, measure performance, intervene in incidents or production bugs, evaluate the entropy of an application and determine technical developments’ needs. The reality is that we are never far from operations when we manage a product, it’s part of the job, even before we start talking about DevOps’ principles!
But my client’s goal was to transform his organization, break the silos up, and I took advantage of that experience to try to understand how DevOps’ practices could fit in and become the default operative mode in a long-standing organization that until then had been working in silos.
I took the opportunity to pass a DevOps’ certification to immerse myself in concepts that have matured over recent years, and also to understand production services’ issues in large organizations that are on the path of agilization. Finally, this experience brought me a great wealth of learning and lead me to give this feedback today, which explains among other things how the introduction of a new role, as the system owner, helped us to conceptualize and materialize a long-term direction towards the adoption of DevOps’ practices.
The first part of this feedback goes back to the context and the pitfalls that I had encountered. The second and third part will recall the panorama of DevOps’ practices advocated by the agile community and associated organizations, and finally the last part will describe the device set up to make this journey to DevOps.
This organization, like many large organizations, has been educated with ITIL. Despite what the method’s most die-hard defenders say, this naturally introduces a bias that tends to move towards working in silos. This is mostly due to three factors:
- ITIL segments the overall activity of providing an IT service into multiple specialized services (in essence considering the notion of support at the expense of value).
- Therefore, to make these different services work with each other and with others, it is necessary to agree on service contracts that allow everyone to determine their scope and the means they must implement to cover it.
- This in turn introduces a customer – supplier relationship in between each service.
On paper, we understand that this responds to a need for structuring aimed at operational efficiency and resource optimization. But this also presents important and completely anti-agile consequences for the organization:
- Each service will tend to optimize its operations without looking at the impact on the value produced for the user (or on people who come to significantly reduce their area of competences while amplifying their expertise in a field that potentially may become obsolete due to IT’s evolution). The organization focuses on its operations rather than the end customer.
- In order to work between services, it is necessary for the applicant to describe their need and to make the other person understand it by providing detailed documentation and making a skills transfer. The supplier will in turn have to demonstrate that he has all faculties necessary to understand and therefore do. Inevitably, we enter an exchange loop and a colossal loss of time and an endless loss of energy around the skills transfer.
- Once the request is sent to the supplier, and when they validate it, well.. There is nothing else one can do but wait! Because you do not know if your supplier really has the ability to do what is needed within the time that you desire and you will probably slip into a long waiting-list.
- Also, do not expect to have much compassion from your colleagues, because truly it does not come from your colleague but from your supplier. This implies the responsibility’s watering down towards the final service delivered to the user as well as an unhealthy game of the rejection of responsibility between services, even within the services themselves.
- The managerial posture reflects these dysfunctions and obliges itself to a directive behavior, sanctioning the error and accentuating the need for control and thus an overload of manpower, bureaucracy and tools.
- And we can continue the long list of dysfunctions related to this model…
But IT’s place in business has changed a lot and is no longer a banal support service. Digital technology has entered the value chain, which requires from IT to meet the ever more urgent demands of the business’ behalf. The organization’s consequence is to face the famous wall of confusion, opposing operations attached to stability and a barrier of technical requirements, in face of the development wishing to control the deployments’ pace and conditions themselves. However, facing a dilemma, the way of approaching the problem is not the same according to the services given, and one can identify three general functioning models:
100% V model: First there are those who are fond of the usual partitioning and who generally work in a V-cycle. This is either the history and the people, or the projects if they are based on off-the-shelf solutions that are difficult to consider (on paper at least) with the Agile method. In general, studies in this format prefer a directive and predictive mode of operation. The level of autonomy, advice and initiative of operations is weak which makes it possible to avoid arguments. Operations like to anticipate change, which (falsely) reassures the risk involved.
Agile Ad Hoc Model: Then there are those who speed themselves up ad hoc. That is to say, leaving the possibility to the development department to go up to the opportunity of autonomous agile teams but who remain in isolation, whereas production is not really within the project team’s scope. This may respond to a business request or a project manager’s desire to change the method. This organization responds well to the need to improve delivery and is generally the cornerstone of an agilization approach. But it misses the goal of agility in the sense of improving time to market, learning by rapid feedback and adaptation to change in relation to competition or new uses.
Agile Model Scale: Finally there are those who have managed to integrate teams, create feature teams by mixing Dev, Ops and trades, remove the wall of confusion, deploy continuously and on demand. But often this model works by bypassing traditional services. This is the lab’s model that grow everywhere in large organizations. Obviously this becomes more and more efficient and we are able to reach the goal of the DevOps with an autonomous team model in responsibility and action. But it also means that the rest of the organization does not learn from this model, which therefore remains an exception. Worse, when the application portfolio developed by the lab decreases in value, it is then sent back to the traditional functional services which then have no history of the application and benefit from a knowledge transfer that is low in quality, which ends with the degradation of the service rendered.
For this client, these 3 models are at work at the same time! It is obviously difficult to respond effectively to everything under these conditions. The big gap is permanent and the production project manager finds himself lost facing that which is expected of him. It is also becoming difficult to provide the right direction to operations departments constantly bounced between the temptation to switch to DevOps, but by missing real positive and significant experiences to justify it, or to stay in a traditional, rather ITIL, mode asking studies to establish their credentials to implement the slightest corrective action. Obviously, this last option seems suicidal because it offers an objective opportunity for development department to switch completely to the cloud by completely bypassing the Operations Directorate.
But, overall, the report is still mostly there: it will be necessary to keep project managers and find a way of working with agile teams and labs. This implies living with an organization that pools skills while proposing a mode of operation that favors the adoption of DevOps practices and can eventually move towards vertical, autonomous and versatile teams that are integrated by the product. The state of agile art responds only slightly to these heterogeneous configurations which are common situations nevertheless. Being in the middle of the ford is not the ideal situation when looking for answers in methodological frameworks, but it is nevertheless essential to understand the objective and the target in order to find the best way to reach the transformation’s other side.