Heuristics for Effective Software Development Organizations: A continuously evolving list.*

  1. Without psychological safety, respect, and trust, none of the following is possible.
  2. The way we work, the work we do, and the organizations within which we work are all part of a connected system. You cannot change anything without changing everything. You cannot improve a system by tinkering with the parts.
  3. Process exists in service of people; the people come first.
  4. The best ways to work are collaborative. Negotiation is not collaboration. Isolated individuals making heroic efforts are never as effective as collaborative groups. We get the best results when customers, business people, and developers literally work together.
  5. Welcome change—in organizations, processes, products, plans—at any time. You cannot be simultaneously rigid and agile.
  6. Outcomes matter more than output. A focus on output yields sub-par outcomes.
  7. Knowledge work has unique concerns, unrelated to those of a factory or construction site.
  8. The most effective organizations are learning organizations. Learning—about both the products we produce and the way we produce them—is continuous. Learning is not just a normal work activity, it is the work.
  9. We continuously improve by observing how we work and fixing any problems we encounter. Improvement is an ongoing, not a periodic, activity. When something goes wrong, we pause and figure out a way to improve our process so the problem can’t happen again. We focus on the system, not the people. Occasionally, we’ll stop and reflect on our work to make proactive improvements.
  10. Simplicity is essential. This rule applies to everything from organizational structure and process to the fine details of the products we develop. We do not waste time building (products or organizations or details) for a future we cannot predict.
  11. Work is transient. We expect to change, or even discard, everything we build, from products to organizations and processes. Everything is an experiment.
  12. We work to make our customer’s lives better and their work easier. We do that by providing a steady stream of artifacts and aid that they find valuable.
  13. We think holistically. We work on complete products, not projects. If you have no projects, you have no need for project management.
  14. At the core of our way of working is continuous and rapid feedback. We make a small change, deliver the result into our customer’s hands, get feedback, then adjust what we do based on that feedback. That cycle is as short as possible—minutes, hours, occasionally a few days—not weeks. This inspect-and-adapt loop applies to both process improvement and product development. The changes we deliver are high quality (e.g. in code: no known defects, production ready, secure, &c.).
  15. Quality is not negotiable. (This rule applies to all aspects of quality, not just testing.)
  16. The best plans are strategic, not tactical.
  17. Predictions are unreliable. Estimates are not promises.
  18. Our only measure of progress is delivering into our customers hands things they find valuable. It’s okay if they change their minds.
  19. Management provides strategic guidance and support only. Tell the teams what you need, trust them to figure out how to execute.
  20. Give people the environment and support they need, then get out of the way. We trust autonomous teams to control the way they work and the environment they work in. Teams are self organizing and self managing. They chose their own tools and methods. We expect them to change both the product and themselves as they deem necessary. If all the teams are working in the same way—using the same process or framework, for example—you have no autonomy.
  21. Autonomy does not mean that the teams do not coordinate with one another and with the larger organization. Alignment around everything from strategic goals to implementation technology is essential.
  22. The best teams are stable. Bring work to the teams; do not form teams to do the work. Fund the teams, not the work.
  23. Teams that depend on other teams cannot respond fast enough, so team members have between them all skills needed to get an idea into our customers hands. Skills overlap, so no single person is essential.
  24. People must start every day refreshed, relaxed, and able to do their best work (and stop when those conditions no longer hold).
  25. Relatedness, autonomy, mastery, and purpose are essential drivers. Rewards and punishments are actively destructive.
  26. Communication is central to effective outcomes. Communication effectiveness improves with the degree of physical proximity and the richness of the communication media. Face to face in real time is best, though not always possible, so we sometimes approximate that as best we can.
  27. Much of the dysfunction in managment comes from fear, which in turn comes from a lack of transparency. Our processes must be as transparent as possible.
* This list is hardly original thinking on my part. It started out as a way to present the values and principles of the Agile Manifesto in a clearer and more contemporary way, though I’ve added a few things. It represents a snapshot of my thinking in a moment in time, not a set of irrefutable truths.

