Open Loops

Auch - oder gerade wenn - ein Team bereits eine Zeitlang agil arbeitet, lohnt es sich, einmal einen Schritt zurück zu treten und das gelebte Vorgehen kritisch zu betrachten.

Nicht selten fällt dabei auf, dass zwar”formal” noch alles richtig gemacht wird, aber das eigentliche Ziel der jeweiligen Methode nicht mehr im Fokus steht. Sehr schön ist dies häufig bei StandUp Meetings zu beobachten, bei denen nicht mehr das tägliche Commitment auf ein Ziel im Vordergrund steht, sondern eher allgemein erzählt wird, womit man sich gerade beschäftigt. Das ist für sich natürlich auch schon mal nicht schlecht, erfüllt aber den Zweck nicht wirklich.

Erst wenn ich mir individuelles Tagesziel wähle, kann ich später feststellen ob ich dieses erreicht habe. Und nur dadurch werden Hindernisse sichtbar. Wenn ich aber nur allgemein beschreibe mit was ich mich beschäftige, werde ich am Folgetag womöglich nur berichten dass ich immer noch mit dem gleichen Thema befasst bin. Die Frage aber, ob es Hindernisse gab, wird dadurch unbeantwortbar: Ich wollte mich mit einem Thema beschäftigen und habe das auch getan. Wenn man sich also keine konkreten Ziele setzt, nimmt man sich auch eine Gelegenheit durch Erfahrung besser zu werden.

Einen sehr schönen Artikel mit vielen praktischen Tipps für das eigene StandUp gibt es auch auf der Webseite von Martin Fowler: It’s not just standing up

Auch wenn Sie kein Sportfreak sind, kennen Sie sicherlich den 4 x 100 Meter Lauf bei den olympischen Spielen oder Weltmeisterschaften. Und Sie erinnern sicherlich auch Bilder aus der 4 x 100 Meter Freistilstaffel, die aus der olympischen Schwimmarena übertragen wurden. Staffelrennen scheinen sich doch irgendwie ähnlich zu sein, meint der Laie. Doch schaut man genauer hin, gibt es einen feinen Unterschied in der Art, wie die Staffel ausgetragen wird.

Ein Schwimmer muss am Beckenrand warten, so lange, bis sein Vorgänger angeschlagen hat. Erst dann darf er die harte Grenze Beckenrand verlassen. Anders ist es in der Leichtathletik-Staffel. Es gibt eine Übergabezone, in der beide Läufer gleichzeitig und nebeneinander herlaufen. Die Übergabe erfolgt durch den Staffelstab. So kann die Leistung eines schwächeren Läufers durch einen starken Läufer, der schon mitläuft und gut startet, leichter ausgeglichen werden. Beim Schwimmen addiert sich die Gesamtzeit der Staffel im Wesentlichen aus den Einzelzeiten der Schwimmer. Bei der Übergabe mit Staffelstab ist das Gesamtergebnis wesentlich durch die perfekte und manchmal auch tragische Übergabe zwischen den Läufern bestimmt.

Im Projektgeschäft habe ich beide Arten von Staffellauf kennengelernt.
Einmal eher die Schwimmer:

• Architekten, die auf die Arbeit des Fachbereichs warten, bevor sie loslegen und sich die ersten Gedanken machen.
• Entwickler, die erst programmieren dürfen, wenn bestimmte Dokumente fertiggestellt sind.
• Entwickler, die nach getaner Arbeit die Szene völlig dem QA-Team überlassen.

Auf der anderen Seite die Läufer mit Staffelholzübergabe:

• Architekten, Testmanager und Entwickler, die dem Fachbereich helfen, eine möglichst nützliche fachliche Spezifikation zu schreiben.
• Entwickler, die es als selbstverständlich ansehen, den technischen Schreibern zur Hand zu gehen, wenn die nicht richtig fertig werden.
• Entwickler, die nach getaner Arbeit dem Testteam helfen, möglichst gründlich zu testen und Fehler sofort beseitigen.

Auch im Projektgeschäft sind diese beiden unterschiedlichen Herangehensweisen völlig andere “Sportarten”. Auf der einen Seite Einzelkämpfer, die ihre Leistung zu optimieren suchen und auf keinen Fall Anteil an einem möglichen Mißsserfolg haben möchten. Auf der anderen Seite Team-Player, die für den gemeinsamen Erfolg die anderen Teammitglieder unterstützen und dafür auch proaktiv Arbeiten der anderen Disziplinen tatkräftig begleiten.

