Was hat aber Unternehmenskultur jetzt mit agiler Entwicklung zu tun? Sehr viel! Liest man sich das agile Manifest durch, kann es nach meiner Meinung so zusammengefaßt werden, daß es für unseren Erfolg wichtiger ist, wie wir miteinander umgehen, als welche detailierten Prozesse wir versuchen einhalten. Wie wir mit einander umgehen, daß lernen wir in unserer Umgebung. Wir sehen, wie die anderen sich in unserer Umgebung verhalten, welche Strategien erfolgreich sind oder zumindest vor Schaden schützen, und passen uns daran an. Das paßt gut zur Definition von Kultur in Organisationen, wie ich sie bei Sonja Sackmann gefunden habe:

Organisationskultur ist die von einer Gruppe gemeinsam gehaltenen grundlegenden Überzeugungen, die deren Wahrnehmung, Denken, Fühlen und Handeln bestimmen und insgesamt typisch für die Gruppe sind.

Ein für uns sehr leicht nachvollziehbares Beispiel in der Softwareentwicklung ist der Umgang mit Fehlern. Defekte, das klingt doch wesentlich neutraler, gibt es in jeder Software, denn Software-Entwicklung ist zu komplex, um keine Fehler zu machen und sei es, daß es ab einem bestimmten Punkte nicht mehr wirtschaftlich vertretbar ist, eine Software gegen jeden Fehler abzusichern. Gute Projekte und Entwicklungsteams unterscheiden sich aber im Umgang mit Fehlern. Keiner macht gerne Fehler, denn das Fehlermachen wird negativ bewertet und oft in der einen oder anderen Form bestraft. Das kann ganz diffizil sein, beispielsweise wenn gleich gesagt wird: „Paß auf, nicht wieder die gleichen Fehler zu machen.“ Neulich habe ich in einem Projekt einen Softwarefehler gefunden und wollte zu dem für die Komponente verantwortlichen Entwickler gehen mit der Bitte, den Fehler zu beseitigen. Er sei im Urlaub sagten mir seine Kollegen, worauf hin ich meinte, daß das schlecht sei, denn er sei der Einzige, der den Fehler beheben könne, sagten sie, daß das vielleicht ja auch gut wäre, dann würde es vielleicht ja auch weniger Fehler geben. Ja, ja, der Truckfaktor. Aber, Wissensverteilung, Risikominimierung und Teamarbeit sind ja jetzt nicht mein Thema. Dieses Beispiel zeigt aber sehr gut, wie der Umgang mit Fehlern symptomatisch für die Kultur in einem Team ist. In einer solchen Umgebung werden Fehler bestraft, was dazu führt, Fehler zu vertuschen, zu leugnen, als nicht so wichtig hinzustellen, als sie zu beheben und daraus zu lernen.

In ihrem Buch „Soft Skills für Software-Entwickler: Fragetechniken, Konfliktmanagement, Kommunikationstypen und -modelle“ haben Uwe Vigenschow und Björn Schneider eine kleine Taxonomie von Fehlerkulturen aufgestellt, in der zwischen funktionaler und dysfunktionaler Fehlerkultur unterschieden wird.

Welche Fehlerkultur herrscht bei Ihnen?

Eigentlichtlich sollte es doch so sein, daß mit zunehmender Erfahrung sich auch unser mentales Modell erweitert, da wir unserm Wissen neuen Fakten und Regel hinzufügen. Dem setzen die Autoren entgegen, daß es uns Menschen schwer fällt Ursache und Wirkung über längere Zeitabstände nicht nur zur Erkennen, sondern auch in unser Handlungsschema zu integrieren. Ich denke, dieses Phänomen ist uns doch nur all zugut bekannt.

Wir müssen also Wege finden auch über größere Zeiträume uns Zusammenhänge zu verdeutlichen. Die Autoren empfehlen hierfür kognitives Feedback. Hierfür werden wichtige Variablen im Projektalltag identifiziert und deren Abhängigkeiten beschrieben. Steuerungsvariablen bilden unser Handeln ab, Kontrollvariablen beschreiben die Auswirkungen unserer Maßnahmen.

Ein leicht nachzuvollziehendes Beispiel sei der Zusammenhang zwischen Defekten in einem Software-Produkt und den Aufwänden für Schulungen. Wir gehen davon aus, daß viele Fehler im Projekt auftreten, will Wissen, ein gemeinsames Verständnis oder Standardsfehlen. Unser Ziel ist es die Fehler im Projekt zu reduzieren. Als Kontrollvariable nehmen wir die Anzahl der gemeldeten und bestätigten Defekte aus unserem Bugtracking-System. Um unsere Fehlerquote zu senken, investieren wir in die Aus- und Fortbildung unserer Mitarbeiter und messen dies über die dafür entstanden Kosten. Wie zu erwarten sinken nach einiger Zeit mit den Schulungen die Fehler und wir können den Schulungsaufwand reduzieren. Trotzdem sinkt die Defektanzahl auch noch später, obwohl den Schulungsaufwand auch reduzieren. Hier stellt sich eine Langzeitwirkung ein.

Ein einfaches Beispiel und nicht immer sind Zusammenhänge so einfach. Doch es demonstriert gut, was kognitives Feedback bedeutet. Für eine richtige Anwendung setzt es jedoch eine gute Datenbasis und kontinuierliche Datenerhebung voraus.