PHP Magazin | Erfolgreich lernen!

"He broke the build"-Auszeichnungen und das obligatorische Besäufnis nach einem Launch gewährleisten nicht einen nachhaltigen Wissensaufbau im Unternehmen. Wie sorge ich aber für ein gutes Lernklima im Unternehmen?

Was kann der Einzelne leisten, damit die Organisation aus Erfolgen und Misserfolgen lernt – und zukünftig schlauer agiert?

Diese Ausführungen rutschen dabei leicht in einen Jammer-Ton ab. An der grundsätzlichen Situation habe sich seit geraumer Zeit nichts geändert. Warum ist das so?

Wer Missstände bejammert, muss das eigene Verhalten nicht reflektieren und anpassen. Jammern als Kritikform zeigt nur auf andere Projektbeteiligte. Diese Kommunikationsform belässt den Einzelnen in der Komfortzone seiner Arbeit. Die Komfortzone ist der Bereich von Wissen von Fähigkeiten, in dem wir uns wohl fühlen. Wir kenne uns sicher in dieser Zone aus. Im täglichen Miteinander versuchen Mitarbeiter, die Komfortzone [2] nicht verlassen zu müssen. Dies ist für Unternehmen hinderlich, weil so kein Wissensaufbau in der Mitarbeiterschaft stattfindet.

Jammert ein Mitarbeiter nur über einen Projektmissstand, kann er in der bequemen Komfortzone weiter arbeiten. Seinen Qualitätsanspruch beruhigt er durch genau dieses Jammern: „Würde der Rest vernünftig sein, könnte ich hier auch was Vernünftiges bauen.“

In dieser Kommunikationsform verbirgt sich gleichzeitig ein unternehmenskultureller Wert. Mitarbeiter, die so agieren dürfen, arbeiten in Unternehmen, in der Verhaltensänderungen durch eine höhere Hierarchiestufe initiiert werden. In solchen Unternehmen ist Jammern über unmögliche Entscheidungen und Vorgänge üblich. Diese Mitarbeiter spüren nicht die Erwartungshaltung, dass sie ihr eigenes Verhalten reflektieren und dieses gegebenenfalls verändern sollten. Diese Mitarbeiter dürfen – unternehmenskulturell geduldet – in der Komfortzone verbleiben.

Arbeitsteilige Projekte zeichnen sich häufig dadurch aus, dass Rollen, Verhaltensregeln sowie Aufgaben der beteiligten Personen unklar sind.

Die Klärung der grundlegenden Projektfragen sollte in der KickOff-Sitzung erfolgen. Wenn Mitarbeiter KickOff-Sitzungen mit Hinweis auf die viele anstehende Arbeit verweigern, werden offensichtlich keine fürs Projekt wesentlichen Fragen geklärt. Dem Jammern über schlechte Projektumstände wird der erste Raum gegeben.

Das Projekt beginnt mit einer klar strukturierten KickOff-Sitzung, in der alle Grundfragen zum Projekt geklärt werden, gefolgt von regelmäßigen Sitzungen, in denen das gesamte Team Aufgabenstellung und Vorgehen bespricht.

Dieser Forderung nach einem gleichberechtigten Team, wie sie sich auch in den zwölf Prinzipien des agilen Manifests findet, steht die althergebrachte, hierarchische Denkweise gegenüber. Denn fünf der zwölf Prinzipien beschreiben die optimale Teamzusammensetzung und perfekte Kommunikation in agilen Projekten [3]:

• „Business people and developers must work together daily throughout the project.“
• „Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.“
• „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“
• „The best architectures, requirements, and designs emerge from self-organizing teams.“
• „At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.“

Die Forderung nach Agilität mag nicht jede Geschäftsleitung bzw. jeder Auftraggeber mitgehen. Fordert doch Agilität eine neue Form der Verantwortungsübernahme als die häufiger vertretende, hierarchisch organisierte Projekt- und Unternehmensform.

Ein Argument für den regelmäßigen Austausch zwischen allen Projektbeteiligten ist, dass fehlende Kommunikation Geld kostet. Projekte scheitern, wenn Kommunikation zwischen den Beteiligten fehlt [1]. Die Etablierung dieses Methodenbausteins ist unabhängig von der Einführung einer agilen Methode.