20 Comments

  1. Daniel Hillis on July 25, 2021 at 1:03 am

    Thank you for writing and publishing this!

  2. Alex on July 25, 2021 at 6:33 pm

    Thank you for sharing 🙂

  3. Ron Hitchens on July 25, 2021 at 9:57 pm

    A good distillation of agile thinking.

    I think #17 is the most important for managers to learn.

  4. Jeremy on July 26, 2021 at 12:45 pm

    2 and 9 seem contradictory. You can’t improve a system by tinkering with the parts, yet we continuously tinker with the parts. If your software and processes are properly designed, then you certainly can improve things by tinkering with parts as pieces of your software or parts of your process are properly focused and separate from others.

    4 is true to an extent but when it comes to pair programming, for instance, some people just don’t have the personality for that. They could be stellar developers but have anxiety when pair programming. There’s no good reason to force them into it. They must be able to effectively communicate and participate in group discussions, but I see no reason to force them into collaborative programming. Another example is myself. I do fine pair programming to help teach Juniors and that’s a big part of my management style, having them sit with me to learn processes and how to be more efficient. But when it comes to something I need to hammer out quickly, pair programming does nothing but slow me down. I’ve been writing code for so many decades that by the time I sit down to actually write the code, it’s already all in my head and discussing it as I go just puts a wrench in the works. Not to say I can’t learn anything from others – collaboration is very useful in the design phase and this is where I’d say it’s actually most important. But when it comes time to turn that design into code, collaboration is not always effective.

    Some great highlights organizations should focus on, though:

    – welcome change
    – focus on the system
    – simplicity is essential
    – work is transient
    – everything is an experiment
    – estimates are not promises
    – quality is not negotiable

    If orgs and managers embrace these concepts they will be many times more successful

    • Allen Holub on July 26, 2021 at 3:15 pm

      There’s a lot to unpack in your comment. Starting with tinkering, you cannot improve the ability of a car to transport you from one place to another (it’s primary purpose) by tinkering with the radio or the cigarette lighter. If you change something significant (e.g. increase the power of the engine), you have to also strengthen the drive train, the engine mounts, the cooling system, the brakes. The pieces of a system are never isolated from the other pieces. That’s one of the things that makes it a system. The same applies to individuals and teams that are part of a system. Adding “rock-star” programmers, or improving a single team in isolation, only rarely improves the system as a whole (the one common exception being removing a constraint/bottleneck). Continuous improvement focuses on the system as a whole, not the individual parts, or if we do focus initially on a part, we consider how changing that part impacts the system. I’d suggest reading a few of the books in the “Systems Thinking” section of my reading list.

      It’s true that some people don’t have the personality for working collaboratively. That in no way counters the fact that lone-wolf programmers slow things down, no matter how good they are. They create bottlenecks and dependencies. They tend to concentrate—or in the worst case, hoard—essential information and skills that the team needs. Working alone just takes longer than working collaboratively as a team. A lone wolf can only do the best work that a single person can do, as compared to the best work the entire team can do. Some organizations can nonetheless find work for those people—e.g. independent tasks that do not interact with product development. That’s fine. I’d also look at the incentive systems in your org that encourage people to work alone. Individual performance appraisals and bonuses, for example, actively discourage a collaborative mindset.

      I should also add that the thing you describe is not pair programming. It’s one-on-one teaching. Valuable, of course, but hardly collaborative work. I should also add that I don’t find the notion of a “junior” particularly useful. Everybody contributes, and there is often no correlation between the value of that contribution and the junior/senior status of the individual. One-on-one training of the sort you describe is valuable for everybody, and I think that everybody should be mentoring everybody else (including you) using techniques like that.

  5. Robert Mykland on July 26, 2021 at 4:52 pm

    I love guideline #10. If you make the parts that can be simpler more complicated than they need to be, by the time you get to the complicated parts, everyone is lost.

  6. Wolfgang on July 27, 2021 at 9:10 am

    Great stuff. I’m just struggling with #2. I get the point about many things within a system being connected. I am just not sure it’s all aspects all the time.

    • Allen Holub on July 27, 2021 at 5:25 pm

      Well, give me an example where you’ve changed something in isolation and haven’t had to change other things to get it all to work. Let’s say you manage to get a team to work faster. If there’s downstream “operations,” then that speed does nothing useful because the changes don’t get into anybody’s hands. If you don’t change the product process, then that fast team can’t get enough things to work on. If it then starts working for work’s sake instead of providing value, you’re just wasting money.

      • Sandro on July 27, 2021 at 7:31 pm

        > Well, give me an example where you’ve changed something in isolation and haven’t had to change other things to get it all to work.

        That’s not what #7 says. It specifically says you have to change *everything* if you change *anything*. That’s an overstatement which is just incorrect. You absolutely can improve a system by tinkering with the parts, *if specific parts are the bottlenecks*.

        There are plenty of examples of isolated changes. You streamline checkout for an e-commerce site, but that doesn’t necessarily mean you have to change the order processing backend, or the shipping backend, or customer service.

        If no specific part is a bottleneck, *then* you may have to rethink the architecture which may involve slightly changing everything.

        • Allen Holub on July 27, 2021 at 7:38 pm

          If you streamline the checkout, you probably have to change other pages on the site, modify the financial subsystems, modify the “customer” model, &c to support the streamlining. Sure, there may be truly trivial changes along the lines of changing the cigarette lighter in a car—changing the color of a button, for example. Dwelling on the word everything, however, is a straw man that pretty much invalidates your comment. Hyper-literalism is just trolling.

          You’re also entirely missing the key part of the heuristic, which is that software production is just a piece of a larger organizational system. In order to be able to do that streamlining, you need a system of support to that permits and enables it. You need product thinking, for example, to define what streamlining entails or whether it’s, in fact, worth doing at all. Then there are Conway’s Law issues of the software architecture reflecting the organizational architecture. If the software architecture needs to change as part of that streamlining, the organizational architecture may need to change to support it. There are a lot of moving parts, here.

  7. Ferdinand Steenkamp on July 28, 2021 at 6:25 am

    I find myself referring to this list couple of times a week, very well thought out 🙂

  8. Vjekoslav Grzin on August 6, 2021 at 9:47 am

    Dear Allen,
    Your envolving list about agility in today’s world has been so inspiring,
    I just had to translate your statements in German:

    Heuristiken für eine effektive Softwareentwicklung:
    Eine sich ständig weiterentwickelnde Liste.*
    von Allen Holub | 24. Juli 2021

    1. Ohne psychologische Sicherheit, Respekt und Vertrauen ist nichts von nachfolgenden Dingen möglich.
    2. Der Prozess steht im Dienst der Menschen; die Menschen kommen an erster Stelle.
    3. Die beste Art zu arbeiten ist kollaborativ. Verhandlungen sind keine Zusammenarbeit. Isolierte Individuen, die heldenhafte Anstrengungen unternehmen, sind nie so effektiv wie kollaborative Gruppen. Wir erzielen die besten Ergebnisse, wenn Kunden, Fachleute und Entwickler wirklich zusammenarbeiten.
    4. Begrüßen Sie Veränderungen – in Organisationen, Prozessen, Produkten, Plänen – jederzeit. Sie können nicht gleichzeitig starr und agil sein.
    5. Ergebnisse (Outcomes) sind wichtiger als Arbeitsleistung (Output). Eine Konzentration auf den Output führt zu unterdurchschnittlichen Ergebnissen.
    6. Wissensarbeit beinhaltet einzigartige Aspekte, die nichts mit denen in einer Fabrik oder auf einer Baustelle zu tun haben.
    7. Unsere Arbeitsweise, unsere Arbeit und die Organisationen, in denen wir arbeiten, sind alles Teile eines verbundenen Systems. Man kann nichts einzeln für sich ändern, ohne alles andere mit zu ändern. Man kann ein System nicht dadurch verbessern, indem man nur an den Einzelteilen herumbastelt.
    8. Die effektivsten Organisationen sind lernende Organisationen. Wir lernen kontinuierlich – sowohl über die Produkte, die wir herstellen, als auch über die Art und Weise, wie wir sie herstellen. Lernen ist nicht nur eine gewöhnliche Arbeitstätigkeit, es ist die eigentliche Kernarbeit.
    9. Wir verbessern uns kontinuierlich, indem wir unsere Arbeitsweise beobachten und auftretende Probleme beheben. Verbesserung ist eine fortlaufende, keine periodische Tätigkeit. Wenn etwas schief geht, halten wir inne und finden einen Weg, unseren Prozess so zu verbessern, damit das Problem nicht wieder auftreten kann. Wir konzentrieren uns auf das System, nicht auf die Menschen. Gelegentlich halten wir inne und reflektieren unsere Arbeit, um Verbesserungen im Vorfeld durchzuführen.
    10. Einfachheit ist grundlegend. Diese Regel gilt für alles, von der Organisationsstruktur über den Prozess bis hin zum Code, den wir schreiben. Wir verschwenden keine Zeit damit, (Produkte oder Organisationen) für eine Zukunft zu bauen, die wir nicht vorhersagen können.
    11. Arbeit ist vergänglich. Wir erwarten, dass wir alles, was wir bauen, ändern oder sogar verwerfen, von Produkten bis hin zu Organisationen und Prozessen. Alles ist ein Experiment.
    12. Wir arbeiten daran, das Leben unserer Kunden zu verbessern und ihre Arbeit zu erleichtern. Wir tun dies, indem wir einen stetigen Strom von Ergebnissen und Hilfsmitteln bereitstellen, die sie für wertvoll halten.
    13. Wir denken ganzheitlich. Wir arbeiten an kompletten Produkten, nicht an Projekten. Wenn Sie keine Projekte haben, brauchen Sie auch kein Projektmanagement.
    14. Der Kern unserer Arbeitsweise ist kontinuierliches und schnelles Feedback. Wir nehmen eine kleine Änderung vor, liefern das Ergebnis an unsere Kunden aus, holen Feedback ein und passen dann unser Handeln aufgrund der Rückmeldungen an. Dieser Zyklus ist so kurz wie möglich – Minuten, Stunden, gelegentlich ein paar Tage – nicht Wochen. Dieser Überprüfen-und-Anpassen Kreislauf gilt sowohl für die Prozessverbesserung als auch für die Produktentwicklung. Die von uns gelieferten Anpassungen sind von hoher Qualität (z.B. im Code: ohne bekannten Mängel, produktionsbereit, sicher usw.).
    15. Qualität ist nicht verhandelbar. (Diese Regel gilt für alle Aspekte der Qualität, nicht nur für Tests.)
    16. Die besten Pläne sind strategisch, nicht taktisch.
    17. Vorhersagen sind unzuverlässig. Schätzungen sind keine Versprechen.
    18. Unser einziger Maßstab für den Fortschritt ist es, unseren Kunden Dinge in die Hand zu geben, die sie für wertvoll halten. Es ist in Ordnung, wenn sie ihre Meinung ändern.
    19. Das Management bietet nur strategische Anleitung und Unterstützung. Sagen Sie den Teams, was Sie brauchen, und vertrauen Sie ihnen, dass sie herausfinden, wie sie es hinbekommen.
    20. Geben Sie den Menschen die Umgebung und die Unterstützung, die sie brauchen, und gehen Sie dann aus dem Weg. Wir vertrauen darauf, dass autonome Teams ihre Arbeitsweise und die Umgebung, in der sie arbeiten, steuern. Teams organisieren und verwalten sich selbst. Sie wählen ihre eigenen Werkzeuge und Methoden. Wir erwarten von ihnen, dass sie sowohl das Produkt als auch sich selbst ändern, wenn sie es für notwendig erachten. Wenn alle Teams auf die gleiche Weise arbeiten – zum Beispiel mit dem gleichen Prozess oder Framework – haben Sie keine Autonomie.
    21. Autonomie bedeutet nicht, dass sich die Teams nicht untereinander und mit der größeren Organisation abstimmen. Eine Ausrichtung auf alles, von strategischen Zielen bis hin zu Implementierungstechnologien, ist unerlässlich.
    22. Die besten Teams sind stabil. Bringen Sie die Arbeit zu den Teams; bilden Sie keine Teams, um die Arbeit zu erledigen. Finanzieren Sie die Teams, nicht die Arbeit.
    23. Teams, die von anderen Teams abhängig sind, können nicht schnell genug reagieren, daher verfügen die Teammitglieder über alle Fähigkeiten, die erforderlich sind, um eine Idee an unsere Kunden zu liefern. Die Fähigkeiten überschneiden sich, sodass keine einzelne Person erforderlich ist.
    24. Die Menschen sollen jeden Tag erfrischt und entspannt beginnen und in der Lage sein, ihr Bestes zu geben.
    25. Verbundenheit, Autonomie, Meisterschaft sowie Sinn und Zweck sind wesentliche Triebkräfte. Belohnungen und Bestrafungen sind von sich aus schadhaft und destruktiv.
    26. Kommunikation ist von zentraler Bedeutung für wirksame Ergebnisse. Die Effektivität der Kommunikation verbessert sich mit dem Grad der physischen Nähe und dem Reichtum an Kommunikationsmedien. Von Angesicht zu Angesicht in Echtzeit ist am besten, wenn auch nicht immer möglich, daher nähern wir uns manchmal daran, so gut wir können.

    * Diese Liste beinhaltet kaum eigene Gedanken meinerseits. Es begann damit, die Werte und Prinzipien des agilen Manifests klarer und zeitgemäßer vorzustellen, auch wenn ich ein paar Dinge hinzugefügt habe. Es stellt eine Momentaufnahme meines Denkens zu einem bestimmten Zeitpunkt dar und nicht eine Reihe unwiderlegbarer Wahrheiten.

    • Allen Holub on August 10, 2021 at 7:28 pm

      Thanks so much for translating it! Anybody else want to try other languages?

  9. Jack Chou on August 13, 2021 at 6:53 am

    Hi Allen,
    Regarding to Agility, sometimes it’s really difficult to deliver “rapidly”, and get feedback “rapidly”. it even takes 1~2 months to “signoff” by down stream departments or upper stream “solution architecture” for the dev team to make any moves in most of the orgs I’ve worked for.
    And almost all orgs I’ve workded for kinda of “phorbid” the devs to talk to customers directly, fearing that they’d give inproper promises “facilitaed” by the customers. They appoint BA or PM or PO to talk to customers.
    OMG, but these are some facts I’m living with.

    • Allen Holub on August 13, 2021 at 5:40 pm

      Well, the world is indeed a messed up place . You don’t need to do everything at once, though. Go through the list and pick one that seems do-able, even if remotely, then work on making that real. Then do the next one. Poco a poco se anda lejos.

  10. Nicolas MEREAUX on August 22, 2021 at 7:39 am

    Hello Allen,

    It’s a very helpful and inspiring list of heuristics 🙂
    Please find below a french translation. May I publish this translation also on my website? I’ll put appropriate credits and a link a back to your website.

    Heuristiques pour un développement logiciel efficace : une liste en constante évolution*
    par Allen Holub | 24 juillet 2021

    1. En l’absence de sécurité psychologique, de respect et de confiance, aucun des éléments suivants n’est possible.

    2. Les processus existent pour être au service des individus ; les individus d’abord.

    3. Les meilleures façons de travailler sont collaboratives. Une négociation n’est pas de la collaboration. Des individus isolés qui font des efforts héroïques pour réussir ne sont jamais aussi efficaces que des groupes collaboratifs. Nous obtenons les résultats les meilleurs lorsque les clients, les gens du métier et les développeurs travaillent littéralement ensemble.

    4. Accueillez le changement – au sein des organisations, des processus, des produits, des plans – n’importe quand. Vous ne pouvez pas être simultanément rigide et agile.

    5. Les résultats finaux comptent plus que le volume produit. Être concentré uniquement sur le volume produit conduit à des résultats médiocres.

    6. Le travail intellectuel a des préoccupations qui lui sont propres, qui n’ont rien à voir avec celles d’une usine ou d’un chantier de construction.

    7. La manière dont nous travaillons, le travail que nous faisons, et les organisations au sein desquelles nous travaillons font tous partie d’un système connecté. Vous ne pouvez rien changer sans tout changer. Vous ne pouvez pas améliorer un système en bricolant sur des parties dudit système.

    8. Les organisations les plus efficaces sont des organisations apprenantes. L’apprentissage — à la fois sur les produits que nous produisons et sur la manière dont nous les produisons — est continu. L’apprentissage n’est pas seulement une activité normale dans le cadre du travail, il s’agit de l’essence même du travail.

    9. Nous nous améliorons continuellement par le biais de l’observation de la manière dont nous travaillons et corrigeons les problèmes que nous rencontrons. L’amélioration est une activité continuelle, et non périodique. Lorsque quelque chose se passe mal, nous faisons une pause et nous trouvons une manière d’améliorer notre processus afin que le problème ne se produise pas à nouveau. Le focus est mis sur le système, non sur les individus. Occasionnellement, nous nous arrêterons et réfléchirons sur notre travail pour faire des améliorations proactives.

    10. La simplicité est essentielle. Cette règle s’applique à tout, de la structure organisationnelle et des processus jusqu’au code que nous écrivons. Nous ne perdons pas de temps en construisant (des produits ou des organisations) dans le cadre d’un futur que nous sommes incapable de prédire.

    11. Le travail est transitoire. Nous nous attendons à changer, voire même à rejeter, tout ce que nous avons construit, des produits aux organisations en passant par les processus. Tout n’est qu’expérimentation.

    12. Nous travaillons à rendre meilleure la vie de nos clients et leur travail plus facile. Nous faisons cela en fournissant un flux régulier d’artéfacts et nous faisons de notre mieux pour qu’ils soient utiles.

    13. Nous réfléchissons de manière holistique. Nous visons à réaliser des produits, non à travailler sur des projets. Si vous n’avez pas de projets, vous n’avez pas besoin de gestion de projets.

    14. Au cœur de notre manière de travailler se trouve la boucle de retour d’informations dite de rétroaction. Nous faisons un petit changement, nous livrons le résultat dans les mains de nos clients, nous obtenons un retour d’informations et nous ajustons notre action en sur la base de ce retour d’informations. Ce cycle est aussi court que possible — en minutes, en heures, ou de manière occasionnelle de l’ordre de quelques jours — et non en semaines. Cette boucle d’inspection et d’adaptation s’applique à la fois au processus d’amélioration qu’à celui du développement produit. Les changements que nous livrons sont de grande qualité (par exemple dans le code, il n’y a aucune anomalie connue, il est prêt pour être mis en production, il est sûr, etc.).

    15. La qualité est non négociable (cette règle s’applique à tous les aspects de la qualité, et non simplement lors des tests).

    16. Nos outils viennent épauler, sans gouverner, notre manière de travailler, et ne supplantent en aucune manière les interactions entre les individus. Le mieux c’est de partir des outils les plus simples possibles par rapport aux processus que vous développez (par exemple avec un tableau blanc, des notes repositionnables, des fiches). Une fois que le processus est opérationnel, sélectionnez les outils destinés à améliorer ou à simplifier les processus ou qui rendent le travail plus facile.

    17. Les meilleurs plans sont des plans stratégiques, non des plans tactiques.

    18. Les prédictions ne sont pas fiables. Les estimations ne sont pas des promesses.

    19. Notre seule mesure d’avancement est le fait de livrer entre les mains de nos clients les choses qu’ils trouvent utiles. Il est tout à fait correct qu’ils puissent changer d’avis.

    20. L’encadrement donne uniquement l’orientation stratégique ainsi que son appui. Indiquez aux équipes ce dont vous avez besoin, faites-leur confiance pour trouver comment le mettre en œuvre.

    21. Fournissez aux individus l’environnement et le soutien dont ils ont besoin, puis écartez-vous du chemin. Nous faisons confiance à ces équipes autonomes pour contrôler la manière dont elles travaillent et l’environnement dans lequel elles travaillent. Les équipes sont autoorganisées et autogérées. Elles choisissent leurs propres outils et leurs propres méthodes. Nous attendons de leur part qu’elles changent à la fois le produit ainsi qu’elles-mêmes pour autant qu’elles le jugent nécessaire. Si toutes les équipes travaillent de la même manière — en utilisant le même processus ou le même cadre de travail par exemple — alors vous n’avez pas d’autonomie.

    22. L’autonomie ne signifie pas que les équipes ne se coordonnent pas les unes avec les autres et avec le reste de l’organisation. L’alignement global allant des objectifs stratégiques aux technologies d’implémentation est essentiel.

    23. Les meilleurs équipes sont des équipes stables. Apportez du travail aux équipes ; ne constituez pas à les équipes pour faire le travail. Financez des équipes, pas des travaux.

    24. Des équipes qui dépendent d’autres équipes sont dans l’incapacité de réagir suffisamment vite, donc il est nécessaire que les membres de l’équipe aient toutes les compétences nécessaires pour donner vie à une idée et à la mettre entre les mains des clients. Les compétences des uns et des autres se recoupent, afin que nul ne soit indispensable.

    25. Les personnes doivent pouvoir démarrer chaque nouvelle journée fraîches, disposes et capables de donner le meilleur d’elles-mêmes.

    26. Interactions sociales, autonomie, maîtrise et but sont des motivations essentielles. Les récompenses autant que les sanctions s’avèrent de nature destructrice.

    27. La communication est centrale pour obtenir des résultats efficaces. L’efficacité de la communication s’améliore avec le degré de proximité physique et la richesse du moyen de communication. La communication en face en face en temps réel est ce qu’il y a de mieux, toutefois elle n’est pas toujours possible, donc nous devons, quand nous le pouvons, nous en rapprocher du mieux que nous le pouvons

    * Cette liste résulte d’une réflexion qui m’est complètement personnelle. Elle a vu le jour afin de présenter les valeurs et les principes du Manifeste Agile d’une manière qui se veut plus claire et plus contemporaine même si j’y ai ajouté des petites choses ici ou là. Elle représente un instantané de ma réflexion, et non un ensemble de vérités irréfutables.

  11. Urs on August 25, 2021 at 7:39 am

    Excellent list, thanks a lot for sharing!

  12. Andre Beland on September 6, 2021 at 4:49 am

    Regarding 2, I read somewhere of a sociological experiment where they set up a team. Then, they proceeded to change 1 person at a time until everyone on the team was a different person. In finality, the team dynamics remained the same; the roles remained played by the new individuals mirrored that of their predecessor. FYI. (An argument for “changing everything”.)

  13. Andre Beland on September 6, 2021 at 5:26 am

    Regarding 5, I disagree. You need some things to be rigid (this is the way we do things; e.g. tests/TDD). This enables you (team) to have “automatic reflexes”. Some things (e.g. product, scope, plans) should be very flexible. In high performing teams, “the mechanics” / some processes (not all) are defined. Example: you don’t want an F1 team to forget an Engine in the Europe when racing in Montreal. Rigidity (on the unimportant stuff) gives you confidence to be super-flexible on the important stuff. IMO.

    Regarding 7. Here here! Can we stop comparing conceptualizing abstractions to nailing 2x4s construction!

    8. The worst “learning organizations” are the ones where only the executive team learns. There is a LOT of hubris and spin in this area. Some companies don’t want learning, they want low wages.

    9. See 8! People matter. See #1.

    10. Explode 10: I think more wasted time & effort is allocated to “predicting the future” than we care to admit. And we still cannot predict the future to a useful and pragmatic degree. But organizations want to know the future, yesterday. (Plans are useless; planning is critical. …). Also relates to 17.

    11. How will you align “lean” practices with “Everything is an experiment” ? Accept the paradox? …

    15. Quality is negotiable: product = car. Do you want a RollRoyce, a Ford, or a TukTuk? A bug that a customer is never going to hit is not a problem. A race condition in a drug-administering device or a civil aircraft is a HUGE problem, even if it’s a 1 chance in a 1,000,000. Would you trust this for your wife, daughter or mother? But I agree that Quality is not negotiable to a software engineer in exactly the same way as “double column accounting” is not negotiable to an accountant (“it’s the same number! Why are you doing this?). … same discourse as Uncle Bob…

    18. KPI… we want lots of KPIs… 🙂

    Finally, to answer your question on twitter, you wrote: “think holistically”. “Holistic Agile”. “Agile Holistics” (I don’t know if it can be made plural.)

    I really like your list!

  14. Vic González on September 13, 2021 at 8:04 pm

    1. Sin seguridad psicologica, respeto y confianza, nada de lo siguiente es posible.
    2. La manera en que trabajamos, el trabajo que hacemos, y la organización dentro de la que trabajamos, son todas parte de un sistema conectado. No puedes cambiar nada sin cambiar todo. No puedes mejorar un sistema jugando con sus partes.
    3. Los procesos existen en servicio de las personas. Las personas van primero.
    4. Las mejores maneras de trabajar son collaborativas. La negociación no es collaboración. Los individuos aislados haciendo esfuerzos heróicos nunca son tan efectivos como los grupos colaborativos. Tenemos mejores resultados cuando los clientes, la gente de negocio y los desarrolladores literalmente trabajan juntos.
    5. Le damos la bienvenida a los cambios (en las organizaciones, procesos, productos, planes) en cualquier momento. No se puede ser ágil y rígido al mismo tiempo.
    6. Los Outcomes importan más que los Outputs. Enfocarse en los Outputs genera Outcomes deficientes.
    7. El trabajo basado en conocimiento tiene preocupaciones únicas, que no están relacionadas a las de las fábricas ni la construcción.
    8. Las organizaciones más efectivas son organizaciones centradas en aprender. El aprendizaje (acerca de los productos que producimo y la manera en que los producimos) es continuo. El aprendizaje es no sólo una actividad normal del trabajo, es el trabajo.
    9. Mejoramos continuamente observando como trabajamos y corriegiendo cualquier problema que encontremos. La mejora es una actividad continua, no periódica. Cuando algo va mal, hacemos una pausa y buscamos una manera de mejorar nuestro proceso para que el problema no pase de nuevo. Nos enfocamos en el sistema, no en las personas. Ocasionalmente nos detendremos y reflexionaremos sobre nuestro trabajo para hacer mejoras proactivas.
    10. Las simplicidad es escencial. Esta regla aplica a todo, desde la estructura organizacional y los procesos hasta los detalles finos de los productos que desarrollamos. No gastamos tiempo contruyendo (productos, organizaciones ni detalles) para un futuro que no podemos predecir.
    11. El trabajo es transitorio. Esperamos cambiar, o incluso descartar, todo lo que construimos, desde productos hasta organizaciones y procesos. Todo es un experimento.
    12. Trabajamos para hacer mejor la vida de nuestros clientes y facilitarles su trabajo. Lo hacemos proporcionando un flujo estable de artefactos y ayuda que encuentren valiosos.
    13. Pensamos holisticamente. Trabajamos en productos completos, no proyectos. Si no tienes proyectos, no hay necesidad de administración de proyectos.
    14. En el corazón de nuestra forma de trabajar esta la retroalimentación rápida y continua. Hacemos pequeños cambios, entregamos el resultado en las manos de nuestro cliente, obtenemos retroalimentación, y hacemos ajustes basados en esa retroalimentación. Ese ciclo es tan corto como sea posible (minutos, horas, ocasionalmente algunos dias, pero no semanas). Este ciclo de inspección y adaptación aplica a la mejora de procesos y al desarrollo de productos. Los cambios que entregamos son de alta calidad (ej. en el codigo no hay errores conocidos, producción está lista, etc.).
    15. La calidad no es negociable (aplica a todos los aspectos de la calidad, no solo las pruebas).
    16. Los mejores planes son estratégicos, no tácticos.
    17. Las predicciónes no son fiables. Las estimaciones nos son promesas.
    18. Nuestra única medida de progreso es entrar en manos de nuestros clientes cosas que encuentren valiosas. Esta bien si cambian de parecer.
    19. La administración proporciona solamente guía y apoyo estratégico. Dile a los equipos qué necesitas, confía en que ellos encontrarán como hacerlo.
    20. Dale a las personas el ambiente y soporte que necesitan, después sal del camino. Confiamos en que los equipos autónomos controlan su forma de trabajar y el ambiente en el que trabajan. Los equipos son auto organizados y auto administrados. Ellos eligen sus propias herramientas y métodos. Esperamos que cambien el producto y a ellos mismos conforme se necesite. Si todo el equipo esta trabajando de la misma manera (usando el mismo proceso o marco de trabajo, por ejemplo) no tienes autonomia.
    21. La autonomía no significa que el equipo no se cordina unos con otros o con la organización. La alineación al rededor de todo, desde los objetivos estratégicos hasta la implementación de tecnologia, es escencial.
    22. Los mejores equipos son estables. Trae el trabajo a los equipo, no crees equipos para hacer el trabajo. Financia al equipo, no al trabajo.
    23. Los equipos que dependen de otros equipos no pueden responder lo suficientemente rápido, entonces todos los miembros del equipo tienen entre ellos todas las habilidades necesarias para llevar una idea a las manos de los clientes. Las habilidades se empalman, de modo que ninguna persona es esencial.
    24. Las personas deben iniciar cada dia refrescadas, relajadas y capaces de hacer tu mejor trabajo (y detenerse cuando esas condiciones no se mantienen más).
    25. La relación, la autonomía, la maestría y el propósito son guías escenciales. Las recompensas y los castigos son activamente destructivos.
    26. La comunicación es central para obtener resultados efectivos. La efectividad de la comunicacion mejora segun el grado de proximidad física y el enriquecimiento del medio de comunicación. La comunicación cara a cara en tiempo real es la mejor, aunque no siempre es posible, entonces buscaremos aproximarnos lo mejor que modamos.
    27- Mucha de las disfunción en la administración viene del miedo, que a su vez viene de la falta de transparencia. Nuestros procesos deben ser tan trasparentes como sea posible.

    Esta lista no es un pensamiento original mio. Comenzó como una forma de presnetar los valores y principios del Manifiesto ágil de una manera más clara y contemporanea, aunque he agregado algunas cosas. Representa una foto de mi pensamiento en un momento del tiempo, no un conjunto de verdades irrefutables.

    I have read it three times and it keeps inspiring me.

Leave a Comment