Without psychological safety, respect, and trust, none of the following is possible.
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.
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.
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.
Welcome change—in organizations, processes, products, plans—at any time. You cannot be simultaneously rigid and agile.
Outcomes matter more than output. A focus on output yields sub-par outcomes.
Knowledge work has unique concerns, unrelated to those of a factory or construction site.
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.
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.
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.
Work is transient. We expect to change, or even discard, everything we build, from products to organizations and processes. Everything is an experiment.
We work to make our customers’ lives better and their work easier. We do that by providing a steady stream of artifacts and aid that they find valuable. Our user/customers “drive” that process, but that means that you communicate often, watch them work, understand their problems, and collaborate on solutions. It doesn’t mean that you mindlessly do what you’re told.
We think holistically. We work on complete products, not projects. If you have no projects,
you have no need for project management.
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.).
Quality is not negotiable. (This rule applies to all aspects of quality, not just testing.)
The best plans are strategic, not tactical.
Predictions are unreliable. Estimates are not promises.
Our only measure of progress is delivering into our customers’ hands things they find valuable. It’s okay if they change their minds.
Management provides strategic guidance and support only. Tell the teams what you need, and trust them to figure out how to execute. Do not collect data and make decisions. Instead, sit down with the teams and help them make decisions.
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 choose 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.
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.
The best teams are stable, but self-selecting. Bring work to the teams; do not form teams to do the work. Fund the teams, not the work. Teams recreate themselves as necessary.
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.
People must start every day refreshed, relaxed, and able to do their best work (and stop when those conditions no longer hold).
Relatedness, autonomy, mastery, and purpose are essential drivers. Rewards and punishments are actively destructive.
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.
Much of the dysfunction in management 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.
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
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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”.)
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.)
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.
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.
Here is an attempt at the Finnish language, doing my best to convey the message:
1. Ilman psykologista turvallisuutta, kunnioitusta ja luottamusta mikään seuraavista ei ole mahdollista.
2. Tapamme tehdä töitä, tekemämme työ ja organisaatiot joissa teemme töitä muodostavat toisiinsa liittyvän järjestelmän. Järjestelmää ei voi parantaa näpertelemällä sen osien parissa.
3. Prosessi on ihmisten palveluksessa; ihmiset ovat etusijalla. Prosessit joita eivät ole suunnitelleet niitä käyttävät ihmiset toimivat harvoin hyvin, jos ollenkaan.
4. Parhaat tavat tehdä töitä perustuvat yhteistyöhön. Neuvottelu ei ole yhteistyötä. Eristäytyneet yksilöt, jotka tekevät sankarillisia ponnistuksia, eivät ole koskaan yhtä tehokkaita kun yhteistyötä tekevät ryhmät. Saavutamme parhaat tulokset kun asiakkaat, liiketoiminnan edustajat ja kehittäjät työskentelevät kirjaimellisesti yhdessä.
5. Toivotamme milloin tahansa muutoksen tervetulleeksi organisaatioissa, prosesseissa, tuotteissa ja suunnitelmissa. Ei ole mahdollista olla jäykkä ja ketterä samaan aikaan.
6. Tulokset merkitsevät tuotoksia enemmän. Keskittymällä tuotoksiin saavutetaan ala-arvoisia tuloksia.
7. Tietotyössä on ainulaatuisia huolenaiheita, jotka ovat erilaisia kuin tehtaan tai rakennustyömaan huolenaiheet.
8. Oppivat organisaatiot ovat tehokkaimpia organisaatioita. Oppiminen sekä tuottamistamme tuotteista että tavastamme tuottaa niitä on jatkuvaa. Oppiminen ei ole vain osa normaalia työtä, työ itsessään on oppimista.
9. Kehitämme jatkuvasti toimintaamme tarkkailemalla tapaamme tehdä työtä ja korjaamalla kohtaamiamme ongelmia. Parantaminen tapahtuu jatkuvasti, ei määräajoin. Kun jokin menee pieleen, pysähdymme keksimään tavan parantaa prosessiamme, jotta ongelma ei toistu. Keskitymme järjestelmään, emme ihmisiin. Joskus pysähdymme ja pohdimme työtämme tehdäksemme ennakoivia parannuksia.
10. Yksinkertaisuus on välttämätöntä. Tämä sääntö koskee kaikkea organisaatiorakenteesta ja prosesseista kehittämiemme tuotteiden pieniin yksityiskohtiin. Emme tuhlaa aikaa rakentamalla (tuotteita, organisaatioita tai yksityiskohtia) tulevaisuutta varten, jota emme voi ennustaa.
11. Työ on tilapäistä. Odotamme muuttavamme tai jopa hylkäävämme kaiken rakentamamme, tuotteista organisaatioihin ja prosesseihin. Kaikki on kokeilua.
12. Pyrimme tekemään asiakkaidemme elämästä parempaa ja helpottamaan heidän työtään. Teemme sen tarjoamalla tasaisen virran luomuksia ja apua, joita he pitävät arvokkaana.
13. Ajattelemme kokonaisvaltaisesti. Työskentelemme kokonaisten tuotteiden, emme projektien parissa. Kun ei ole projekteja, ei ole tarvetta projektinhallintaan.
14. Toimintamme ytimessä on jatkuva ja nopea palaute. Teemme pienen muutoksen, toimitamme tuloksen asiakkaidemme käsiin, saamme palautetta ja muokkaamme toimintaamme palautteen perusteella. Tämä sykli on mahdollisimman lyhyt – minuutteja, tunteja, joskus muutama päivä – ei viikkoja. Tämä palautesilmukka koskee sekä prosessien parantamista että tuotekehitystä. Toimittamamme muutokset ovat korkealaatuisia (ei tunnettuja vikoja, tuotantovalmis, turvallinen jne.).
15. Laatu ei ole neuvoteltavissa. (Tämä sääntö koskee kaikkia laatunäkökohtia, ei vain testausta).
16. Parhaat suunnitelmat ovat strategisia, eivät taktisia.
17. Ennusteet eivät ole luotettavia. Arviot eivät ole lupauksia.
18. Ainoa edistymisen mittarimme on toimittaa asiakkaillemme asioita, joita he pitävät arvokkaina. Ei haittaa, jos he muuttavat mielensä.
19. Johto tarjoaa ainoastaan strategista ohjausta ja tukea. Kerro tiimeille, mitä tarvitset, ja luota että he selvittävät miten suoriutua.
20. Anna ihmisille heidän tarvitsemansa ympäristö ja tuki, sitten poistu tieltä. Annamme itsenäisille tiimeille luottamuksen hallita työskentelytapaansa ja työympäristöään. Tiimit ovat itseorganisoituvia ja itseohjautuvia. He valitsevat itse työkalunsa ja menetelmänsä. Odotamme heidän muuttavan sekä tuotetta että itseään tarpeelliseksi katsomallaan tavalla. Jos kaikki tiimit työskentelevät samalla tavalla – käyttämällä esimerkiksi samaa prosessia tai kehystä – ei ole itsenäisyyttä.
21. Autonomia ei tarkoita sitä, etteivätkö tiimit koordinoisi keskenään ja suuremman organisaation kanssa. Kaiken kohdistaminen strategisista tavoitteista toteutusteknologiaan on välttämätöntä.
22. Parhaat tiimit ovat vakaita. Tuo työ tiimeihin; älä muodosta tiimejä tekemään työtä. Rahoita tiimejä, elä työtä.
23. Toisista tiimeistä riippuvaiset tiimit eivät pysty reagoimaan tarpeeksi nopeasti, joten tiimin jäsenillä on keskenään kaikki taidot, joita tarvitaan idean saamiseen asiakkaidemme käsiin. Taidot menevät päällekkäin, joten yksittäinen henkilö ei ole välttämätön.
24. Ihmisten on aloitettava jokainen päivä virkeänä, rentoutuneena ja pystyttävä tekemään parhaansa (ja lopetettava, kun nämä ehdot eivät enää päade).
25. Yhteenkuuluvuus, autonomia, pätevyyden kokemus ja merkityksellisyys ovat tärkeitä tekijöitä. Palkinnot ja rangaistukset ovat aktiivisesti tuhoavia.
26. Viestintä on keskeistä tehokkaiden tulosten kannalta. Viestinnän tehokkuus paranee fyysisen läheisyyden ja viestintävälineiden rikkauden myötä. Reaaliaikainen kasvokkain tapahtuva viestintä on parasta, joskaan ei aina mahdollista, joten joskus pyrimme pääsemään mahdollisimman lähelle sitä.
27. Suuri osa johtamisen toimintahäiriöistä johtuu pelosta, joka puolestaan johtuu avoimuuden puutteesta. Prosessien tulee olla mahdollisimman läpinäkyviä.
2. Tapamme tehdä töitä, tekemämme työ ja organisaatiot joissa teemme töitä muodostavat toisiinsa liittyvän järjestelmän. Mitään ei voi muuttaa muuttamatta kaikkea. Järjestelmää ei voi parantaa näpertelemällä sen osien parissa.
Zonder psychologische veiligheid, respect en vertrouwen, is geen van de onderstaande punten mogelijk.
De manier waarop we werken, het werk wat we doen en de organisaties waarin we werken zijn allemaal verbonden met elkaar. Je kan niets veranderen zonder de rest ook te veranderen. Je kan een systeem niet verbeteren door te sleutelen aan een onderdeel.
Processen bestaan om mensen te dienen; mensen komen eerst. Processen die niet door hun gebruikers ontwikkeld zijn werken zelden, als ze uberhaupt werken.
The beste werkvormen zijn collaboratief. Onderhandeling is niet samenwerken. Geïsoleerde individuen die heroische inspanningen verrichten zijn nooit zo effectief als groepen die samenwerken.
Het beste resultaat komt als klanten, mensen uit de business en ontwikkelaars letterlijk samen werken.
Verwelkom verandering–in organisaties, processen, producten, plannen–op elk moment.
Je kan niet tegelijkertijd star en agile zijn.
Resultaten zijn belangrijker dan opbrengst. Een focus op opbrengst geeft suboptimale resultaten.
Kenniswerk heeft unieke aspecten, die ongerelateerd aan die van een fabriek of bouwplaats.
De meeste effectieve organisaties zijn lerende organisaties. Leren–over zowel de producten die we maken en de manier waarop we ze maken–is doorlopend.
Leren is niet slechts een onderdeel van het werk, het is het werk.
We verbeteren continu door hoe we werken te observeren en problemen die we tegenkomen op te lossen. Als iets mis gaat, stoppen we en bedenken een manier om ons proces te verbeteren zodat het probleem niet nog een keer kan optreden. We focussen op het systeem, niet op de mensen.
Sporadisch stoppen we en reflecteren op ons werk om proactief verbeteringen te maken.
Simpliciteit is essentieel. Deze regel is van toepassing op alles van organisatie structuur en proces, tot in de fijnste details van het product dat we ontwikkelen. We verspillen geen tijd met het bouwen (van producten of organisaties of details) voor een toekomst die we niet kunnen voorspellen.
Werk is vergankelijk. We verwachten alles wat we bouwen te moeten aanpassen of weggooien. Van producten tot organisaties en processen. Alles is een experiment.
We werken om het leven van onze klanten beter te maken en hun werk makkelijker te maken. We doen dat door een constante stroom van artefacten en hulpmiddelen te maken die onze klant waardevol vindt.
We denken holistisch. We werken aan complete producten, niet aan projecten. Als je geen projecten hebt, heb je ook geen project management nodig.
De kern van onze werkwijze is continue en snelle feedback. We maken een kleine wijziging, leveren het resultaat aan de klant, krijgen feedback en passen wat we doen aan op basis van die feedback. Die cyclus is zo kort mogelijk–minuten, uren, soms een paar dagen–geen weken. Deze inspect-and-adapt cyclus is van toepassing op zowel procesverbetering als productontwikkeling. De veranderingen die we opleveren zijn van hoge kwaliteit (bijvoorbeeld in code: geen bekende defecten, klaar voor productie, veilig, etc.).
Kwaliteit staat niet ter discussie. (Deze regel gaat over alle aspecten van kwaliteit, niet alleen het testen.)
De beste plannen zijn strategisch, niet tactisch.
Voorspellingen zijn onbetrouwbaar. Schattingen zijn geen beloften.
Onze enige indicatie van voortgang is het leveren van dingen die onze klant waardevol vindt. Het is prima als ze daarover hun mening bijstellen.
Management levert alleen strategische begeleiding en support. Vertel de teams wat je nodig hebt en vertrouw ze om zelf uit te zoeken hoe ze dat realiseren.
Geef mensen de omgeving en support die ze nodig hebben en doe dan een stap terug. We vertrouwen autonome teams om de manier waarop ze werken en de omgeving waarin ze werken in te richten. Teams zijn zelforganiserend en zelfsturend. Ze kiezen hun eigen gereedschap en methoden. We verwachten dat ze het product en zichzelf aanpassen indien noodzakelijk. Als alle teams op dezelfde manier werken–met bijvoorbeeld hetzelfde proces of raamwerk–hebben ze geen autonomie.
Autonomie betekent niet dat de teams niet coordineren met elkaar en de rest van de organisatie. Het is essentieel dat we het eens zijn over alles van strategische doelen tot de gebruiken technologie voor implementatie.
De teams zijn stabiel. Geef werk aan de teams; vorm geen teams om het werk te doen. Betaal de teams, niet het werk.
Teams die afhankelijk zijn van andere teams kunnen niet snel genoeg reageren, dus een team moet alle vaardigheden bevatten om een idee in handen van de klant te krijgen. Vaardigheden overlappen, zodat geen enkel persoon essentieel is.
Mensen moeten elke dag fris, ontspannen en op hun best te zijn (en stop als dat niet langer het geval is).
Betrokkenheid, autonomie, meesterschap en doelmatigheid zijn essentiële drijfveren. Beloningen en straffen zijn destructief.
Communicatie is de kern van effectieve resultaten. Effectieve communicatie verbetert met het fysiek bij elkaar zijn en de rijkheid van je communicatie medium. Face to face is het beste, maar niet altijd mogelijk, dus we proberen dat zo goed mogelijk te benaderen.
Veel van de disfunctie in management komt voort uit angst, wat op zijn beurt voort komt uit een gebrek aan transparantie. Onze processen moeten zo transparant mogelijk zijn.
Every one of the 21 heuristics is an article in and of itself. A book can be written describing these 21 heuristics with case studies and examples. These are hard earned lessons from Author which needs more explanation.
For example Rule 3: People over processes. Perhaps the author was frustrated when processes were preferred over people which lead to failure.
27, but sure . They are just simple rules of thumb, so they all need detailed explanation. I have a class that covers that (which I’m happy to teach in house). I’m working on a book.
I mean I disagree with the in person part. But that’s just a nitpick. Because 1 and 24 are absolutely essential for day-to-day performance, and most ignored.
I just love it Allen, so well phrased and captures the essence of how sw development should be done. The only downside is when you see this in practice once it is impossible to go back and do what 99% of tech companies do
Thank you for writing and publishing this!
Thank you for sharing 🙂
A good distillation of agile thinking.
I think #17 is the most important for managers to learn.
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
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.
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.
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.
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.
> 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.
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.
I find myself referring to this list couple of times a week, very well thought out 🙂
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.
Thanks so much for translating it! Anybody else want to try other languages?
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.
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.
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.
Excellent list, thanks a lot for sharing!
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”.)
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!
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.
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.
Here is an attempt at the Finnish language, doing my best to convey the message:
1. Ilman psykologista turvallisuutta, kunnioitusta ja luottamusta mikään seuraavista ei ole mahdollista.
2. Tapamme tehdä töitä, tekemämme työ ja organisaatiot joissa teemme töitä muodostavat toisiinsa liittyvän järjestelmän. Järjestelmää ei voi parantaa näpertelemällä sen osien parissa.
3. Prosessi on ihmisten palveluksessa; ihmiset ovat etusijalla. Prosessit joita eivät ole suunnitelleet niitä käyttävät ihmiset toimivat harvoin hyvin, jos ollenkaan.
4. Parhaat tavat tehdä töitä perustuvat yhteistyöhön. Neuvottelu ei ole yhteistyötä. Eristäytyneet yksilöt, jotka tekevät sankarillisia ponnistuksia, eivät ole koskaan yhtä tehokkaita kun yhteistyötä tekevät ryhmät. Saavutamme parhaat tulokset kun asiakkaat, liiketoiminnan edustajat ja kehittäjät työskentelevät kirjaimellisesti yhdessä.
5. Toivotamme milloin tahansa muutoksen tervetulleeksi organisaatioissa, prosesseissa, tuotteissa ja suunnitelmissa. Ei ole mahdollista olla jäykkä ja ketterä samaan aikaan.
6. Tulokset merkitsevät tuotoksia enemmän. Keskittymällä tuotoksiin saavutetaan ala-arvoisia tuloksia.
7. Tietotyössä on ainulaatuisia huolenaiheita, jotka ovat erilaisia kuin tehtaan tai rakennustyömaan huolenaiheet.
8. Oppivat organisaatiot ovat tehokkaimpia organisaatioita. Oppiminen sekä tuottamistamme tuotteista että tavastamme tuottaa niitä on jatkuvaa. Oppiminen ei ole vain osa normaalia työtä, työ itsessään on oppimista.
9. Kehitämme jatkuvasti toimintaamme tarkkailemalla tapaamme tehdä työtä ja korjaamalla kohtaamiamme ongelmia. Parantaminen tapahtuu jatkuvasti, ei määräajoin. Kun jokin menee pieleen, pysähdymme keksimään tavan parantaa prosessiamme, jotta ongelma ei toistu. Keskitymme järjestelmään, emme ihmisiin. Joskus pysähdymme ja pohdimme työtämme tehdäksemme ennakoivia parannuksia.
10. Yksinkertaisuus on välttämätöntä. Tämä sääntö koskee kaikkea organisaatiorakenteesta ja prosesseista kehittämiemme tuotteiden pieniin yksityiskohtiin. Emme tuhlaa aikaa rakentamalla (tuotteita, organisaatioita tai yksityiskohtia) tulevaisuutta varten, jota emme voi ennustaa.
11. Työ on tilapäistä. Odotamme muuttavamme tai jopa hylkäävämme kaiken rakentamamme, tuotteista organisaatioihin ja prosesseihin. Kaikki on kokeilua.
12. Pyrimme tekemään asiakkaidemme elämästä parempaa ja helpottamaan heidän työtään. Teemme sen tarjoamalla tasaisen virran luomuksia ja apua, joita he pitävät arvokkaana.
13. Ajattelemme kokonaisvaltaisesti. Työskentelemme kokonaisten tuotteiden, emme projektien parissa. Kun ei ole projekteja, ei ole tarvetta projektinhallintaan.
14. Toimintamme ytimessä on jatkuva ja nopea palaute. Teemme pienen muutoksen, toimitamme tuloksen asiakkaidemme käsiin, saamme palautetta ja muokkaamme toimintaamme palautteen perusteella. Tämä sykli on mahdollisimman lyhyt – minuutteja, tunteja, joskus muutama päivä – ei viikkoja. Tämä palautesilmukka koskee sekä prosessien parantamista että tuotekehitystä. Toimittamamme muutokset ovat korkealaatuisia (ei tunnettuja vikoja, tuotantovalmis, turvallinen jne.).
15. Laatu ei ole neuvoteltavissa. (Tämä sääntö koskee kaikkia laatunäkökohtia, ei vain testausta).
16. Parhaat suunnitelmat ovat strategisia, eivät taktisia.
17. Ennusteet eivät ole luotettavia. Arviot eivät ole lupauksia.
18. Ainoa edistymisen mittarimme on toimittaa asiakkaillemme asioita, joita he pitävät arvokkaina. Ei haittaa, jos he muuttavat mielensä.
19. Johto tarjoaa ainoastaan strategista ohjausta ja tukea. Kerro tiimeille, mitä tarvitset, ja luota että he selvittävät miten suoriutua.
20. Anna ihmisille heidän tarvitsemansa ympäristö ja tuki, sitten poistu tieltä. Annamme itsenäisille tiimeille luottamuksen hallita työskentelytapaansa ja työympäristöään. Tiimit ovat itseorganisoituvia ja itseohjautuvia. He valitsevat itse työkalunsa ja menetelmänsä. Odotamme heidän muuttavan sekä tuotetta että itseään tarpeelliseksi katsomallaan tavalla. Jos kaikki tiimit työskentelevät samalla tavalla – käyttämällä esimerkiksi samaa prosessia tai kehystä – ei ole itsenäisyyttä.
21. Autonomia ei tarkoita sitä, etteivätkö tiimit koordinoisi keskenään ja suuremman organisaation kanssa. Kaiken kohdistaminen strategisista tavoitteista toteutusteknologiaan on välttämätöntä.
22. Parhaat tiimit ovat vakaita. Tuo työ tiimeihin; älä muodosta tiimejä tekemään työtä. Rahoita tiimejä, elä työtä.
23. Toisista tiimeistä riippuvaiset tiimit eivät pysty reagoimaan tarpeeksi nopeasti, joten tiimin jäsenillä on keskenään kaikki taidot, joita tarvitaan idean saamiseen asiakkaidemme käsiin. Taidot menevät päällekkäin, joten yksittäinen henkilö ei ole välttämätön.
24. Ihmisten on aloitettava jokainen päivä virkeänä, rentoutuneena ja pystyttävä tekemään parhaansa (ja lopetettava, kun nämä ehdot eivät enää päade).
25. Yhteenkuuluvuus, autonomia, pätevyyden kokemus ja merkityksellisyys ovat tärkeitä tekijöitä. Palkinnot ja rangaistukset ovat aktiivisesti tuhoavia.
26. Viestintä on keskeistä tehokkaiden tulosten kannalta. Viestinnän tehokkuus paranee fyysisen läheisyyden ja viestintävälineiden rikkauden myötä. Reaaliaikainen kasvokkain tapahtuva viestintä on parasta, joskaan ei aina mahdollista, joten joskus pyrimme pääsemään mahdollisimman lähelle sitä.
27. Suuri osa johtamisen toimintahäiriöistä johtuu pelosta, joka puolestaan johtuu avoimuuden puutteesta. Prosessien tulee olla mahdollisimman läpinäkyviä.
Small mistake in bullet number 2:
2. Tapamme tehdä töitä, tekemämme työ ja organisaatiot joissa teemme töitä muodostavat toisiinsa liittyvän järjestelmän. Mitään ei voi muuttaa muuttamatta kaikkea. Järjestelmää ei voi parantaa näpertelemällä sen osien parissa.
Made a Dutch translation:
Zonder psychologische veiligheid, respect en vertrouwen, is geen van de onderstaande punten mogelijk.
De manier waarop we werken, het werk wat we doen en de organisaties waarin we werken zijn allemaal verbonden met elkaar. Je kan niets veranderen zonder de rest ook te veranderen. Je kan een systeem niet verbeteren door te sleutelen aan een onderdeel.
Processen bestaan om mensen te dienen; mensen komen eerst. Processen die niet door hun gebruikers ontwikkeld zijn werken zelden, als ze uberhaupt werken.
The beste werkvormen zijn collaboratief. Onderhandeling is niet samenwerken. Geïsoleerde individuen die heroische inspanningen verrichten zijn nooit zo effectief als groepen die samenwerken.
Het beste resultaat komt als klanten, mensen uit de business en ontwikkelaars letterlijk samen werken.
Verwelkom verandering–in organisaties, processen, producten, plannen–op elk moment.
Je kan niet tegelijkertijd star en agile zijn.
Resultaten zijn belangrijker dan opbrengst. Een focus op opbrengst geeft suboptimale resultaten.
Kenniswerk heeft unieke aspecten, die ongerelateerd aan die van een fabriek of bouwplaats.
De meeste effectieve organisaties zijn lerende organisaties. Leren–over zowel de producten die we maken en de manier waarop we ze maken–is doorlopend.
Leren is niet slechts een onderdeel van het werk, het is het werk.
We verbeteren continu door hoe we werken te observeren en problemen die we tegenkomen op te lossen. Als iets mis gaat, stoppen we en bedenken een manier om ons proces te verbeteren zodat het probleem niet nog een keer kan optreden. We focussen op het systeem, niet op de mensen.
Sporadisch stoppen we en reflecteren op ons werk om proactief verbeteringen te maken.
Simpliciteit is essentieel. Deze regel is van toepassing op alles van organisatie structuur en proces, tot in de fijnste details van het product dat we ontwikkelen. We verspillen geen tijd met het bouwen (van producten of organisaties of details) voor een toekomst die we niet kunnen voorspellen.
Werk is vergankelijk. We verwachten alles wat we bouwen te moeten aanpassen of weggooien. Van producten tot organisaties en processen. Alles is een experiment.
We werken om het leven van onze klanten beter te maken en hun werk makkelijker te maken. We doen dat door een constante stroom van artefacten en hulpmiddelen te maken die onze klant waardevol vindt.
We denken holistisch. We werken aan complete producten, niet aan projecten. Als je geen projecten hebt, heb je ook geen project management nodig.
De kern van onze werkwijze is continue en snelle feedback. We maken een kleine wijziging, leveren het resultaat aan de klant, krijgen feedback en passen wat we doen aan op basis van die feedback. Die cyclus is zo kort mogelijk–minuten, uren, soms een paar dagen–geen weken. Deze inspect-and-adapt cyclus is van toepassing op zowel procesverbetering als productontwikkeling. De veranderingen die we opleveren zijn van hoge kwaliteit (bijvoorbeeld in code: geen bekende defecten, klaar voor productie, veilig, etc.).
Kwaliteit staat niet ter discussie. (Deze regel gaat over alle aspecten van kwaliteit, niet alleen het testen.)
De beste plannen zijn strategisch, niet tactisch.
Voorspellingen zijn onbetrouwbaar. Schattingen zijn geen beloften.
Onze enige indicatie van voortgang is het leveren van dingen die onze klant waardevol vindt. Het is prima als ze daarover hun mening bijstellen.
Management levert alleen strategische begeleiding en support. Vertel de teams wat je nodig hebt en vertrouw ze om zelf uit te zoeken hoe ze dat realiseren.
Geef mensen de omgeving en support die ze nodig hebben en doe dan een stap terug. We vertrouwen autonome teams om de manier waarop ze werken en de omgeving waarin ze werken in te richten. Teams zijn zelforganiserend en zelfsturend. Ze kiezen hun eigen gereedschap en methoden. We verwachten dat ze het product en zichzelf aanpassen indien noodzakelijk. Als alle teams op dezelfde manier werken–met bijvoorbeeld hetzelfde proces of raamwerk–hebben ze geen autonomie.
Autonomie betekent niet dat de teams niet coordineren met elkaar en de rest van de organisatie. Het is essentieel dat we het eens zijn over alles van strategische doelen tot de gebruiken technologie voor implementatie.
De teams zijn stabiel. Geef werk aan de teams; vorm geen teams om het werk te doen. Betaal de teams, niet het werk.
Teams die afhankelijk zijn van andere teams kunnen niet snel genoeg reageren, dus een team moet alle vaardigheden bevatten om een idee in handen van de klant te krijgen. Vaardigheden overlappen, zodat geen enkel persoon essentieel is.
Mensen moeten elke dag fris, ontspannen en op hun best te zijn (en stop als dat niet langer het geval is).
Betrokkenheid, autonomie, meesterschap en doelmatigheid zijn essentiële drijfveren. Beloningen en straffen zijn destructief.
Communicatie is de kern van effectieve resultaten. Effectieve communicatie verbetert met het fysiek bij elkaar zijn en de rijkheid van je communicatie medium. Face to face is het beste, maar niet altijd mogelijk, dus we proberen dat zo goed mogelijk te benaderen.
Veel van de disfunctie in management komt voort uit angst, wat op zijn beurt voort komt uit een gebrek aan transparantie. Onze processen moeten zo transparant mogelijk zijn.
Every one of the 21 heuristics is an article in and of itself. A book can be written describing these 21 heuristics with case studies and examples. These are hard earned lessons from Author which needs more explanation.
For example Rule 3: People over processes. Perhaps the author was frustrated when processes were preferred over people which lead to failure.
27, but sure . They are just simple rules of thumb, so they all need detailed explanation. I have a class that covers that (which I’m happy to teach in house). I’m working on a book.
I mean I disagree with the in person part. But that’s just a nitpick. Because 1 and 24 are absolutely essential for day-to-day performance, and most ignored.
Thank you Allen, great list!
I just love it Allen, so well phrased and captures the essence of how sw development should be done. The only downside is when you see this in practice once it is impossible to go back and do what 99% of tech companies do