Eine regelmäßige und persönliche Kommunikation sichert zwischen den Teammitgliedern die individuellen Kenntnisse über Anforderungen und Ansprüche ans Projekt.

Im Gespräch ergeben sich viele Aha-Erlebnisse bei den Teammitgliedern, die unnötige Projektschleifen verhindern. Gerade in interdisziplinären Teams ist der direkte Austausch sehr wichtig. Die Reduktion auf schriftliche Dokumente würde zu Missverständnissen führen. Die Ergebnisse direkter Absprachen werden für alle abschließend und recherchierbar schriftlich dokumentiert.

Ohne das Streitwort „agil“ ist die Einführung von regelmäßigen Kommunikationsritualen leicht möglich. Fokus der Argumentation für eine veränderte Verhaltensweise liegt auf der Vermeidung von Missverständnissen (und damit zeit- und aufwandsintensiven Projektschleifen) durch eine offene, bewusste Reflexion des Team-Verhaltens und der anstehenden Aufgaben.

Die allen bekannte Definition des Projektziels, die Benennung der Projektbeteiligten und deren Rollen, der regelmäßige Austausch über anstehende Aufgaben sowie die regelmäßige Reflexion des Teamverhaltens wird zur Verbesserung des Arbeitsalltags führen. Die Aufgaben sind für alle verständlich und ordnen sich wie selbstverständlich in das Gesamtprojekt ein.

Häufig werden in Unternehmen Projekte nach dem Wasserfall- bzw. V-Modell durchgeführt. Die Erarbeitung der Anforderungen, die Lösungsskizze, die Implementierung, Qualitätssicherung, Auslieferung und Betrieb erfolgen arbeitsteilig (in verschiedenen Abteilungen und Team-Zusammensetzungen). Selbst Teams, die sich als agil bezeichnen, leben oft in einer insgesamt arbeitsteiligen und stark hierarchisch organisierten Umgebung. Wenn der Auftraggeber des Projekts (d.h. das „Business“ der agilen Terminologie) nicht Mitglied des Projektteams ist, entsteht eine hierarchische Struktur, mit der es umzugehen gilt. Für beide Herangehensweisen gilt, dass im Normalfall ein offener Austausch der Erwartungen, Vorgehensweisen und Lösungsansätze unterbleibt.

Um eine effiziente Gemeinschaftsleistung zu ermöglichen, muss die Gemeinschaft spürbar sein. Dazu gehören ein regelmäßiger Austausch über „Was steht an?“ im Projekt genauso wie die Reflexion des Verhaltens (also der Austausch übers „Wie?“ in Form von Retrospektiven).

Darüber hinaus muss aber auch vom Projektbeginn an klar sein, wer dem Team zuzurechnen ist und welche Personen darüber hinaus durch Erwartungen bzw. Zulieferungen zum Gelingen des Projekts beitragen. Die klassische Stakeholder-Analyse [6] hilft, Transparenz über Projektbeteiligte und deren Anforderungen herzustellen. Gleichzeitig kann die Stakeholder-Analyse zu Beginn der Arbeit helfen, das Rollenverständnis jedes Einzelnen für das Projekt zu schärfen.

Eine Team-Sitzung wird im Krisenfall – jedes Teammitglied befindet sich in der Panikzone – nicht einberufen werden. „Dafür haben wir jetzt keine Zeit, das klären wir später“ – mit dieser Ansage unterbleibt eine grundsätzliche Klärung. Der für später angekündigte Termin wird nicht forciert und irgendwann vergessen. Gleichzeitig liefert diese durchlebte schwierige Situation weiteren Stoff fürs Jammern: „Das war doch klar, dass das schieflaufen musste“.

Jedes Teammitglied hinterfragt daher am Beginn des Projekts die Kommunikationsrituale im Projekt. Diese werden in der KickOff-Sitzung vereinbart. Unterbleibt diese Klärung zunächst, sind hier die Teammitglieder gefragt: sie fordern diese nachträglich ein.

Während eines Projekts sind die Grundfragen „Wie“ und „Was“ in drei Zeitperspektiven zu klären:

• Wie und was ist es bisher gelaufen?

• Wie und was steht jetzt an?

