Inhalt : Aus Fehlern lernen - aber wie?

Ich habe gerade einen interessanten GEO-Artikel über das Thema "Aus Fehlern lernen" gelesen.

Für mich ist ein wichtiger Aspekt agilen Arbeitens, dass man durch Iterationen genau dieses Lernen aus Fehlern ermöglicht - vorausgesetzt jeder im Team ist dazu bereit.

Darum meine Frage:

• Wie schafft ihr in euren Teams/Projektgruppen/bei euch selbst ein Umfeld, dass genau dieses Lernen auf Fehlern zulässt?
• Habt ihr eine gute Methode oder Tipps zu dem Thema?

Bitte schreibt eure Antworten doch direkt in den Beitrag, indem ihr den Bearbeiten-Button nutzt. So können wir ewige Kommentarlisten vermeiden und aus der Frage am eine hoffentlich einen Beitrag mit Antworten machen!

rainwebs: Grundsätzlich muß der Scrum Master dafür sorgen, daß Fehler gemacht werden dürfen. Das fällt den klassischen Managern traditionell schwer. Null-Fehler-Toleranz ist noch stark verbreitet. Es scheint einen Zusammenhang zu geben zwischen der Anzahl gemachter Fehler pro Zeiteinheit und der sich danach einstellenden Effizienz. Demnach sollte das Team möglichst viele Fehler machen (in möglichst kurzer Zeit), um möglichst effizient zu werden. Allerdings gilt auch hier: jeden Fehler nur einmal - sonst tritt kein Lerneffekt auf .

Jens von Gersdorff: Fehler passieren. Und wenn man es genau nimmt plant man eine gewisse Fehlerquote aus der Erfahrung mit ein. Auch und besonders als "klassischer Manager" . Das Lernen daraus passiert unmittelbar, wenn das Team oder auch die einzelnen Mitarbeiter dazu bereit sind. Gegen "Lernresistenz" kann weder das Team noch ein Scrum Master oder PM etwas machen. Im Großen  und Ganzen ist es zuerst ein Klima des Vertrauens im Team (dessen Teil ich als PM bin) dass es ermöglicht "lesson learned" zu leben. Ob ein Lerneffekt eingesetzt hat sieht man an der zunehmenden Performance des Projekt. Und an einer angstfreien Arbeitsatmosphäre. Denn Mitarbeiter verfallen ansonsten in einen "Angststarre". Eine Null-Fehler-Toleranz ist mir in meinem Leben nicht begegnet, wohl aber heftige Reaktionen, wenn aus Fehler nichts gelernt wird und sie deswegen immer wieder auftreten. Ich mag es nicht, wenn das Team (also auch ich) möglichst viele Fehler macht. Rookies vielleicht. Aber ältere Mitarbeiter sind schon sehr erfahren, was dafür spricht, dass sie aus gemachten Fehlern gelernt haben. Eingeplante Fehler-Quoten sind aber oftmals Versicherungen, die man nicht in Anspruch nehmen muss, rentieren sich allerdings in der o.b. angstfreien Arbeitsatmosphäre und der besseren Performance daraus.

Ausserdem bin ich der Meinung, dass dies KEIN Thema für "Agiles PM" ist, sondern eines, was allgemein zum Thema PM gehört: Menschenführung! --> Guter Punkt, habe ich geändert

Roland Baldenhofer: Aus Fehlern der Vorgängerprojekte lernen
Fehler wurden bereits in der Vergangenheit gemacht. Bei vielen Projekten werden in Lessons-Learned-Meetings die erkannten Fehler aufgeschrieben.
Bei vielen Firmen werden diese Lessons Learned zusammen mit dem Projekt beerdigt und in ein Archiv verschoben. Einige Firmen nehmen diese Informationen jedoch und publizieren sie so, dass nachfolgende Teams und Projekte diese Lessons Learned wieder finden können.
Es lohnt sich in einer Firma bei Projektstart, und immer wieder mal zwischendurch, schnell mal über die bisherigen Lessons Learned drüberzuschauen. Ich habe mir angewöhnt dies zu tun und mein Team dazu zu ermutigen dass sie das auch tun.
So können wir von der Vergangenheit lernen und unsere eigenen (neuen) Fehler machen.