Modernes Management, das alle Ressourcen nutzen möchte, heißt für mich, den Läufern mit Staffelholz nachzueifern. Es gibt keine feste Grenze Beckenrand, sondern die Übergabe wird mit dem Staffelholz ausgehandelt. Der Teamerfolg steht im Vordergrund, nicht die Leistung eines Einzelnen.

Wo können Sie den Staffelstab in Ihren Projekten einsetzen und eine feste Grenze verschwinden lassen?

In komplexen Projektumgebungen oder größeren Organisationszusammenhängen hilft die Suche nach einfachen Fehlerursachen nicht. Fehler und Probleme haben meist einen systemischen Charakter, d.h. sie lassen sich nicht auf eine einzelne Ursache zurückführen, und unmittelbar ersichtliche Gründe für einen Fehler sind selten dessen tiefere Ursache. Ist man sich dessen bewusst und sucht nicht einfach nach Schuldigen, sondern nach einer Lösung von Problemen, so kann die Fragetechnik der 5 Why’s weiterhelfen. Die Idee dazu stammt aus dem Toyota Production System und ist im gleichnamigen Standardwerk zur Lean Production von Taiichi Ohno beschrieben. Dieses bereits 1990 ersterschienene Buch ist 2009 in deutscher Fassung heraus gekommen. Das Lesen lohnt sich - nicht nur für Manager in der Automobilindustrie.

Haben Sie sich bei einem Problem oder Fehler schon einmal fünfach hintereinander gefragt, warum der Fehler aufgetreten ist? Ohno veranschaulicht dieses Vorgehen in seinem Buch an einem Beispiel aus der Automobilindustrie:

“Warum hat die Maschine angehalten?
Es hat eine Überlastung gegeben, und die Sicherung ist durchgebrannt.
Warum ist eine Überlastung aufgetreten?
Das Lager war nicht ausreichend geschmiert.
Warum war es nicht ausreichend geschmiert?
Die Ölpumpe hat nicht genügend gepumpt.
Warum hat sie nicht genügend gepumpt?
Die Welle ist ausgeschlagen und rattert.
Warum ist die Welle ausgeschlagen?
Es war kein Sieb angebracht, und deshalb gerieten Metallsplitter in die Maschine.”

Doch auch in Zusammenhängen von IT-Projekten und Turnarounds überzeugt diese einfache Technik durch ihre Wirkung. Ein Beispiel:
Warum sind so viele Fehler noch im Produktionssystem aufgetreten?
Die Entwickler und Tester hatten keine ausreichende Möglichkeit zur Qualitätssicherung.
Warum hatten sie keine ausreichende Möglichkeit zur Qualitätssicherung?
Sie hatten zu wenig Zeit und vor allem waren die Anforderungen nicht klar.
Warum waren die Anforderungen nicht klar? (hier wird nur ein Pfad verfolgt, die zweite Frage nach der Zeit wäre auch zielführend)
Das Dokument, in dem sie beschreiben sind, ist zu groß und völlig unübersichtlich.
Warum ist das Dokument so groß und völlig unübersichtlich?
Entwickler, Tester und Leute aus dem Produktmanagement setzen sich zu wenig zusammen und sprechen miteinander.
Warum sprechen sie nicht miteinander während der Erstellung der Anforderungspezifikation?
Das ist in unserem Prozess so nicht vorgesehen. Dafür hat niemand Zeit.

Ich selbst nutze diese Technik für Kernprobleme, die mir in Turnarounds auffallen. Alleine der Weg, durch den einen die Fragerei führt, ist interessant und legt Möglichkeiten zur Veränderung offen. Wo sind Probleme, Fehler oder Knackpunkte in Ihrem Projekt oder Unternehmen? Welche Antworten liefern die 5 Why’s in Ihrem Team?

Warum haben Sie die Technik der 5 Why’s noch nicht eingesetzt?
….

„Wenn wir wüssten, was wir alles wissen!“ Gelingendes Wissensmanagement ist ein zunehmend wichtiger Baustein für den Erfolg von Unternehmen. Um vorhandenes und neues Wissen zu sammeln, im Unternehmen zugänglich zu machen und systematisch zu verteilen, gibt es eine ganze Reihe von Methoden: Knowledge-maps, Checklisten, FAQs, Planspiele, Kreativitätstechniken, Mentorensysteme, Manöverkritik, Lessons Learned usw.

Im Projektmanagement werden häufig Projektberichte dazu genutzt, die „gelernten Lektionen“ an Andere weiterzugeben. Das ist eine an sich gute Idee – wäre da nicht das Problem, dass diese Berichte von den KollegInnen häufig ignoriert werden. Das Wissen aus den Projekten bleibt somit in Schubladen oder Datenbanken verschüttet. Die Frage ist also: Wie muss dieses Wissen aufbereitet werden, damit andere MitarbeiterInnen es annehmen und in ihren Projekten nutzbar machen? Die Antwort lautet: Machen Sie Geschichten daraus! Mitreißende, amüsante, spannende – vor allem: anschauliche – Geschichten motivieren zum Lesen und zu einer Auseinandersetzung mit den Inhalten. Und sie führen dazu, dass das Wissen haften bleibt, denn lebendige Bilder prägen sich besser ein als bürokratischer Text.

