Freitag, 3. Juli 2015

Vom Sprint zum Überblick. Durchblick kommt nicht von allein.

Ordnung ins Chaos

Artikelübersicht
1. Teil Gegenseitige Hilfe ersetzt Chaos.
2. Teil Ein Held, der sich helfen lässt.
3. Teil Teambullshit oder wirkliche Teams. Mit dem Team gegen das Chaos.
4. Teil Vom Sprint zum Überblick. Durchblick kommt nicht von allein.


Im letzten Post habe ich beschrieben, wie sich ein kleines Team selbst organisieren kann. Die Abarbeitung der Aufgaben in Sprints, die eine, zwei oder vier Wochen dauern, gewährleistet eine effektive Arbeitsweise, mit der man auf kurzfristige Änderungen reagieren kann. Außerdem wird die Arbeit so zu einer Kette von Erfolgserlebnissen, die alle zwei Wochen ein neues und erweitertes Produkt präsentieren. Der Arbeitsfortschritt wird transparent. Es ist ein bisschen vergleichbar mit dem Ernten eines 100 Hektar großen Kartoffelackers. Die schiere Größe der abzuerntenden Fläche raubt uns den letzten Nerv oder sie lässt uns verzweifeln. Unterteilen wir die Fläche in kleinere Parzellen, wird jede einzelne Ernteaufgabe in absehbarer Zeit zu bewältigen sein. Wir stecken 10 x 10 m Parzellen ab und ernten eine nach der anderen ab. Unsere Motivation aufgrund der Kette von Erfolgen steigt enorm. Ein ähnliches Prinzip verwenden erfolgreiche Computerspiele, um ihre Spieler süchtig zu machen.

Ein weiterer Vorteil dieser Arbeitsweise ist das schnelle Umsteuern eines Projektes. Mit einer Verzögerung von einem Sprint kann die Richtung korrigiert werden. Ein Projekt muss nicht in Stein gemeißelt sein. Kann ein Kunde auf diese Flexibilität eingehen, genießt er ungeahnte Vorteile durch diese Arbeitsweise. Haben wir im Team eine Sprintdauer von zwei Wochen vereinbart, wird alle zwei Wochen ein Sprintrelease erzeugt. Dieses kann dem Kunden testweise zur Verfügung gestellt werden. Über den Testzugang kann er Funktionalität ausprobieren und so frühzeitig feststellen, wie gut oder schlecht er mit der Software arbeiten kann. Die Software muss kein Überraschungspaket am Ende einer monate- oder jahrelangen Entwicklung sein.

Den Vorteilen dieser Arbeitsweise in Sprints und Teams stehen auch Nachteile gegenüber, wenn man es nur auf diese kurzfristigen Erfolge absieht. Ein Management, welches schon früher nur Aufgaben verteilt hat, dürfte nun froh darüber sein, die Verantwortung für das Steuern von Projekten ganz an die Teams abgegeben zu haben. So wie früher die Kommunikation zwischen einzelnen Mitarbeitern notwendig gewesen wäre, so ist nun auch die Kommunikation zwischen den Teams notwendig. Dabei ist die wichtigste Aufgabe zu erkennen, worüber und wie die Teams kommunizieren sollten.

In der objektorientierten Programmierung werden Daten und Verhalten gekapselt. Wir verbergen Implementierungsdetails und legen nur Schnittstellen offen. Über diese vereinbarten Schnittstellen läuft die Kommunikation mit anderen Objekten. Wie das Verhalten im Einzelnen programmiert wurde, ist uns ziemlich egal, außer die Antwort benötigt unverhältnismäßig viel Zeit oder sie ist falsch. Solange die Methoden der Schnittstelle das liefern, was sie sollen, interessiert uns der Rest nicht.


In der Kommunikation zwischen den Teams gilt es also Aufgaben zu finden, die über den Teams stehen und über die sie kommunizieren müssen. Außerdem ist die Art und Weise der Kommunikation festzulegen. Gibt es überhaupt solche übergreifenden Aufgaben? In einem Betrieb mit einem Entwicklerteam gibt es solche Aufgaben nicht. In einer Firma mit mehr als einem Team, welche an ähnlichen Technologien arbeiten, gibt es solche Aufgaben sehr wohl. Stellen wir uns vor, jedes dieser Teams entwickelt eine spezifische Webanwendung. Jedes Team verwendet die gleiche Technologie. Jede Anwendung implementiert eine eigene Benutzerverwaltung. Solche übergreifenden Aufgaben können auf mehrere Teams verteilt werden. Das eine Team entwickelt die Benutzerverwaltung, ein anderes Team ein spezifisches Logging, andere Teams können spezielle UI-Komponenten entwickeln. Jedes Team stellt nun die Früchte seiner Arbeit der Firma zur Verfügung.