Peter Addor (26.8.12): Zu Punkt 2 (Habt Ihr eine gute Methode....) finde ich Rolands Hinweise gut. Lessons Learned (LL) gehört zu jedem Projekt. Diese dürfen nicht einfach archiviert werden. "Zwischendurch schnell mal über die bisherigen LL drüberschauen..." ist zwingend. Regelmässige Denkpausen verzögern das Projekt nicht, sondern beschleunigen es paradoxerweise. Zusätzlich meine ich, dass LL stets in Prozessen und Infrastruktur ihren Niederschlag finden sollten. Nehmt irgend einen Aspekt aus Euren LL und verändert damit einen Arbeitsablauf oder macht daraus eine organisatorische oder gar eine bauliche Massnahme. Das ist auch Kontextmanagement. Dass Projektleiter dafür oft zu wenig Einfluss haben, sollte hier eigentlich ein wichtiges Diskussionsthema sein.

Zu Punkt 1 (Wie schafft Ihr ... ein Umfeld, das Lernen zulässt): Das ist ein sehr komplexes Thema. Es geht einmal darum, Projekte als lernende Organisationen aufzufassen. Das Verständnis der eigenen mentalen Modelle und Systemdenken sind Voraussetzungen dafür. Das können zum Beispiel Lernzyklen leisten, die unabhängig von Projekten regelmässig durchgeführt werden, um eine Kultur des Lernens aufzubauen. Lernen heisst in diesem Zusammenhang natürlich nicht, das PMBOK für die Zertifizierung auswendig zu lernen, sondern zu lernen, Aufmerksam zu sein bei allem, was man macht und zu wissen, worauf mach achten soll und was Fehler überhaupt sind. Ein gute Hilfe ist es, Aufmerksamkeit auf Fast-Fehler zu legen. Zu wissen, was hätte passieren können, wie es verhindert wurde und warum, ist sehr wertvoll.

Von Erfahrung halte ich nicht viel. Projekte sind definitionsgemäss erst- und einmalig, da gibt es keine Erfahrung. Erfahrung verleitet auch zu Frequency Gambling und Similarity Matching, zwei Denk- und Verhaltensfehler, die Projekte (und Unternehmen) leicht gegen die Wand fahren lassen. 

Thilo Niewöhner (01.11.2013):  Aus Fehlern zu lernen ist kein einfacher Prozeß.

Aus meiner Sicht beginnt alles mit dem täglichen Umgang miteinander, also mit Sozialkompetenz: Behandle Deine Teammitglieder so, daß Du selbst in einer Konfliktsituation immer unterbrechen und sagen kannst; "Komm, wir gehen erstmal was essen", ohne daß sich einer der Beteiligten merkwürdig fühlt.

Geht man vertrauens- und respektvoll miteinander um, schafft man die Basis für das freiwillige Aufzeigen von Fehlern, ohne daß die Kollegen Schuldzuweisungen fürchten.
Hat man die Kollegen so weit mitgenommen, hat das einen äußerst wertvollen Nebeneffekt:
Dadurch, daß die Kollegen dem Projektleiter vertrauen, melden sie auch eigene Fehler so früh, daß man gemeinsam noch reagieren und das Schlimmste vermeiden kann.

Jetzt kommt die Unterscheidung: Kleinere Fehler oder Nachlässigkeiten werden behoben, und mit dem Mitarbeiter eine angepaßt gemeinsame Kontrolle vereinbart. Das ist dann ein Lessons Learned im Kleinen.
Für größere Fehler braucht es unter Umständen eine Analyse, die im Projekt geführt und ggf. vom Projektleiter dokumentiert wird.

Mit den Analysen kann man dann am Ende des Projektes überprüfen, wo Veränderungen notwendig sind.

Erfahrungsgemäß bleiben diese Punkte aber im Team, da das Unternehmen meist keinen übersteigerten Wert auf Lessons Learnt Analysen hat, da diese meist mit Aufwand und Kosten verbunden sind. Um so wertvoller ist also der (zum Teil in einem kleinen schwarzen Moleskin dokumentierte) Erfahrungsschatz eines PM sowie der (hypothetische) Ansatz, erfahrene Teams über mehrere Projekte zu erhalten und zu fördern. 
Manche Projektleiter führen übrigens ihre eigenen Projektvorlagen, inklusive einem stetig fortgeführten Risikoregister, das beim Aufsetzen eines neuen Projektes in das Risikomanagement mit einfließt.

Anders gesagt: Wo die Firmen keinen Raum für Fehler lassen, bleibt dem PM keine andere Wahl, als diesen Spielraum selbst zu gestalten und zu führen.