Auteurs: Nicole Forsgren, PhD, Jez Humble, Gene Kim

Année de parution: 2018

Éditeur: IT Revolution

Lien vers mes notes manuscrites numérisées

C’est intéressant de relire le même livre deux fois à trois ans d’intervalle. C’est la troisième fois que je me prête à cet exercice, et j’avoue que c’en est un essoufflant. J’ai hâte de passer à du nouveau contenu! Or, le contenu DevOps, c’est central à ma carrière, et c’est une bonne idée de valider que la première fois que je les ai lus, j’ai véritablement extrait l’essentiel.

Dans le fond, je révise autant mes notions DevOps que je valide la robustesse et la pertinence de mon système d’apprentissage.

Voici mes notes de la première fois que j’ai lu ce livre, et le review original (#19!). Et voici mes nouvelles notes. C’est intéressant de comparer que la première fois que j’ai lu ce livre j’ai focusé sur des choses différentes de la deuxième fois. C’est normal, en fait, parce que je savais déjà à quoi m’attendre. Je connaissais d’avance la construction du livre.

De quoi parle le livre dans son ensemble?

La recherche qui a mené à la philosophie DevOps. Rien de moins!

Que dit-on en détail, et comment?

On explique comment les employés de diverses entreprises ont été sondés pour établir des métriques qui permettent de déterminer leur capacité (“capabilities”, analogue à la maturité). On explique les résultats de ces études, comment les études ont été construites, et pourquoi ce choix de construction était approprié. Cela rend les conclusion du livre assez béton.

Qu’est-ce que j’ai appris?

J’ai pu mieux apprécié la nuance entre la capacité d’une organisation et sa maturité. La maturité sous-entend qu’une fois qu’on l’a, on ne peut pas reculer en arrière, ce qui est différent avec une capacité. Ainsi, quand on évalue l’avancement de l’amélioration continue dans une entreprise, il vaut mieux parler de capacité que de maturité.

Autre que cela, j’ai appris sur moi-même, comment je vis cet exercice de relire des livres que j’ai déjà explorés. En bref, c’est tortueux. J’ai mis beaucoup, beaucoup de temps à écrire ce review, simplement parce que ça ne me tentait pas, ayant l’impression de tourner en rond. Voilà le troisième lire core DevOps que je lis pour la deuxième fois. Ça me donne l’impression de faire du surplace.

J’ai appris que je suis prêt à donner la réponse à une question que je me pose depuis quelques années déjà: mon système d’apprentissage est assez bon. À partir de maintenant, quand je lis un livre, j’ai la conviction que je n’aurai pas besoin de le relire une deuxième fois. Quand je m’applique, j’arrive à extraire l’essentiel de la lecture.

Je suis vraiment satisfait de cette réalisation. Quand je compare les notes que j’ai prises sur ce livre en 2023 versus aujourd’hui, mes notes d’aujourd’hui sont beaucoup plus faciles à suivre.

Comment vais-je utiliser ce que j’ai appris?

Je vais prendre une pause de relire des livres deux fois. J’ai envie de continuer à apprendre, pas continuellement revenir sur mes pas!

Pourquoi dois-je utiliser ce que j’ai appris?

Parce que mon temps est limité.

Quand vais-je utiliser ce que j’ai appris?

Dès maintenant. Je n’ai pas l’intention de relire un livre que j’ai déjà lu, du moins pas avant l’année prochaine.

Autres citations pêle-mêle que je n’ai pas pris le temps de classer parce que j’avais hâte de terminer ce review:

C’est rare que je fais ça, mais je me donne un passe-droit pour aujourd’hui. Ça fait trop longtemps que ce livre traîne dans mes pensées. Voici en vrac:

(p. 14) There are two parts to lead time:
- the time it takes to design and validate a product or feature (“fuzzy front end”)
- the time to deliver the feature to customers
- (J’ai l’impression que ceci contredit la définition donnée à la page 159, lead time = the time from code commit to code in a deployable state, et cycle time: the time from code starting to be worked on by development to code in a deployable state.)
(p. 15) Product delivery lead time is the time it takes to go from code committed to code successfully running in production.
(p. 33) Likert-type questions for measuring culture: https://f-l.ca/RTT
(p. 39) In complex adaptative systems, accidents are almost never the fault of a single person who saw clearly what was going to happen and then ran toward it or failed to act to prevent it. Rather, accidents typically emerge from a complex interplay of contributing factors.
(p. 39) Human error should […] be the start of the investigation.
(p. 117) The five characteristics of a transformational leader:
- Vision: A clear understanding of where the organization of where the organization is going and where it should be in five years
- Inspirational communication, in a way that inspires and motivates, even in an uncertain or changing environment
- Intellectual stimulation, challenging followers to think about problems in new ways
- Supportive leadership, demonstrating care and consideration of followers’ personal needs and feelings
- Personal recognition, praising and acknowledging goals and improvements in work quality, personally complimenting others when they do outstanding work.
(p. 118) How to measure transformation leadership: https://f-l.ca/FFH
(p. 192) Enterprise leaders often ask: How do we change our culture? The better questions to ask are: How do we learn how to learn? How do I learn? How can I make it safe for others to learn? How can I learn from others and with them? How do we, together, establish new behaviors and new ways of thinking that build new habits, that cultivate our new culture?
(p. 193) “Let’s try this together. Even if it doesn’t work, we will learn something that will help us to be better. Will you join me in this and see what we can learn?”

Le verdict de Félix:
👍

Schéma intégrateur

📚 Vocabulaire

💡 Nouvelles idées

⭐ Citations étoiles

Foreword by Martin Fowler

(p. xiii) “Confirmation bias is a strong force (although I mostly notice it in others).”

Foreword by Courtney Kissler

(p. xv) Non-functional requirements (NFRs) are features.
(p. xvi) “If I am a senior leader and my team doesn’t feel comfortable sharing risks, then I will never truly know reality. And, if I’m not genuinely curious and only show up when there’s a failure, then I am failing as a senior leader.”

Preface

Part 1: What We Found

Chapter 1: Accelerate

(p. 6) Focus on capabilities, not maturity.
(p. 6) The most innovative companies and highest-performing organizations are always striving to be better and never consider themselves “mature” or “done” with their improvement or transformation journey.
(p. 10) High performers understand that they don’t have to trade speed for stability or vice versa, because by building quality in they get both.

Chapter 2: Measuring Performance

(p. 13) Velocity is a relative and team-dependent measure, not an absolute one. Teams usually have significantly different contexts which render their velocities incommensurable.
(p. 17) Traditionally, reliability is measured as time between failures. However, in modern software products and services, which are rapidly changing complex systems, failure is inevitable, so the key question becomes: How quickly can service be restored?
(p. 27) Change management boards are negatively correlated with tempo and stability.
(p. 27) “In pathological and bureaucratic organizational cultures, measurement is used as a form of control, and people hide information that challenges existing rules, strategies, and power structures. As Deming said, ‘whenever there is fear, you get the wrong numbers.’ " (Humble et al. 2014, p. 56)

Chapter 3: Measuring and Changing Culture

(p. 31) Three characteristics of good information:
- It provides answers to the questions that the receiver needs answered
- It is timely
- It is presented in such a way that it can be effectively used by the receiver
(p. 35) Bureaucracy is not necessarily bad. The goal of bureaucracy is to “ensure fairness by applying rules to administrative behavior. The rules would be the same for all cases—no one would receive preferential or discriminatory treatment.” (Mark Schwartz)
(p. 38) “Who is on a team matters less than how the team members interact, structure their work, and view their contributions.” (Google, 2015) In other words, it all comes down to team dynamics.
(p. 39) “The way to change culture is not to first change how people think, but instead to start by changing how people behave—what they do.” (John Shook, 2010)

Chapter 4: Technical Practices

(p. 52) Unplanned work and reword are useful proxies for quality because they represent a failure to build quality into our products.

Chapter 5: Architecture

(p. 63) “Organizations which design systems […] are constrained to produce designs which are copies of the communication structure of these organizations.” (Melvin Conway, 1968)
(p. 67) What tools or technologies you use is irrelevant if the people who must use them hate using them, or if they don’t achieve the outcomes and enable the behaviors we care about. What is important is enabling teams to make changes to their products or services without depending on other teams or systems.

Chapter 6: Integrating Infosec Into the Delivery Cycle

(p. 70) Infosec experts should contribute to the process of designing applications, attend and provide feedback on demonstrations of the software, and ensure that security features are tested as part of the automated test suite.
(p. 70) Shift from information security teams doing the security reviews themselves to giving the developers the means to build security in.

Chapter 7: Management Practices for Software

(p. 76) Work in progress (WIP) limits on their own do not strongly predict delivery performance. It’s only when they’re combined with the use of visual displays and have a feedback loop from production monitoring tools back to delivery teams or the business that we see a strong effect.
(p. 79) Approval by an external body (such as a manager or CAB) simply doesn’t work to increase the stability of production systems, measured by the time to restore service and change fail rate. However, it certainly slows things down. It is, in fact, worse than having no change approval process at all.

Chapter 8: Product Development

Chapter 9: Making Work Sustainable

(p. 90) ⭐ Where code deployments are most painful, you’ll find the poorest software delivery performance, organizational performance, and culture.
(p. 94) Research shows that stressful jobs can be as bad for physical health as secondhand smoke and obesity.
(p. 95) Six organization risk factors that predict burnout:
- Work overload
- Lack of control
- Insufficient rewards
- Breakdown of community
- Absence of fairness
- Value conflicts
(p. 96) A classic hallmark of burnout is indifference and cynicism, as well as feelings that your work is no longer helpful or effective.
(p. 96) When your work starts negatively impacting your life outside of work, burnout has often set in.
(p. 99) When organizational values and individual values are aligned, the effects of burnout can be lessened and even counteracted.
(p. 99) If the organizational values felt by employees differ from the official values of the organization […], it will be the everyday, lived values that count. If there is a values mismatch […] burnout will be a concern. When there is alignment, employees will thrive.

Chapter 10: Employee Satisfaction, Identity, and Engagement

(p. 109) Job satisfaction depends strongly on having the right tools and resources to do your work.
(p. 113) A study conducted by Anita Woolley and Thomas W. Malone measured group intelligence and found that teams with more women tended to gall above average on the collective intelligence scale.

Chapter 11: Leaders and Managers

(p. 115) Being a leader doesn’t mean you have people reporting to you on an organizational chart—leadership is about inspiring and motivating those around you.
(p. 122) ⭐ Managers […] should delegate more authority to their employees. Knowledge is power, and you should give power to those who have the knowledge.
(p. 124) Building trust between teams is the most important thing you can do, and it must be built over time. Trust is built on kept promises, open communication, and behaving predictably even in stressful situations.

Part II: The research

Chapter 12: The Science Behind This Book

(p. 131) Research falls into two broad classes: primary and secondary research. The key difference between these two types is who collects the data. Secondary research utilizes data that was collected by someone else.

Chapter 13: Introduction to Psychometrics

Chapter 14: Why Use a Survey

(p. 167) Research has shown that organizational culture is predictive of technology and organizational performance, is predictive of performance outcomes, and that team dynamics and psychological safety are the most important aspects in understanding team performance.

Chapter 15: The Data for the Project

Part III: Transformation

Chapter 16: High-Performance Leadership and Management

(p. 192) When you change the way you work, you change the routines, you create a different culture.
(p. 196) It’s not easy to try new things in front of others. Change takes discipline and courage.

Conclusion

(p. 200) You can’t buy or copy high performance. You will need to develop your own capabilities as you pursue a path that fits your particular context and goals. This will take sustained effort, investment, focus, and time.

(Lecture 142) Accelerate