Why do we do DevOps if we have Agile?

Is Devops the same as agile and how are they different?

So I'm often asked, JP, what is Devops Anyway? We already have Agile, is Devops supposed to replace it?

The short answer is no.

Agile is a software development methodology, that leverages cyclic reviews (sprints or iterations) that are defined as shorter than a month, to ensure the process maintains sanity. These reviews are traditionally driven by the people on the team(s) and quite subjective. They focus on delivering what was promised above and beyond all manage intrinsic "unexpected" change. 

Devops over-arches this. It reviews cycles with "mechanical" and automated metrics. It attempts to depersonalize and make measurements as objective as possible. It's cyclicity is as short as a delivery cycle, which ideally can be several times of day. But the data can be reviewed at any periodicity, included the sprints or iterations that Agile has defined.

Agile protects and isolates the development team. Their motivation is usually delivering what was promised in the most expedient way. In some ways, it contributes to silos.

Devops exposes and wants to include the teams of previous and following processes. The pretension being the more you know about those you will be working for or with, the better off you will understand what you need to do. It promotes autonomy rather than isolation. Continuous improvement instead of a stable recipe for stable software delivery. It considers the human factor as something to leverage, by also the Agile process itself. And lets not forget all the tools and automation that people usually associate with the term, in the first place.

So in my opinion, Agile is more about software development and Agile is more about all around business needs. After all it allows you to do more while using less. It focuses on adding value rather than maintaining a stipulated agreement.

But as I often say, my promise is my process. If it is built to consider experimentation, failure and success as part of it. How can I possibly lose? And to me, that is the best of what Devops has to offer.

Qu'est-ce qui a de nouveau a comprendre de DevOps?

Qu'est-ce qui a de nouveau à comprendre de DevOps au Québec?

Les deux faces de DevOps

Il semble que si on allait simplifier la signification du terme DevOps on l'aurait fait.

Démystifier DevOps, cela restera un enjeu, mais pourquoi?

Étant un sujet toujours aussi "sexy" il y a beaucoup "d'appropriation" du terme DevOps.

En effet il y a des ressources qui prétendent être "DevOps" comme si c'était un rôle.

Pour que cette ressource soit désirable comme un espèce de nouveau Guru dans l'entreprise.

Certainement en plaçant un guru sur lequel la réussite ou le blâme peut être facilement visé, est d'intérêt pour la cupidité humaine, par exemple. Et les recruteurs du Québec profitent de cette confusion en allant chercher tout et n'importe quoi qui est précédé ou qui contient le terme DevOps et le vendant comme une panacée.

Et on en a pas fini avec la cupidité, regrettablement...

On est pas un "DevOps", pas plus qu'on est un "Agile".

Mais c'est vrai qu'il y a des spécialistes en opérationalisation ou en automatisation de déploiement qui sont critiques à DevOps, c'est vrai. Et c'est l'étiquette DevOps est hyper-vendable... alors il s'approprient aussi le terme, se disant qu'il s'expliqueront et comprendront avec le client ultime. 

J'ai du mal à les blâmer.

Tout comme un Scrum Master est requis dans la méthode Agile, ces spécialistes sont cruciaux, certes, mais tant que ce faux débat ne sera pas éclairci, le bruit qu'il représente justifiera un ralentissement de l'adoption du DevOps.

Alors quoi?

Aujourd'hui comment on peut mieux exprimer c'est quoi l'apport de DevOps?

Dans les faits il s'agit plutôt d'une façon de faire, holistique. Avec DevOps on veut devenir une équipe hyper performante et celle-ci ne doit pa être dépendante d'individus détenant la science infuse, au contraire. Même si on veut industrialiser le processus de livrer du logiciel, pour être efficace on doit considérer la ressource ou matière première: les gens. Pas des gurus ou des Super Héros.

Effectivement si ils s'agit d'humains, il nous servira bien de les apprécier à leur pleine valeur, et quel est le meilleur moyen d'en tirer le maximum, sinon de les avoir motivés à réussir?

Donc, contrairement à Agile ce n'est pas tant une méthode qu'un état d'esprit ou une philosophie, à la limite, à cultiver.

On doit capitaliser sur le bénéfices d'un esprit collectif, notamment.

