Devops for Growth

Quelles sont les capabilities que nous avons utilisées dans le cadre du projet 

• Oui = Nous utilisons la capability
• Non = Nous ne travaillons pas sur ce sujet
• A améliorer = Nous avons des axes de progrès

automation

 (À améliorer)

 (À améliorer)

 (À améliorer)

 (À améliorer)

(À améliorer)

(*) nous n’utilisons pas trunk-based mais nous sommes dans la philosophie d’accelerate d’avoir des branches à courte durée de vie

 (À améliorer)

 (À améliorer)

 (À améliorer)

 (À améliorer)

 (À améliorer)

 (À améliorer)

(À améliorer

 (À améliorer)

 (À améliorer)

 (À améliorer)

(À améliorer)

Pour quel résultat ? :

• Rappelez-vous que nous mettions environ 100 jours pour déployer une version en production, aujourd’hui il nous faut 10 jours. L’impact pour les équipes est significatif car il montre de façon factuelle que nous pouvons nous améliorer et ceci est visible à la fois par les équipes, le responsable de la plateforme mais aussi la direction avec laquelle nous partageons chaque mois les indicateurs accelerate.
• A partir du moment où les indicateurs accelerate ont été présentés ainsi que les modalités de calcul, les équipes ne discutent plus de savoir si les indicateurs sont corrects ou non mais des actions concrètes qu’il est possible de mettre rapidement en place pour s’assurer que nous sommes sur la bonne voie et pivoter si nécessaire. Notre objectif reste l’amélioration continue.
• Nous voyons que nos échanges sont plus constructifs entre les équipes : il y a une volonté permanente d’améliorer nos pratiques et in fine d’améliorer le produit
• Les équipes de développement ont décidé de déployer sur l’environnement de recette pour réduire le lead time et s’approprier l’infrastructure AWS. De facto l’équipe est sortie de sa zone de confort pour améliorer le lead time.

Resetting an Entrenched Culture

Many organizations that have been around for a while have established processes that are hard to change. Mitch Ashley, CEO and managing analyst at Accelerated Strategies Group, who’s helped create several DevOps organizations, shared his perspective about why changing a culture can be so difficult. “Culture is a set of behaviors and norms, and also what’s rewarded in an organization. It’s both spoken and unspoken. When you’re in an organization for a period of time, you get the vibe pretty quickly. It’s a measurement culture, or a blame culture, or a performance culture, or whatever it is. Culture has mass and momentum, and it can be very hard to move. But, you can make cultural changes with work and effort.” 

What Mitch is referring to, this entrenched culture that can be hard to change, is sometimes called legacy cultural debt. I loved Mitch’s story about his first foray into DevOps because it’s a great place to start if you’re dealing with a really entrenched legacy culture. He and his team started a book club, and they read The Phoenix Project. He said, “The book sparked great conversations and helped us create a shared vision and understanding about our path to DevOps. We realized we all had questions, but we were all going to learn together. It was a really positive experience that created safety and trust along the way.”

Amin, who’s been at the IRS for five years, made a great point about how he helped make a cultural change within a really entrenched organization. “When I told management that we could release 20 deliveries in a month, I heard ‘Why would we do that? We only have one release a year.’ I had to remind myself that moving to DevOps is a big cultural shift.” He repeatedly explained to IRS management that the organization needed to shift away from one big delivery a year to multiple microservices rolled out throughout the year. “Another way I helped get people to buy-in was to share some good examples,” Amin said. “I started with some small success stories, and slowly people started to understand the new DevOps processes and how they could benefit. People started to realize that having lots of people spending their nights and weekends working on roll-outs wasn’t the best way to do things.”

Brian also suggested a great idea to kick off a DevOps transformational effort: Host an agile “inception workshop.” It’s a two or three-day event where you bring together all of the functional stakeholders to align around goals, roles, responsibilities, and rules of engagement—to help build that culture of trust, understanding, and transparency.

Donovan Brown defines DevOps as "the union of people, process, and products to enable continuous delivery of value to our end users."

When we unpack this definition, we realize that the core of the DevOps mindset is to continuously deliver value and delight our customers.

• "Feedback from stakeholders is essential."
• "Improve beyond the limits of today's processes."
• "No new silos to break down silos."
• "Knowing your customers means cross-organization collaboration."
• "Inspire adoption through enthusiasm."

The kanban system helps us visualize and improve the efficiency of value delivery, resulting in delighted customers. I argue that if you are comfortable with kanban, you will enjoy the full benefits of DevOps through visualization, flow improvement, feedback, and continuous innovation.

A qui s’adresse la trilogie Culture DevOps, et plus particulièrement ce volume 2 ?

A tous ceux qui veulent comprendre les enjeux et les bonnes pratiques DevOps.

Le second volume concerne particulièrement les personnes confrontées concrètement à des problématiques techniques de déploiement et d’industrialisation – côté dev, ops ou côté architecture.

Les volumes 1 et 3 (à venir), qui traitent respectivement des sujets d’organisation et des pratiques de qualité portent des messages qui ne laisseront pas le top management insensible…