DevOps transformation – choose your target wisely

This is a second post in what might become a series regarding DevOps, and DevOps transformation. Unfortunately for you, I speak my mind when I feel like it, so there is no master plan behind my ranting. First post was about choosing a strategy when transforming a managed services team towards DevOps.

This second step may not come necessarily after that first step 🙂 You get to choose.

In a way, I have the feeling that DevOps is close to what ITIL is : a toolbox where you can select which parts you would like to apply, and the way to implement them.

So new topic : how to target or build the team which will start the DevOps initiative in your organization?

There are several indicators that you can use to make this selection. None is an absolute, once again, these are pointers to which team would better succeed in applying DevOps principles. There is no sure shot, no magic finger method 🙂

The obvious criteria is to pick a team, of future team members that are already aware of DevOps, and willing to make the move. Of course these would be the people that will help you succeed in the first move, and show the rest of the world that it can be done, and bring very positive outcomes.

The second flag that should be raised is tied to one of the main outcome of DevOps : software delivery. If you have a team that is already struggling to get a reliable software delivery in place, and is willing to put the effort into building the organization and tools to get there, then you have a probable winner 🙂 On the opposite, if you try to convince a team that they need to move to DevOps when they are convinced their software is delivered efficiently and reliably, you’re going to hit a wall. Basically it would come down to convincing them that they are doing a poor job and are not even aware of that. Maybe not the right target for your first DevOps project.

The last one brings us to my favorite topic, outside of tech stuff : business outcome!

Of course, the aim of a transformation within your organization should always be mindful of the business outcome. Imagine you pick a team that is working on a neglected piece of software that no one cares about, and of which customers are just happy of the current situation. I do not think you would get the visibility and traction, not to mention willingness if you try to initiate your DevOps transformation in there. On the other hand, if you manage to get a team working on a new flagship product, that gets the attention of the CxOs, and has a need to show modern and reliable software delivery… you have a winner!

Once you’ve chosen your dream team, and start working, remember that DevOps, as always, is about people, not just tools.

The key thing to take away stems from common sense, and has been given by someone who did try and implement multiple Agile/DevOps organizations: “if you start with bad people and give them a smart way to work together, they won’t become smart by themselves”. Alright, I must admit the original quote was much harsher, but I cannot write it here 🙂

PS : I tend to keep these article short, and do not dive into each topic. This is done on purpose, not just by laziness. If you need to go deeper in each topic, just ask, or get a good read 🙂

La transfo DevOps – Ă©tape 1

Je sais, tout le monde parle de DevOps, Ă  tort et Ă  travers, mais parfois Ă  raison. C’est un terme souvent utilisĂ© pour redorer une image d’Ă©quipe ou de practice, et donner une touche sexy sur un jeu de diapositives. Je le vois souvent utilisĂ© pour dĂ©crire ce qui n’est essentiellement que de l’automatisation dans une Ă©quipe Ops/infrastructure. C’est un bon dĂ©but, mais ce n’est qu’un dĂ©but, pas le voyage complet.

NĂ©anmoins, ayant Ă©tĂ© acteur, parfois majeur, et tĂ©moin de plusieurs de ces transformations vers le DevOps, je voulais donner mon avis, Ă  qui veut bien l’entendre. Ce que je vais dire va sĂ»rement paraĂ®tre trivial Ă  certains d’entre vous, mais pourrait donner quelques indices Ă  ceux qui se demandent oĂą va le mĂ©tier d’infogĂ©reur.

Je parle de transformation DevOps, spĂ©cifiquement lorsque cette transformation touche une Ă©quipe de Managed Services/infogĂ©rance. C’est un sujet difficile dans ce contexte, car ces Ă©quipes doivent fournir un support moderne Ă  leur client, qui sont parfois dĂ©jĂ  organisĂ©s en mode DevOps, et mĂŞme les aider Ă  vivre cette transformation.

Je ne vais pas entrer dans les sujets contractuels et SLA, c’est un point très sensible et complexe. En tout cas, pas aujourd’hui.

J’ai pu observer deux façons d’approcher ce sujet. La première est une transformation complète et radicale de l’existant, pas de quartiers. La seconde est de construire une nouvelle Ă©quipe dĂ©diĂ©e DevOps, en parallèle de l’existant.

