Das Thema Fehler und Fehlerkultur hat mich jüngst über mehrere Wege eingeholt: Zum Einen bei der Erstellung unseres Qualitätsmanagementtrainings für die LinkedIn Learning Projektmanagement Reihe und zum Anderen über eine Diskussion ausgelöst durch einen Blogpost von Marcus Raitner gefolgt von einigen Repliken, u.a. von Stephan List auf dem Toolblog.

Was mir gar nicht gefällt ist die Verquickung der Begriffe Fehler und Scheitern. Während ein Fehler ganz neutral lediglich ein Ergebnis darstellt, das so weder erwartet noch gewollt war, birgt Scheitern eine stark persönlich wertende Konotation: Eine negative Wertung über die Leistungserbringung und den Leistungserbringer. Insofern würde ich gerne Marcus These („Scheitern erlauben – Fehler abschaffen“) etwas provokant auf den Kopf stellen:

Fehler erlauben – Scheitern abschaffen!

Ganz klar: Es geht nicht um unnötige und fahrlässige Fehler, aber es geht um Fehlerkultur. Es geht um einen konstruktiven Umgang mit Fehlern. Aktuelles Negativbeispiel ist wieder das Dieselgate und der desaströse Umgang damit in Politik und den betroffenen Firmen.

Aber was ist dann eine Fehlerkultur? Was macht eine (positive) Fehlerkultur aus?

(1) Akzeptanz von Fehlern
Fehler passieren. Ob wir wollen oder nicht. Dafür ist unsere Welt viel zu komplex, als dass wir alles kontrollieren könnten. Es ist sinnlos das zu negieren, vielmehr sollten wir den konstruktiven Umgang mit Fehlern suchen.

(2) Keine Schulddebatten
Beim konstruktiven Umgang mit Fehlern geht es nicht um die Schuldfrage, sondern um Lösungen. Es geht nicht um willfährigen, vorauseilenden Gehorsam, der nur auf das achtet, was vermeintlich erwartet wird, sondern um eine ehrliche und sachliche Auseinandersetzung.

(3) Transparenz
Wir brauchen selbstverständlich im Team Transparenz über unsere Fehler und Probleme. Das ist natürlich nur möglich, wenn niemand negative Konsequenzen aus seiner Ehrlichlkeit fürchten muss. Hier schließt sich der Kreis zur Schulddebatte. Es geht eben nicht um Fingerpointing auf Personen, sondern um Sachlichkeit.

(4) Fehlervermeidung kein Selbstzweck
Natürlich wollen wir keine unnötigen Fehler, aber Fehlervermeidung darf auch nicht zur Selbstzensur werden. Wir brauchen Handlungs- und Experimentierfreiräume um Lernen zu können und voran zu kommen. Das Negativbeispiel hier ist der Sprachenschüler, der seinen Mund nicht aufkriegt aus Angst einen Fehler zu machen und damit grandios an seinem Ziel – der Kommunikation – scheitert (upps, jetzt habe ich selbst von Scheitern gesprochen), statt mit Händen und Füßen zu kommunizieren und sein eigentliches Ziel zu erreichen. Die Fehlervermeidung an sich ist nicht das Ziel, sondern (in diesem Fall) die Kommunikation, aber das wird mitunter vergessen.

Wir brauchen also einen entspannteren Umgang mit Fehlern, aber keinen leichtfertigen, einen sachlichen und ganz bewussten.

Und auf die Energieverschwendung für Eitelkeiten und Schulddebatten können wir im Sinne des Teams gerne verzichten.

Christian hat über unserer Trainer-Tätigkeit für LinekedIn Learning/video2brain getweetet.

Und ich kann nur sagen: Mit Dir jederzeit wieder!

Trainer bei LinkedIn https://t.co/CgcmxdOm7f via @visualbraindump

— Bernhard Schloß (@schlossblog) May 6, 2017

Diese Tage kam ich in der Diskussion mit einem Kunden auf die Berücksichtigung von Security Requirements in einem agilen Kontext.

Hintergrund war, dass bislang Security vor allem für den Betrieb und für die Produktsicherheit thematisiert wird, aber Sicherheitsaspekte in der Entwicklung und in einer Projektphase noch eher stiefmütterlich behandelt werden. Auf der anderen Seite finden agile Vorgehensweisen immer weiter Einzug in die Unternehmen und die Ausgangsfrage des Kunden war, wie man Sicherheitsbelange im agilen Kontext berücksichtigen kann.

Für die Projektsicht gibt es vor allem zwei Themenstränge (und dabei müssen wir noch nicht mal zwischen agil und klassisch unterscheiden):