• L'aise de communication
• Un effort orienté vers un but commun
• Une compréhension des préoccupations/des rôles professionnelles des individus au sein de cette collectivité pour être sensible à comprendre que la réussite de l'un entraîne la réussite de la collectivité. Et il en est de même pour l'échec.
• L'expérience collective est un atout important.

Il devrait être clair qu'un saine collaboration gagne sur l'individualité.

Et parmi les préoccupations majeures que DevOps tente d'adresser dans un projet, au sein des équipes en voici des exemples saillants, dans aucun ordre particulier:

• Savoir négocier et décider en équipe de façon efficace
• Réduire le travail en cours (WIP ou Work In Progress)
• Faire la bonne chose au bon moment (Do the right thing at the right time)
• Faire les choses en amont, de ne pas faire attendre ce qui ne le doit pas. (Shift Left)
• Exploiter les contraintes
• Cultiver la confiance
• Augmenter l'autonomie des équipes.
• Faire les erreurs au bon moment.
• Experimenter et apprendre.
• Que DevOps soit un objectif commun
• Comprendre la valeur que DevOps apport au projet(s)
• Défaire les silos qui séparent les préoccupations classiques, soit entre Dev et OPS ou même encore La sécurité DevOps/SecDevOps
• Bien gérer le travail planifié versus le travail imprévu.
• Cultiver un environnement de travail sain, où le bien commun et la charge est bien distribuée.
• Avoir un processus qui supporte la réalisation efficace.
• Automatiser et systématiser ce qui en vaut la peine, plutôt que de tenter tout le faire.
• Capitaliser de la flexibilité des infrastructures virtuelles et agiles pour aller plus vite avec moins de risques.

Si il y a raison de voir un importance de comprendre ce que cette relativement nouvelle façon de faire apporte, est justement la sensibilité au temps que ceci peut avoir.

Pourquoi c'est si lent à arriver?

Démarrer une initiative DevOps sans échec est beaucoup plus facile qu'on se l'imagine et pourtant le monde des TI est très hésitant à démarrer particulièrement au Québec.

Depuis près de cinq ans la communauté et moi-même, poussons et tirons dans tous le sens pour obtenir une traction sur le changement bénéfique proposé. Tout le monde parle de révolution numérique, mais les projets TI ne consomment pas les bénéfices systémiques qu'ils proposent souvent eux mêmes!

Quand on comprend qu'il ne s'agit pas de tout révolutionner d'un seul coup, qui s'agit d'utiliser la progressivité itérative pour, experimenter et mesurer sa réussite, on comprend du coup, qu'il s'agit d'une transformation culturelle et mentale à la base. Et même si l'initiative est bien mature dans les pays francophones de l'Europe, au Québec, on traîne de la patte, comme on le dit. 

Et si on regarde le temps que la méthodologie Agile prend du temps à se propager ici, et pourtant sa maturité, on comprend qu'on ne peut pas se vanter d'être toujours à l'avant garde des bonnes pratiques de industrialize.

Les organisations justifient leur reticence, en partie de ne pas vouloir perturber les employés ou opérations actuelles. Surtout qu'au Québec, je dois le dire, la pénurie de main d'oeuvre qualifiée en TI a généré toute une troupe de personnes sur le marché du travail qui se comportent en "royauté", qui au moindre dérangement menace le départ.

Mais DevOps n'est pas sensé être perturbateur même si c'est transformateur. On est sensé travailler mieux et non plus fort. Plus intelligemment avec plus d'empathie.

Et c'est pourquoi il est impératif comme leader ou dirigeant d'entreprise de bien comprendre le bienfaits. Si on est sensé en faire une transformation organisationnelle, il devient évident comment le choix du porteur de cette initiative est critique.

Mais cela s'en vient.

Mon observation du marché propose qu'il y a un movement en cours. Éventuellement il y aura ceux qui sont Agiles et Devops et les autres. Le organisations qui tardent à changer auront toujours une place figurant dans le logiciel "à bon marché" ou peu dispendieux. Le prix final de la réalisation d'un projet est encore un facteur important dans la considération de la clientèle actuelle du Québec.

Mais ceux qui auront adopté Agile et Devops, auront l'avantage de la qualité, l'habileté à redresser des scénarios incohérents, des équipes heureuses et surtout efficaces. 

Alors ma question pour vous est: avec qui voudriez vous travailler?