• Wie und was liegt noch vor uns?

Jedes Team stellt hierfür die für sich passenden Methodenbausteine zusammen. Die nachfolgende Liste weist exemplarisch eine Zusammenstellung auf. In diesem Beispiel nutzt das Team klassische als auch agile Methodenbausteine.

Review-Sitzungen unterbleiben dann, wenn Mitarbeiter die Verurteilung für Fehler fürchten. Oder anders formuliert: Ist unternehmenskulturell verankert, dass immer eine einzelne Person die alleinige Schuld an Fehlern trägt, wird sich niemand zu Fehlern bekennen. Gerade in Software-Projekten ist es üblich, Einzelne an den Pranger zu stellen, wenn sie Fehler gemacht haben. Eine Google-Bilder-Suche nach „He broke the build“ zeigt eine Vielzahl von Entwicklern, die meist weniger glücklich in die Kamera schauen, während sie veralbert werden [4].

Dieses negativ besetzte Anprangern wird dem Team nicht ermöglichen, einen ähnlich gelagerten Fall zu erkennen und adäquat zu reagieren. Gleichzeitig kann das Auszeichnen von Fehlern für den Einzelnen eine große Belastung darstellen, die derjenige aktiv meidet. Er erreicht dies, in dem er Fragestellungen, die außerhalb seiner Komfortzone (also außerhalb seines sicheren Wissens und seiner Fähigkeiten) liegen, nicht als Aufgabe annimmt. Nicht für jeden Mitarbeiter stellen Rituale dieser Art ein Problem dar – aber für viele nimmt eine solches Ritual die notwendige Sicherheit, um innovativ außerhalb der Komfortzone zu agieren. Unternehmen, die ein „He broke the build“-Ritual in ihrem Unternehmensrepertoire führen, verkleinern damit die ohnehin schon schmale Lernzone.

Sind hingegen regelmäßig stattfindende Retrospektiven für das Projekt etabliert, wird das Team auch in der schwierigen Lage erste Erkenntnisse über das Auftreten und Auswirkungen sammeln und mögliche neue Wege diskutieren können. In einer Retrospektive sind die Ursachen für Probleme und Fehler zu benennen:

• Woran können wir erkennen, dass eine bestimmte Situation vorliegt?

• Was muss ich in einer solchen Situation tun?

Diese Fragestellung trägt der Erkenntnis Rechnung, dass Fehler in Software-Projekten gemeinschaftlich gemacht werden. Einer mag die „falschen“ Code-Zeilen getippt haben, aber alle anderen haben genau das zugelassen. Keine Prüfung, kein Test, kein Teamverhalten hat dies verhindern können. Deswegen ist auch jedes Teammitglied an der Fehlerbehebung beteiligt. Der Einsatz des Partnerschaftspassiv [5] „Man müsste mal …“ würde zu keinen Verhaltensänderungen führen, weil für niemanden klar wäre, wer „man“ ist.

Schließt das Team ein Projekt erfolgreich ab, sind – um den Erfolg im Unternehmen zu manifestieren – zwei Maßnahmen durchzuführen:

1. Der Erfolg ist zu feiern!

2. Aus dem Erfolg lernen!

Feiern! Der positive Abschluss eines Projekts ist Anlass für die Würdigung der Leistung des Teams. Diese Würdigung erfolgt zum Einen im Team selbst, sollte aber auch durch die Leitungsebene und den Auftraggeber (sofern extern) erfolgen. Wenn das eine Projekt nahtlos vom nächsten abgelöst wird, befinden sich die Mitarbeiter in einer Tretmühle, die voraussichtlich im BurnOut enden wird. Der feierliche Abschluss eines Projekts setzt einen Schlusspunkt und ermöglicht eine kleine Verschnaufpause.

Die Feier selbst wird je nach Team unterschiedlich ausfallen. Während die Einen sich einen Sekt auf der Arbeit erlauben, mögen die Anderen sich auf einem Bowling-Abend wiederfinden. Auch bei diesem (schönen!) Ritual ist darauf zu achten, dass die gefundene Feierform für alle Beteiligten annehmbar ist. Die männerdominierte IT-Branche neigt zu Feierformen, die explizit für die weiblichen Projektbeteiligten unangenehm sind. Da die Beteiligung von Frauen wünschenswert ist, nicht nur, aber auch wegen der umsatzsteigernden Wirkung [6], die von Frauen ausgeht, sollten die Feierrituale für alle Teammitglieder passen.