Dass die Verbindung von Story Telling und Lessons learned funktioniert, zeigt eine Studie von Shad Morris (Ohio State University) und James B. Oldroyd (SKK Graduate School of Business, Seoul), deren Ergebnisse in der aktuellen Juni-Ausgabe des Harvard Business Manager vorgestellt werden. Sie untersuchten die Einführung des Programms „Smart Lessons“ bei der International Finance Corporation (IFC) der Weltbank und fanden heraus, dass dieses den Wissensstand der IFC-MitarbeiterInnen „dramatisch verbesserte“. Die ProjektmanagerInnen wurden angehalten, ihre Erfahrungen in menschliche Geschichten zu verpacken, mit denen die Anderen direkt etwas verbinden konnten, und diese dann online zu stellen. Die Autoren stellten sich dabei mit einem Foto, einer Kurzvita und ihren Interessensgebieten vor. Das Programm war so erfolgreich, dass die Smart Lessons mittlerweile zu einem festen Bestandteil des Projektmanagements am IFC geworden sind. Tolle Sache!

Sicherlich kennt sie jeder von Ihnen. Auch mir begegnen sie immer wieder, wenn ich ein neues Projekt oder ein Interimsmanagement beginne: Flaschenhälse. Flaschenhälse können Maschinen oder Datenbanken sein, die in einem Web-System nicht ausreichend Traffic zulassen und die Anzahl der möglichen User eines Systems und der bearbeitbaren Requests begrenzen.

Auch Einzelpersonen oder Teams können Flaschenhälse sein. Architekten, die verspätet Architekturschablonen vorlegen, können das ganze restliche Team bremsen. Ein Zulieferer, der seine Komponenten verspätet bereitstellt, sorgt dafür, dass ein ganzes Projekt verzögert wird. Und nicht zuletzt können Manager wie ich Flaschenhälse sein, wenn sie notwendige Entscheidungen verspätet treffen.

Nun kann man sich über offensichtliche Flaschenhälse in Systemen beklagen und die Tatsache, dass es sie gibt, als unabänderlich hinnehmen.

Doch wie ist es mit der Idee, die Kenntnis von Flaschenhälsen produktiv zu nutzen? Hier hilft eine allgemeine Managementmethodik weiter, die auf Goldratt zurückgeht und “Theory of Contsraints” heißt. Goldratt hat in ihr u.a. einen kontinuierlichen Verbesserungsprozess zur Optimierung von Systemen (Produktionsanlagen, Hard-und Softwaresysteme aber auch Beziehungsgeflechte von Menschen wie Projekte) vorgeschlagen. Seine Ideen greifen weiter, aber allein der folgende fünfstufige Prozess hat mir geholfen, Flaschenhälse nicht mehr als Ärgernis, sondern als Chance zu begreifen.

1. Identifiziere den Flaschenhals im System; die ganze Kette ist nur so stark wie ihr schwächstes Glied. Ich stelle mir zu Beginn eines Projektes, insbesondere bei Turnarounds die Frage: Wo ist der wichtigste beschränkende Faktor, der einen optimalen Output verhindert?

2. Nutze das schwächste Glied, den Flaschenhals optimal. So kann man z.B. einem Architekten einen Technical Writer oder einem Manager einen Assistenten zur Verfügung stellen, um seine Kernkompetenz verstärkt ausnutzen zu können.

3. Passe die Arbeitsrate des Gesamtsystems dem Flaschenhals an. So können zum Beispiel Prioritätsverschiebungen im Gesamtsystem verhindern, dass sich vor dem Flaschenhals unnötig Arbeit und Unerledigtes anhäuft, denn das ist ohnehin Blindleistung, die nicht verarbeitet werden kann.

4. Erweitere die Kapazität des Flaschenhalses. Beispiele sind das Hinzustellen weiterer Hardware oder das Einstellen zusätzlicher Manager, die notwendige Entscheidungen treffen können.

5. Beginne wieder bei 1. Wenn der bisherige Flaschenhals behoben wurde, so begrenzt der nächste Engpass das System und sollte behoben werden.

Und wann gehen Sie auf die Suche nach den Flaschenhälsen in Ihrem Arbeitsumfeld? Haben Sie schon Ideen für die Schritte 2-4?