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. Processes not developed by the people who use them rarely work well, if at all.
  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.

21 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.

  15. Mik Seljamaa on October 31, 2021 at 8:02 am

    While I find it slightly weird to translate delivery I thought I could try these important wisdoms into Estonian.

    Efektiivne kohaletoimetamine ettevõtetes.

    KullatĂĽkid

    1. Ilma turvatunde, austuse ja usalduseta ei ole alljärgnev võimalik.
    2. See kuidas me töötame, see töö mida me teeme, ja ettevõtted milledes me töötame on kõik üheks osaks ühest ühendatud süsteemist. Ei saa muuta midagi kui sa kõike ei muuda. Sa ei saa muuta süsteemi selle osadega nokitsedes.
    3. Protsess on selleks et inimesi teenida, inimesed on peamised. Harva, kul ĂĽldse, toimivad protsessid mida pole arendanud inimesed kes neid kasutavad.
    4. Parimad tööviisid on koostööpõhised. Kauplemine ja läbirääkimine ei ole koostöö. Eraldatud indiviidid kes loovad kangelastegusid pole kunagi nii efektiivsed kui koostöös olevad rühmad. Me saavutame parimaid tulemusi kui arendajad otseselt koos töötavad.
    5. Valmisolek muutusteks – ettevõttes, protsessides, toodetes ja plaanides – mis iganes ajal. Sa ei saa olla samal ajal nii jäik kui ka agiilne.
    6. Tulemused on olulisemad koi tulem. Keskendumine tulemile toob kaasa kehvad tulemused.
    7. Teabetöös on ainulaadsed vajadused, mis ei sarnane tehase või ehitusplatsiga.
    8. Kõige efektiivsemad ettevõtted on õppivad ettevõtted. Ă•ppimine on pidev – nii toodetud toodetest kui ka viisidest mida me kasutame. Ă•ppimine ei ole vaid normaalne see ongi töö.
    9. Me areneme pidevalt jälgides kuidas me töötame ja parandades iga probleemi mida kohtame. Parandused on pidevad mitte perioodilised tegevused. Kui miski viltu veab siis teeme pausi ja püüame leida viisi oma protsessi parendada niisugusel viisil, et see ei juhtuks taas. Me keskendume süsteemile mitte inimestele. Vahest teeme peatusi ja mõtleme oma töö peale, et teha ennetavaid parandusi.
    10. Lihtsus on oluline. See reegel on rakendatav kõige kohta, ettevõtte struktuuri, ja protsessi, ja ka tootearenduse pisiasjadeni välja. Me ei raiska aega luues (tooteid või ettevõtteid või pisiasju) tuelviku jaoks, mida me ei suuda ennustada.
    11. Töö on mööduv. Me arvestame, et tuleb muuta, või isegi kõik loodu hüljata, toodetest, organisatsioonideni ja protsessideni. Kõik on eksperiment.
    12. Me töötame selleks, et teha oma klientide elud paremaks või nende tööd kergemaks. Teeme seda luues pideva voo asju ja abivahendeid mida kliendid väärtuslikeks peaks.
    13. Me mõtleme terviku peale, holistiliselt. Me töötame terviktoodete kallal, mitte projektide peal. Kui sul pole projekti siis pole vaja ka projektijuhtimist.
    14. Meie mõtteviisi peaosa on pidev ja kiire tagasiside. Teeme väikese muutuse, toimetame tulemuse kliendi kätte, saame tagasisidet ja siis kohandame selle tagasiside põhjal seda mida me teeme. See vaatle-ja-muuda tsükkel rakendub nii protsesside parandamise juures, kui ka tootearenduses. Muutused mida me pakume on kõrge kvaliteediga. (Näiteks: Koodi osas: teada olevate defektid puuduvad, tootmisvalmidus saavutatud, toode on turvaline jne.)
    15. Kvaliteet ei ole läbirääkimise või kauplemise küsimus ( See käib iga kvaliteedi osa kohta mitte ainult testimise kohta.)
    16. Parimad plaanid on strateegilise mitte taktilised.
    17. Ennustused on ettearvamatud. Arvestused ei ole lubadused.
    18. Meie ainus progressi mõõdupuu on toimetada kliendi kätte midagi mis on talle väärtuslik. See sobib ka meile kui nad oma meelt muudavad.
    19. Juhtimine võimaldab ainult strateegilist juhtimist ja tuge. Ütle tiimile mida vaja on ning usalda, et nad lahendavad selle kuidas käima panna.
    20. Anna inimestele keskkond ja tugi mida nad vajavad ja siis kao eest. Me usaldame, et autonoomsed tiimid juhivad ise oma tööd ja keskkonda milles nad töötavad. Tiimid on ise organiseeruvad ja isejuhtivad. Nad valivad ise oma tööriistad ja meetodid. Me usaldame et nad muudavad nii toodet kui ka iseennast kui selleks vajadus on. Kui kõik töötavad samal viisil, kasutades seda sama protsessi või näiteks raamistikku, siis pole mingit autonoomiat.
    21. Autonoomia ei tähenda et tiimid ei juhindu üksteise suundadest ja suuremast plaanist. Ühised jooned, igas asjas, on vajalikud strateegilistes eesmärkides ja tehnoloogiate rakendamisel.
    22. Parimad tiimid on stabiilsed: Too tööd tiimile ära tee tiime selleks et töö ette võtta. Rahasta tiime mitte tööd.
    23. Tiimid mis olenevad teistest tiimidest ei suuda liikuda piisavalt kiiresti seega tiimi liikmetel on kõik oskused mida on vaja et idee jõuaks asjani kliendi käes. Oskused kattuvad — nõnda ei ole üksikisik oluline.
    24. Inimesed peavad saama päeva alustada värske, puhanuna ja võimelisena parimat panust andma ning peatuma siis kui need tingimused pole täidetud.
    25. Suhted, autonoomia, võimekus ja siht on olulised suunised. Auhinnad ja karistused toimivad hävitavana.
    26. Suhtlemine on keskne efektiivse tulemuse saavutamiseks. Suhtlemise efektiivsus paraneb seoses füüsilise läheduse tasemega ja suhtlusmeediumi rikkalikusega. Näost näkku päriselus on parim, kuid mitte alati võimalik, seega vahest me leiame sarnaseid lahendusi nii hästi kui saame.
    27. Suur osa juhtimisdüsfunktsionaalsusest tuleb hirmust ja see tuleb omakorda läbipaistvuse puudumisest. Meie protsessid peavad olema nii läbipaistvad kui võimalik.

Leave a Comment