Barrikaden überwinden

Die meisten Teams sind nach dem klassischen Modell strukturiert. Das heißt, dass die Rollen innerhalb des Teams fest vergeben sind. Da gibt es den Teamleiter, der die Marschrichtung vorgibt, Aufgaben verteilt und verantwortlich ist für die Entscheidungsfindung. Unter ihm gibt es Entwickler, die sich auf Technologien beziehungsweise Bereiche spezialisiert haben. So wird bei der Programmierung der Oberfläche immer der Entwickler Hans mit der Umsetzung betraut und die Implementierung im Backend wird vom Kollegen Alfred übernommen. Integrationstests führt Kollegin Hermine routiniert durch. So hat jeder seine Aufgabe und Nische. Die Verantwortungsbereiche sind klar definiert. Jeder kennt sich in seinem Bereich wunderbar aus. Das nächste Projekt kann kommen.

Dieser Ansatz ist bewährt. Er gibt den Beteiligten Sicherheit, da die Grenzen, in denen man sich bewegt, klar definiert sind. Diese Grenzen können jedoch auch dazu führen, dass Teammitglieder ein bisschen einrosten und ihr Potenzial nur zu einem geringen Teil nutzen.

In [1] wird die Geschichte eines Krankenhauspflegers geschildert, der ein Unternehmen zur Krankenpflege in Holland gegründet hat, welches inzwischen 9000 Pflegekräfte beschäftigt. Diese sind in Teams von zehn bis zwölf Mitarbeitern organisiert, die ohne Teamleiter innerhalb des Teams und ohne Manager auf übergeordneter Ebene auskommen.

Die Zufriedenheit spricht sich in der Branche so herum, dass jeden Monat Hunderte Bewerbungen von Pflegekräften beim Unternehmen eintreffen.

Wo ist aber bitteschön die Verbindung von den Pflegekräften zu Softwareentwicklern, die sich doch bitte mal ausschließlich mit technologischen Herausforderungen oder Algorithmen beschäftigen sollen?

Die Verbindung stellt sich mit einer Aufforderung des Managements der Firma her, in der der Autor arbeitet: Die Mitarbeiter mögen doch bitte experimentieren und neugierig bleiben. Damit war der Freiraum zur Selbstorganisation geschaffen und das Experimentierkästchen geöffnet.

Die Experimente waren unterschiedlicher Art. Das erste war eine Feedback-Runde innerhalb des Teams. Jeder sollte einem anderen Kollegen Rückmeldung geben. Was sich von der Phase der Vorbereitung bis kurz vor Beginn als sehr ungewohnt angefühlte, stellte sich dann als äußerst wertvoll heraus. Wer hätte gedacht, dass Menschen, die primär über Filme wie „Matrix“ miteinander kommunizieren, in der Lage sind, Lob auszusprechen und Kollegen dort zu berühren, wo es darauf ankommt: im Herzen?

Das mag sonderbar klingen, ist es vermutlich auch, wurde jedoch gut aufgenommen. Die Auswirkungen auf den Team-Spirit waren auf jeden Fall deutlich zu spüren.

Um das permanente Lernen zu unterstützen, das in der Branche der Softwareentwicklung zwingend ist, wurde ein Experiment ins Leben gerufen, bei dem Domain Driven Design genauer unter die Lupe genommen wurde. Interessierte fanden sich hierbei zu einem Team zusammen.

Als Ziel wurde festgelegt, ein Projekt mittels DDD umzusetzen und das während dieses Prozesses gesammelte Know-how in die Firma zurückfließen zu lassen. Hierbei war ein etwas höheres Maß an Engagement nötig, da der Großteil des Aufwands in der Freizeit erfolgte. Der Einsatz und die langen Abende vor dem Computer brachten aber den gewünschten Erfolg. Es kam zu tollen Diskussionen und es konnte in einem ungezwungenen Rahmen etwas probiert werden.

Accountability-Partnerschaften [2] und dem Partner zugesagte Termine sorgten dabei für den nötigen Druck, ohne den manche Aufgaben wohl im Sande verlaufen wären. Nur durch den Druck, eine Zeitplanung, Milestones und die Präsentation seiner Ergebnisse vor den anderen Teilnehmern wurden die Ziele erreicht. Sie waren maßgeblich verantwortlich für den Erfolg.

Im dritten Experiment wagten die Entwickler einen Blick in die Glaskugel. Hierbei versetzte sich das Team in Gedanken drei Monate in die Zukunft und überlegte, wie die vergangenen drei Monate im optimalen Fall verlaufen sein sollten. Aus diesen Ergebnissen konnten Ziele definiert und für deren Erreichung konkrete Aktionen hergeleitet werden.

Wie in [3] beschrieben repräsentiert die Retrospektive einen geschützten Raum, in dem sich das Team austauscht und offen über wirklich alles sprechen kann. Diese angstfreie Zone sollte es allen Teammitglieder leicht machen, ihre Vorschläge für Experimente wie oben beschrieben anzusprechen. Es können tolle, eventuell ungewohnte Vorschläge besprochen werden, die das Team und somit das Unternehmen voranbringen können. Folgende Regeln sind dabei unerlässlich:

Die Erfahrung des Autors ist, dass eine selbstorganisierte Teamkultur zu einem sehr schnellen Austausch von Neuem führen kann.

Neben den zwischenmenschlichen Erfahrungen wie dem geschilderten Experiment der Feedback-Runde kommt auch die technische Weiterentwicklung des Teams nicht zu kurz. Neues wird angesprochen, untersucht und findet gegebenenfalls schnell den Einsatz im täglichen Business.

Durch diese Art der Einflussnahme durch das Team nimmt die Attraktivität der Arbeitsstätte zu. Der Raum zur persönlichen Entfaltung, der Voraussetzung für die Zufriedenheit ist, ist gegeben.

Jedoch sollte erwähnt werden, dass diese Art der Arbeit nicht unbedingt für jeden passend ist. Auch der klassische Ansatz mit festen Rollen hat seine Daseinsberechtigung. Dies ist sicherlich eine Typsache. Als Schlusssatz seien noch einige Bücher erwähnt, die uns weitergeholfen und als Inspira­tion gedient haben [4][5][6][7][8]. Und ein Beitrag in [9] hat zu einem interessanten Austausch geführt.