J’ai seulement vĂ©cu la seconde mĂ©thode personnellement. Il s’agissait d’une opportunitĂ© car nous amenions tout un panel de nouvelles technologies et de clients dans une Ă©quipe d’infogĂ©rance existante. J’ai pu faire le choix de repartir d’une feuille blanche et de bâtir un ensemble d’outils et de mĂ©thodes pour desservir des nouveaux clients dans un nouveau modèle, en ne m’appuyant qu’au strict minimum sur l’existant. Cela nous a donnĂ© la possibilitĂ© d’ĂŞtre crĂ©atif et de dĂ©montrer la viabilitĂ© des nouvelles mĂ©thodes de travail et d’interaction avec nos clients.

La partie difficile a Ă©tĂ© l’adaptation aux services existants. Par exemple, nous avons du commencer en conservant les outils de supervision existants, car nous ne pouvions pas demander aux Ă©quipes de monitoring 24*7 de surveiller des outils et dashboards multiples. Notre succès sur les autres domaines (infrastructure as code, focus sur l’applicatif) nous a permis ensuite de driver un changement de plate-forme de supervision, quelques mois après les premiers pas. Et le mouvement, une fois lancĂ©, a continuĂ©.

L’autre mĂ©thode, aka Big Bang, j’en ai Ă©tĂ© tĂ©moin. C’est une approche très disruptive, et qui ne peut pas ĂŞtre portĂ©e par n’importe qui. Il faut avoir un soutien de sa hiĂ©rarchie, jusqu’aux plus hauts niveaux, car l’implĂ©mentation va avoir des rĂ©percussions. Tout d’abord sur les Ă©quipes elles-mĂŞmes, car tous les profils ne sont pas prĂŞts Ă  changer du jour au lendemain, mĂŞme avec un accompagnement personnalisĂ©. Ensuite sur le delivery et les clients, car eux non plus ne sont pas forcĂ©ment convaincus, ou enchantĂ©s de subir les effets de bord de vos transformations internes.

Le cĂ´tĂ© très positif est par contre d’Ă©viter d’avoir Ă  gĂ©rer deux Ă©quipes en parallèle pour le mĂŞme service au client. Et surtout de ne pas conserver de legacy très longtemps.

Je ne peux que vous suggĂ©rer deux lectures pour en savoir plus sur les enjeux de cette transformation : Phoenix project, qui est une version romancĂ©e d’une Ă©volution DevOps, et The DevOps Handbook, qui donne les clĂ©s concrètes pour mener cette transformation.

La prochaine fois, je parlerais de comment il faut choisir la bonne cible, interne ou externe, pour démarrer ce voyage vers le monde merveilleux du DevOps.

DevOps transformation for Managed Services

I know, DevOps is still a buzzword. IT is often used to rebrand an old team or practice, and give more sexiness to a marketing slideset. I have seen it used to describe what is essentially an automation team within an Ops team. Good start, but missing the point.

Anyway, having been a major actor in a devops transformation, and witness to many, I wanted to give some advice to anyone out there patient enough to listen to me. I think most of what I am going to say will seem trivial, but it would help a few of us to put some words on what is happening to good ol’ outsourcing.

I am talking right now about DevOps transformation, but specifically when it happens to a Managed Services team, as in an outsourcing company, or an MSP. This is a difficult spot, as such teams should be able to provide support for DevOps organizations form their customers, and even help them.

I will skip the contract and SLA part, as it is a very tricky subject, at least for now.

I have seen two ways of approach the subject. First is full ahead transformation, no quarters, no mercy. The second is building a new team dedicated to DevOps, in parallel of the existing one.

I have only experienced the second first hand. It was an opportunity as we were bringing a new set of skills and customers into an existing managed services org. I chose to break from the past, and build a new set of tools and processes almost outside of the existing system. This creates the possibility to create and prove the viability of these new ways of working and interacting with your customers.

The difficult part is where you have to merge with the existing tools and processes. For example, we had to start with the monitoring tools we had, as we could not ask our 24*7 monitoring team to have multiple dashboards and tools. The fact that we were successful with the other tools and habits we developped allowed us to push for a new monitoring solution a few months after the initial move. And we kept the momentum after that 🙂

The other way I have witnessed, to transform the whole team at once, is challenging and cannot be carried by anyone on the team. I would advise that you start this path if you have a sufficient executive weight, or support from the executive team, because it will be a disruptive path. This is good, but the cost might be high, both in terms of people inside the team being disgruntled and maybe leaving, and in termes of your existing customers (and prospects) who might not understand what you are undetaking. The uptake is that you avoid having two different teams working with different mindsets and toolsets.

Obviously I would recommend reading the Devops Handbook, and the Phoenix Project, to get a basic understanding of what you are getting yourself into 🙂

Next up, I will try and help you target which team and/or customer would be a best fit to start your devops journey, stay tuned!