Auch wenn das Projekt nicht so gut verlaufen ist, ist die Teamleistung zu würdigen. Jedes Unternehmen hat auch hierfür einen angemessenen Weg zu definieren. Das Totschweigen von Projekten ist für alle daran Beteiligten schwer auszuhalten. Schafft man es, aus der Situation zu lernen, ist auch ein schlecht verlaufenes Projekt ein gutes Projekt – verhindert die bewusste Reflexion darüber die Wiederholung der gemachten Fehler.

So wie aus Fehlern zu lernen ist, ist aus dem Erfolg zu lernen. Warum hat das Team das Projektziel gut erreichen können? Welche Handlungen und Vorgehensmodelle haben dem Team geholfen? Was war der Beitrag jedes einzelnen Projektbeteiligten? Die Sinnhaftigkeit einer Retrospektive wird von vielen erkannt, wenn es nicht gut läuft. Durch Retrospektiven einen guten Projektverlauf abzusichern, ist das wahre Erfolgsmodell. Erfolgreiches Lernen motiviert für weitere Schritte. Die Lernzone erweitert sich quasi wie von selbst.

In guten Projektphasen ist sicherzustellen, dass das Projektteam nicht in Eigenlob ausbricht, sondern tatsächlich nach den Erfolgsfaktoren für den guten Verlauf sucht und diese benennt. Durch Überprüfung in nachfolgenden Retrospektiven kann das Team den eigenen Lernfortschritt weiter ausbauen.

Für Unternehmen ist es sinnvoll, wenn ihre Mitarbeiter in der Lernzone agieren. Ist dies der Fall, wachsen das Wissen und die Fähigkeiten im Unternehmen. Aber: in der Lernzone passieren Fehler! Die Mitarbeiter betreten neues Land – und auf dem Weg ins Unbekannte werden auch falsche Entscheidungen getroffen.

Um dennoch eine positive Bewegung fürs Unternehmen daraus zu erzeugen, ist ein positiver Umgang mit Fehler notwendig: eine gute Fehlerkultur muss her. Der Schwenk einer gesamten Organisation hin zu einem guten, lernenden Umgang mit Fehlern ist nicht einfach [8]. Es gilt eine Atmosphäre zu schaffen, in der jeder Einzelne – ohne negative Konsequenzen fürchten zu müssen – Fehler benennen und andere Handlungsalternativen diskutieren kann.

Projektteams haben die Möglichkeit, diese Reflexionsform direkt einzuführen. Durch gemeinschaftlich vereinbarte Spielregeln sorgt das Team für eine angstfreie Umgebung, in der das Teamverhalten reflektiert und optimiert werden kann.

Jedes Teammitglied, aber auch jede Führungskraft, beginnt, eigene Fehler zu benennen und über Handlungsalternativen mit anderen Kollegen ins Gespräch kommen. Aus dem Projektablauf – sowohl dem positiven als auch dem negativen – können alle Beteiligten lernen:

• Was ist gut gelaufen? Was werde ich beim nächsten Mal wiederholen?

• Was ist nicht gut gelaufen? Wo liegen die Ursachen hierfür? Was und wie ist mein Beitrag, es beim nächsten Mal anders zu machen?

Durch die Verankerung dieser Fragestellungen durch rhythmisch wiederkehrende Retrospektiven sorgen alle dafür, dass das Projektvorgehen laufend optimiert wird.

Sind diese Fragen fest verankert und werden die Antworten gelebt, verläuft der Arbeitsalltag einfacher, dabei aber spannender. Schließlich betritt jedes Teammitglied täglich neues Land – in seiner Lernzone!

Dieser Artikel ist zuerst im PHP Magazin, Ausgabe 02/2013, Software & Support Verlag erschienen.

• Nächster Artikel: Betriebswirtschaft + testgestützte PHP-Entwicklung
• Vorheriger Artikel: Software-Qualität in PHP-Projekten | Testbasierte Entwicklung verkaufen [01]