Wir kennen alle die berühmt berüchtigten vier Phasen der Teambildung: Forming, Storming, Norming, Performing. Wenn einer diese Worte in einem Meeting fallen lässt, dann werfe ich ihn in der Regel raus. Es geht nicht darum, Schlagworte für einen schwierigen Prozess zu finden, sondern den Sinn dahinter zu verstehen, um den Vorgang unterstützen zu können. Wenn ich wirklich weiß, wie Teams funktionieren, dann kann ich ruhigen Gewissens auch darüber nachdenken, die Zusammensetzung fröhlich zu rotieren.
Für den einen oder anderen unter Ihnen wird sich das vielleicht komisch anhören. Wir bekommen immer wieder eingetrichtert, wie wichtig es ist, stabile Teams zu bilden, und jetzt faselt der Typ davon, dass man problemlos rotieren könne. Wie soll das gehen?
Um diese eine Sache von vornherein klarzustellen: Selbstverständlich wollen wir Stabilität in unseren Entwicklungsteams. Kein Mensch – auch ich nicht – wird Ihnen jemals empfehlen, ein Team, das sich gerade findet, wieder auseinanderzureißen. Es sei denn, dass Ihnen schon zu einem sehr frühen Zeitpunkt klar ist, dass die Teamzusammensetzung nicht funktioniert, weil die Kollegen entweder fachlich oder menschlich nicht zueinander passen.
Solche Fälle gibt es natürlich. Ein neuer Kollege macht während des Vorstellungsprozesses einen umgängliche Eindruck, entpuppt sich bei genauerer Betrachtung und in der täglichen Zusammenarbeit jedoch als unausstehliches Arschloch. Oder ein paar Kollegen haben so große menschliche Differenzen, dass diese sich nicht mehr ausräumen lassen. Es kann auch sein, dass ein Team fachlich nach bestimmten Anforderungen zusammengesetzt wurde, der Scope der Anwendung sich aber soweit verschiebt, dass sich diese fachliche Anforderung auch stark verändert.
Es gibt zahlreiche Gründe, warum wir gezwungen sein können, Teams zu überdenken. Darauf möchte ich heute aber nicht hinaus. Ich möchte mit Ihnen ein paar Gedanken zu dem Thema teilen, welche Möglichkeiten wir haben, wenn wir alles richtig gemacht haben.
Ich habe die Erfahrung gemacht, dass der Teambildungsprozess sehr vorsichtig begleitet werden sollte. Wir arbeiten mit vernunftbegabten und sozialisierten (auch wenn bei Softwareentwicklern die Meinungen zu diesem Punkt geteilt sind) Menschen zusammen, die ein natürliches Bestreben haben, eine Gemeinschaft zu bilden. Das haben alle (oder fast alle) Menschen gemeinsam: wir wollen uns in Gruppen organisieren. Da es dieses natürliche Streben gibt, und da die meisten Menschen die dafür nötigen Fähigkeiten mitbringen, müssen wir in der Regel sehr wenig tun, diesen Prozess zu steuern. Verabschieden Sie sich vor allem von dem Gedanken, dass Sie diese Sache beschleunigen könnten.
Selbstverständlich werden zahlreiche Seminare, Coachings und Trainingsmaßnahmen angeboten (von denen ich im allgemeinen nicht sehr viel halte – Ausnahmen bestätigen die Regel). Diese sind aber vor allem dazu geeignet, Konflikte und Störungen zu betrachten. Auf die »natürliche« Teambildung – das Kennenlernen und das Aufstellen von unausgesprochenen Regeln – haben sie nur sehr wenig Einfluss. Ein guter Scrum-Master hat jedoch seine Möglichkeiten, diese Dinge zu beeinflussen, und damit meine ich nicht die Retrospektive-Keule. Die ist für die Regeln der Zusammenarbeit gedacht. Grundlage hierfür ist jedoch die menschliche Komponente – Sozialisation, Kultur, Charaktereigenschaften. Ein guter Scrum-Master achtet nicht nur darauf, dass Scrum funktioniert, er hat auch ein sehr feines Gespür für die Befindlichkeiten der Teammitglieder.
Er sollte bemerken, wenn es irgendwo ein Sender-Empfänger-Problem gibt, oder anders gesagt: er sollte es bemerken, wenn jemand die Aussage eines Anderen in den falschen Hals bekommt. Dann kann er für Klärung sorgen, bevor ein Konflikt entsteht. Er kann sehr fein Gemeinsamkeiten herausarbeiten und fördern. Man kommt dann ein wenig in den Counselor-Troi-Modus.
Dieser Aspekt der Tätigkeiten eines Scrum-Masters erfordert sehr viel Erfahrung, eine ausgezeichnete Menschenkenntnis (die eine oder andere Form einer psychologischen Schulung kann auch nicht schaden), und vor allen Dingen sehr viel Fingerspitzengefühl. Drängt man sich zu sehr auf, und es entsteht der Eindruck, dass man sich zu tief in die sehr persönlichen Dinge einzelner Personen einmische, dann erzielen sie nur den Effekt, dass Sie selbst zum störenden Faktor in der Teambildung werden.
Aber ich schweife ab. Gehen wir einmal davon aus, dass Sie als Scrum-Master sehr geschickt und sehr zurückhaltend vorgegangen sind. Ihr Team versteht sich gut, hat seinen eigenen Modus gefunden und wird richtig produktiv. Alles scheint damit im grünen Bereich zu liegen. Spätestens jetzt – aber eigentlich schon viel früher – ist der Zeitpunkt gekommen, an dem wir über den Tellerrand hinaus blicken müssen (es sei denn wir sprechen nur von einem Entwicklungsteam im Unternehmen). Haben wir mehrere Entwicklungsteams, ist es auch die Aufgabe der Scrum-Master, Kommunikation und Kooperation über Teamgrenzen hinaus zu fördern. Glauben Sie mir: die Standardzeremonien wie das Scrum of Scrums reichen dafür nicht aus.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Wir benötigen wahrscheinlich einen gemeinsamen Styleguide, eine gemeinsame Definition of Done, ein gemeinsames Verständnis von Testing und viele Dinge mehr, die nicht ein Team allein für sich definieren sollte. Vor allen Dingen benötigen wir eine gemeinsame Sicht auf das Produkt, weil sich die Silos, die wir sonst bilden auch im Produkt widerspiegeln. Die Erfahrung für den Anwender wird darunter leiden.
Wir bringen also immer wieder sowohl Entwickler als auch Product Owner an einen Tisch, wobei nicht immer jeder an jedem Meeting teilnehmen muss. Es können auch immer nur einzelne Vertreter eines Teams teilnehmen, wenn man sich vorher innerhalb des Teams verständigt hat.
Wenn es uns gelungen ist, dass alle Teams ein gleiches Verständnis vom Vorgehen, von der Codequality usw. haben, dann haben wir keine einzelnen voneinander getrennten Teams sondern eine größere Menge an Entwicklern, die nur in Teams unterteilt ist. Das ist ein wichtige Unterschied. Kennen sich alle Beteiligten gut, weil man oft miteinander spricht, haben alle ein gemeinsames Grundverständnis von allen zentralen Punkten, kommen wir in die Situation, dass wir problemlos die Teamzusammensetzungen ändern können, um z.B. zeitlich begrenzte Special-Teams zu bilden. Das kann für rein technische größere Anforderungen durchaus sinnvoll sein, wenn die gesamte Anwendung auf eine neue Software-Version gehoben werden muss. Das könnte man an ein Team geben, um es für einen längeren Zeitraum komplett zu blockieren. Es wird dann für mehrere Sprints nicht in der Lage sein, Features an Kunden auszuliefern. Man könnte es aufteilen und alle Teams übernehmen einen gleich großen Teil der anfallenden Aufgaben oder kümmern sich um ihren jeweiligen Heimatbereich. Unter Umständen – je nach Aufgabenlage – langweilen sich dann die Frontender. Oder man bildet eben ein Special-Team mit Vertretern aller Teams, die für die anstehende Aufgabe besonders geeignet sind (oder sich freiwillig melden).
Der Vorteil bei diesem Vorgehen ist, dass die eigentlichen Teams weiter an Features arbeiten können (wenn auch mit reduzierter Stärke), während sich das Special-Team fokussiert seiner Aufgabe widmen kann. Wir müssen dann schlussendlich nur noch entscheiden, ob dieses Special-Team nach Scrum vorgeht, mit einem PO und allen Zeremonien, oder ob es in einem Kanban-Modus vielleicht besser aufgehoben ist. Dafür möchte ich keine allgemeingültige Empfehlung geben. Bei einem klar umrissenen sehr techniklastigen Thema ist es durchaus möglich, dass kein Product Owner im klassischen Sinne gebraucht wird. Vielleicht bietet es sich auch an, dass einer der Entwickler diese Rolle übernimmt, weil er sowieso am besten weiß, was alles zu tun ist. Als Scrum-Master sollten sie dieses Team dennoch begleiten. Sorgen Sie dafür, dass es alles hat, um ungestört und effizient arbeiten zu können. Das kann auch beinhalten, dass es einen eigenen Raum benötigt, um zusammen sitzen zu können, was für die Kommunikation im Team sowieso sinnvoll ist.
Auch wenn sich alle bewusst dafür entschieden haben, nicht im Scrum-Modus zu arbeiten, werden Sie als Scrum-Master dennoch benötigt. Sie führen moderierend durch die Meetings und beraten Ihre Kollegen in den Abläufen. Sie sind dann zwar kein Scrum-Master aber dennoch organisierender und moderierender Teil des Teams. Nicht zuletzt sind Sie auch eine Schnitstelle nach außen.
Unsere Aufgaben sind vielfältig und keinesfalls leichter als in Scrum. Der Fokus liegt darauf, die Frage zu beantworten, wann das Team fertig ist und sich wieder auflösen kann. Wie gelangen gewonnene Erkenntnisse in die übrigen Teams? Wie halten wir die anderen Teams, Product Owner und Stakeholder im Loop? Ein Special-Team kann für den Nicht-Scrum-Master eine sehr herausfordernde Aufgabe sein. Wenn wir in der Teambildung jedoch alles richtig gemacht haben, dann werden wir feststellen, dass sich temporäre Teams sehr schnell finden, sehr schnell einen passenden Modus erarbeiten und sehr schnell zu einer hochproduktiven Einheit verschmelzen können, von der jeder weiß, dass sie nur für einen kurzen Zeitraum Bestand hat. Alle kennen sich, alle haben eine gemeinsame Grundvorstellung, alle haben bisher nach ähnlichen Regeln gearbeitet. Haben wir dafür gesorgt, dann sind temporäre Teams kein Problem.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