• Die Sicherheit im Projekt
• Die Entwicklung der Sicherheit für Produkt und Betrieb

Bei letzterem Punkt könnte ich mir unterschiedliche Strategien vorstellen:

• Ein stufenweiser Hochlauf, bei dem systematisch das Sicherheitsniveau angehoben wird. (Anfangs mit einer Sandbox, dann Aufbau einer Entwicklungsumgebung, erst noch ohne Daten, dann nur mit einem Teilset der Daten, bis hin zur vollumfänglichen Produktion)
• Vorgabe von Leitplanken (im Qualitätsmanagement gibt es dafür das Control Chart als Werkzeug).
• …

Grundsätzlich würde ich Security-Anforderungen im Normalfall den nicht-funktionalen Anforderungen zuordnen.

Agile SW-Entwicklung fokussiert tendenziell auf funktionalen Anforderungen. Werden dabei wichtige nicht-funktionale Anforderungen vergessen, so kann dies eine Schwäche agilen Vorgehens sein.

Im Wesentlichen finden sich drei Ansätze zur Berücksichtigung von Security Requirements im agilen Kontext:

• Eigene nicht-funktionale Einträge ins Backlog (beispielsweise eigene User Stories. Ein Kollege hat mir berichtete mir, dass er ein eigenes Backlog für Security Anforderungen aufgebaut hat.)
• Berücksichtigung nicht-funktionaler Anforderungen als Constraints
• Berücksichtigung als Kriterien im Definition of Done

Wenn die Vorgaben für Security oder nicht-funktionale Anforderungen allerdings zu sehr formalisiert werden, dann birgt das bereits einen kulturellen Konflikt: Ein formaler Prozess entspricht jetzt nicht ganz den agilen Vorstellungen von eigenverantwortlichem Handeln, d.h. auch da bräuchte es klar definierten Handlungsspielraum für das Team.

Maturity Ansätze fand ich zur Berücksichtigung von Security Anforderungen nicht hilfreich. Da finden sich  CMMI-Adaptionen auf agile Vorgehensweisen. Thematisiert wird aber das Vorgehensmodell an sich und nicht die Berücksichtigung nicht-funktionaler oder sicherheitsrelevanter Anforderungen.

Beitrag #723 auf schlossBlog

Mittlerweile sind die ersten 5 Trainings unseres Projektmanagement-Kurses online, ein weiters ist in der Post-Produktion und die Dreharbeiten für die nächsten Trainings stehen vor der Tür.

Die Video-Trainings sind sowohl bei video2brain als auch bei LinekdIn-Learning (kostenlos für LinkedIn-Premium-Abonnenten) verfügbar. Einzelne Demo-Filme aus dem Training kann man sich auch ohne Anmeldung ansehen (bei video2brain). Wer also neugierig geworden ist…

Die Entwicklung und Erstellung war sehr intensiv, hat aber auch wirklich Spaß gemacht.

Mit Christian, meinem Trainerpartner von visualbraindump, kann man Pferde stehlen, Thomas ist ein alter Hase was Lektorat und redaktionelle Betreuung angeht und bei der Grazer Crew von video2brain ist man in den allerbesten Händen.

Da kommt noch mehr – und ich freu mich darauf!

#Beitrag 722 auf schlossBlog

Diese Tage wurde ich zufällig Ohrenzeuge einer kleinen Gruppe von Agile Coaches in einem Großunternehmen.

Erst sprachen sie ihre Einführungsfolien durch („Da sollten wir noch auf die agilen Werte eingehen.“). Das Ganze from the scratch weil agiles Vorgehen #Neuland und so, aber groß im Kommen.

Dann war Mittag und ich durfte einem anderen Gespräch der agile Coaches folgen: „Bist du jetzt schon Senior oder noch Junior? Und wie sieht es mit deiner Zertifizierung aus?“

Klar solches Hierarchie- und Statusdenken ist voll agil.

Steht bestimmt auch im agilen Manifest… Zertifikate vor gesundem Menschenverstand.

Agiles Projektmanagement ohne ein entsprechendes Mindset ist vollkommen sinnlos.

Mit dem richtigen Mindset ist schon fast wieder die Vorgehensweise egal.

Jedes Projekt braucht Agilität. Aber die erreicht man nicht durch die Einführung von agilem Projektmanagement, sondern durch eine entsprechende Einstellung und entsprechende Verhaltenswesien. Aus diesen resultiert dann (vielleicht) wieder ein agiles Projektmanagement oder aber ein open-minded klassisches Vorgehen.

Sinnfrei eingeführtes agiles PM ist genauso bürokratischer Mist, wie jede andere ohne Verstand eingeführte Methode. Mag die Methode an sich noch so gut sein.