Schon haben wir die Notwendigkeit von Kommunikation über die Teamgrenzen hinweg. Ausführliche Dokumentationen zu den Modulen sind notwendig. Einführende Vorträge müssen gehalten werden, Mitarbeitern muss in Weiterbildungen nahegebracht werden, die gemeinsamen Module zu verwenden. Ohne Kommunikation bleiben gemeinsame Module eine Absichtserklärung. Neben diesen entsteht trotzdem eine Vielfalt eigener Teamentwicklungen. Man beschränkt sich immer auf die Ebene der Kommunikation und Information, die man beherrscht. Gibt es keine einfache Informationsweitergabe zwischen den Teams, wird diese auch nicht genutzt. Die Lehre daraus ist, die Masse der fließenden Information auf ein Minimum zu beschränken. Dieses Minimum muss das Wesentliche sein.

Zu diesen wesentlichen Dingen gehören Prozessmodelle für die Entwicklung von Anforderungsspezifikationen, Vorgehensmodelle zur Aufgabenabarbeitung und der Ortung von Verantwortlichkeiten sowie Regeln für den Aufbau von Softwarearchitekturen. Für diese Aufgaben kann es Arbeitsteams geben, die über dem Team stehen. Einzelne Personen in den Teams können sich in ganz spezifischen Rollen ein hohes Wissen aneignen. Es kann Spezialisierungen in Richtung Projektmanagement, Requirements Engineering, Usability Engineering oder Softwarearchitektur geben. Diese Spezialisten haben einerseits die Aufgabe, sich ständig in ihrem Wissensgebiet weiterzuentwickeln, auf der anderen Seite müssen sie dieses Wissen aufgearbeitet in das Team tragen. Die Kommunikation zwischen den Teams erfordert, dass sich diese Spezialisten in Arbeitsgruppen zusammenfinden. Dort entwickeln sie firmenweite Standards für das Projektmanagement, für das Requirements Engineering, das Usability Engineering und die Softwarearchitektur.



Sicherlich fallen Ihnen andere Themengebiete ein, zu denen eine Zusammenarbeit zwischen den Teams notwendig wäre. Begrenzen Sie diese Aufgaben jedoch auf das notwendige Minimum, erhalten Sie eine größtmögliche Autonomie für das Team, ohne sinnlosen Doppelarbeiten Tür und Tor zu öffnen. Der Gewinn der Kommunikation zwischen den Teams muss größer sein, als der Verlust durch die Kommunikation. Eine Diskussion, ein Austausch zwischen Spezialisten ist in jedem Fall ein Gewinn, genauso wie gemeinsame Standards, die für lange Zeit Gültigkeit besitzen. Eine weitere wichtige Aufgabe solcher Institutionen außerhalb der Sprints, ist es zurückzutreten und den Esel beim Lauf zu beobachten.

Einmal beschlossene Prozesse verselbstständigen sich. Sie werden zu wenig auf ihren Sinn hin untersucht. Allein die Länge ihres Bestandes soll ihren positiven Charakter beweisen. Ein Beweis im Sinne vernunftbegabten Denkens ist das jedoch nicht. Dazu benötigen wir Regelkreise, in denen wir diese Prozesse beobachten. Zu den einzelnen Arbeitsschritten und den anzufertigenden Artefakten sollten messbare Größen gefunden oder im Team abgestimmte Einschätzungen getroffen werden. Diese Messergebnisse und Wertungen sollten die Grundlage für das Weiterbestehen oder das Abschaffen solcher Arbeitsschritte und Artefakte sein.

Diese übergreifenden Teamstrukturen bilden die Grundlage für langfristiges Denken und Planen. Sie erlauben innezuhalten, Dinge zu überdenken, dem täglichen Arbeitslauf Struktur zu geben. Diese kann im ausschließlichen Tagesgeschäft leicht verloren gehen. Ich behaupte, sie geht in jedem Fall verloren, wenn man nichts weiter als Tagesgeschäft kennt. Ein gutes Management muss die Strukturierung zwischen diesen kurz- und langfristigen Aufgaben beherrschen. Es dient der Schaffung von Kommunikationsstrukturen, dem Aufrechterhalten des Aufgabenflusses sowie der Spiegelung des Gesamtprozesses. Ein schlechtes Management macht Druck auf schlecht geschaffene Strukturen oder sitzt alles nur aus. Ein gutes Management sorgt für funktionierende Strukturen und kennt seine dienende Aufgabe.

vorheriger Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen