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 :)
Bienvenue dans ce second épisode de ce qui menace de se transformer en série de posts sur DevOps et la transformation DevOps. Malheureusement pour vous, je dis souvent ce qui me passe par la tête, et il n’y a aucun plan génial visant à écrire un livre chapitre par chapitre. Le premier article parlait de choisir une stratégie lors de la transformation DevOps d’une équipe de services managés. Ce second article ne vient pas nécessairement après le premier, vous avez toute liberté de choix :) D’une certaine façon, mon sentiment est que DevOps est assez proche d’ITIL dans l’esprit : une boite à outils où vous pouvez prendre ce dont vous avez besoin, et décider comment l’utiliser. Donc, sujet d’aujourd’hui : comment viser, ou construire l’équipe qui va initier le mouvement DevOps dans votre
transformation DevOps. Malheureusement pour vous, je dis souvent ce qui me passe par la tête, et il n’y a aucun plan génial visant à écrire un livre chapitre par chapitre. Le premier article parlait de choisir une stratégie lors de la transformation DevOps d’une équipe de services managés. Ce second article ne vient pas nécessairement après le premier, vous avez toute liberté de choix :) D’une certaine façon, mon sentiment est que DevOps est assez proche d’ITIL dans l’esprit : une boite à outils où vous pouvez prendre ce dont vous avez besoin, et décider comment l’utiliser. Donc, sujet d’aujourd’hui : comment viser, ou construire l’équipe qui va initier le mouvement DevOps dans votre organisation? Il existe plusieurs indicateurs sur lesquels s’appuyer pour faire ce choix. Aucun n’est absolu. Encore une fois, je ne vous donne que des indications pour sélectionner l’équipe qui va réussir à appliquer des principes DevOps. Il n’y a pas de Remède miracle, ni de baguette magique! Le critère le plus évident est de constituer une nouvelle équipe, en sélectionnant des collaborateurs qui sont déjà au fait de DevOps, et désireux de s’y mettre. Cr sont les personnes qui sont les plus susceptibles de vous aider à réussir ce premier pas, et montrer au reste de l’organisation que la transformation est possible, et qu’elle génère beaucoup de gains et bénéfices. Le second indicateur à repérer est fortement lié au principal objet des méthodes DevOps : le software delivery. Si vous avez une équipe qui rencontre des difficultés à maintenir un processus de livraison de code fiable, et que cette équipe est prête à s’investir pour construire l’équipe et les outils nécessaires pour en arriver là, alors vous avez un très bon candidat. A l’opposé, si vous essayez de convaincre une équipe qu’elle doit s’intéresser à DevOps, alors qu’ils sont persuadés que leur processus actuel est fiable et de qualité, à tort ou à raison, vous allez vous heurter à un mur. Il ne semble pas pertinent de consommer du temps et de l’énergie dès le départ pour convaincre des gens qu’ils effectuent un travail de piètre qualité s’ils ne le réalisent pas. Ce n’est très probablement pas la bonne cible pour votre premier pas vers DevOps. Le dernier critère nous ramène à mon sujet favori, en dehors de la technique : les bénéfices business! Cela paraît évident, mais une transformation dans votre organisation doit toujours être sensible aux objectifs business, à la cible de l’entreprise dans son ensemble. Imaginons que vous choisissiez une équipe qui travaille sur un produit en fin de vie sur lequel aucune évolution n’est prévue, et dont les clients sont satisfaits. J’ai bien peur que vous n’ayez aucun soutien, ni aucun résultat évident si vous démarrez votre transformation DevOps par cette équipe. D’un autre côté, si vous arrivez à commencer par une équipe travaillant sur le produit phare de l’organisation, sur lequel les yeux des plus hautes instances sont rivés, et qui doit démontrer une capacité de livraison de code moderne et fiable… vous avez votre champion. (petit bémol, c’est aussi probablement le candidat sur lequel vous n’aurez pas le droit à l’erreur… mais on ne vit pas sans se mettre un peu en danger régulièrement :) ) Une fois cette équipe choisie, ou construite, commencez à travailler. Gardez à l’esprit, tout le temps, que le cœur de DevOps, comme toujours, est l’humain et non uniquement les outils. Le bon sens va dicter la seule chose à retenir de cet article . Je vais paraphraser quelqu’un qui a implémenté des organisation Agile/DEvOps multiples : “Nous avions démarré avec une population difficile, et nous leur avons donné des outils et méthodes modernes et intelligents. Ca n’en a pas fait une population moderne et intelligente.” Je dois admettre que la citation d’origine était plus… rude, mais je ne peux l’écrire ici :) PS : J’essaye de garder ces articles à une taille raisonnable, et je ne fais pas de deep dive sur chaque sujet évoqué. Croyez-moi c’est volontaire, ce n’est pas uniquement de la flemme. Si vous voulez en savoir plus sur un sujet particulier, demandez-moi, ou bien trouvez un bon livre/article de référence! A très bientôt!