Beitrag #721 auf schlossBlog

Und hier kommt der zweite Film der PM-Reihe – https://t.co/JCjoplVh8x //Diesmal Solo für @schlossblog

— christian botta (@pottasson) 28. Februar 2017

Doris Helzle, Immer wieder einmalig – Erfolgreich in Projekten – pfiffig und kompakt, Saulheim 2016 (Amazon)

Das kleine Büchlein von Doris Helzle ist eine humorvolle Projekt-Fibel mit wunderbaren Zeichnungen von André Poloczek (meine Favoriten sind das Reiten des toten Pferdes und der Sprung ins Neue/Unbekannte).

Doris Helzle weiß worauf es ankommt und deswegen stehen statt Methoden die Kommunikation und das Zwischenmenschliche im Vordergrund – da bin ich ganz bei ihr!

Sie hat wunderbare Bilder (nicht nur die von André Poloczek, sondern auch im übertragenen Sinne) für uns bereit: Seien es Lampe und Papierkorb mit ihren launigen Dialogen im Projektbüro oder das perfekte Verbrechen als Projektmetapher.

Einzig in einem Punkt tue ich mich schwer: Wem sollte ich diese Büchlein, das so schön gemacht ist, empfehlen?

Alten Projekthasen? Die würden Doris Helzle gleich zustimmen und am liebsten bei einem Bierchen mit der Autorin Projektanekdoten austauschen, aber etwas wirklich Neues würde ihnen nicht geboten.

Newbies? Da habe ich etwas Bedenken, denn sehr schnell geht die Autorin über elementare Begriffe hinweg und setzt das eine oder andere Mal vielleicht etwas mehr voraus, als man von dieser Zielgruppe erwarten darf. Klar weckt die Lektüre Appetit, aber für eine Einführung ist es dann doch etwas dünn.

Zyniker? Nein, dafür ist die Autorin zu pragmatisch.

Melancholiker? Vielleicht am Ehesten. So in den tiefen Abgründen eines Projekts, abends nach getaner Arbeit, um sich gemeinsam mit gleichgesinnten „auszukotzen“? Nun, dann vielleicht doch lieber auf ein Bierchen mit Doris Helzle…

Trotz allem, aber ein schön gemachtes Buch, das bei der Lektüre ein Schmunzeln ins Gesicht zaubert!

Beitrag #719 auf schlossBlog

https://t.co/QHRBTZSxIq der erste Kurs von @schlossblog und @pottasson ist jetzt auf @LinkedIn verfügbar #Projektmanagement

— Visual Braindump (@VisualBraindump) 9. Februar 2017

Warum erfreuen sich Konzepte wie Visuelles Denken, Design Thinking oder Werkzeuge wie Canvas immer mehr Beliebtheit?

Nun: Sie bringen Empathie zurück in unsere Unternehmen.

Empathie bezeichnet die Fähigkeit und Bereitschaft, Empfindungen, Gedanken, Emotionen, Motive und Persönlichkeitsmerkmale einer anderen Person zu erkennen und zu verstehen (Wikipedia). Egal ob bezüglich unserer Mitarbeiter, unserer Kunden, Konkurrenten oder anderer Stakeholder.

Beispielsweise mit einer Empathy Map können wir uns das Empfinden einer Person vor Augen führen.

Das Scientific Management von Taylor ist alt, aber Management by Objectives und amerikanisches Management Denken haben sich in den letzten Jahren immer mehr durchgesetzt.

Was auf der Strecke geblieben ist, sind einfühlsames Denken und gesunder Menschenverstand.

Visuelles Denken und Prozesse wie Design Thinking sprechen auch unsere emotionale Intelligenz an.

Haben wir zuletzt einseitig auf die eine Seite geschielt, dann verspricht ein Schielen auf die andere Seite verblüffende Einsichten und Erkenntnisgewinn.

Einseitige Gefühlsduselei ist natürlich genau derselbe Quatsch, wie blinder Rationalismus. Ein konsequentes Management by Objectives – ohne Sinn und Verstand – führt selbstverständlich genauso ins Verderben, wie wenn wir unseren Namen tanzen…

Man kann diesen Schalter aber nicht steuern. Man kann nicht wählen: 10% Gefühl, 90% Kalkül. Es ist immer ein sowohl als auch.

Und wer an den Werten von Zielvorgaben oder Command & Control blind festhält wird nie wirklich Empathie entwickeln.

Beitrag #717 auf schlossBlog

Mein neues Büro pic.twitter.com/s1S5ckKRGB

— Bernhard Schloß (@schlossblog) January 29, 2017