In der Vielzahl der Publikationen finden Sie überall die Beschreibung der Regeln und Artefakte. Meistens bleibt das sehr theoretisch, weil es nur schwer ist, alle möglichen Fälle und Probleme bei der Einführung von Scrum in Ihrem Unternehmen zu berücksichtigen. Auch ich kann an dieser Stelle unmöglich umfassend Auskunft geben (wenn Sie Rat suchen, sprechen sie mich an), aber ich kann hier einen Punkt herauspicken, der immer wieder Schwierigkeiten bereitet: Die Etablierung von Scrum im Team.
In den zukünftigen Wochen werde ich diese Thematik sicherlich noch vertiefen, wenn ich andere Aspekte der Einführung Agiler Methoden im Unternehmen betrachte, aber heute möchte ich mich ausschließlich mit dem Entwicklungsteam und den Dingen beschäftigen, die uns dort begegnen können.
Wir gehen davon aus, dass bereits ein Product Owner bestimmt wurde, und dass man sich auf einen Scrum Master geeinigt hat. Und schon hier könnten Sie den ersten Problemen begegnen. Sehr oft wird der Product Owner von der Geschäftsführung oder dem Entwicklungsleiter bestimmt und dem Team vorgesetzt. Vergessen Sie dabei nicht, dass Entwicklungsteam und PO sehr eng zusammenarbeiten müssen, und dass die Rolle des Product Owners nicht der eines Vorgesetzten im klassischen Sinne entspricht (zum Teil irgendwie schon, aber das ist ein anderes Thema). Den Idealzustand erreichen wir, wenn alle vertrauensvoll und auf Augenhöhe miteinander sprechen können. Dazu ist es natürlich am besten, wenn ich das Team in den Auswahlprozess miteinbeziehe, aber hier kommen wir zum Kern aller Probleme: Was tun, wenn das Team nie gelernt hat, Verantwortung zu übernehmen und Entscheidungen zu treffen?
Alle Probleme, auf die Sie bei Einführung von Scrum in Ihrem Team stoßen werden, sind letztlich darauf zurückzuführen (sehen wir mal von persönlichen Animositäten ab). Wenn Scrum (oder andere Agile Methoden) in einem Unternehmen scheitert, spricht man hinter vorgehaltener Hand gern von Widerständen und verweist dabei auf eine Geschäftsleitung oder andere Vorgesetzte, die nicht bereit waren, Kompetenzen an das Entwicklungsteam oder den Product Owner abzutreten. Gelegentlich hat der Zusammenbruch jedoch auch seine Ursache in einem Team, das es nicht gelernt hat, sich von der Rolle des reinen Befehlsempfängers zu befreien.
Grundsätzlich begegnen mir bei der Zusammenarbeit mit dem Entwicklungsteam drei Klassen von Problemen:
1. Das Team ist übermotiviert und euphorisch, weil sich jetzt alles ändert, und schießt übers Ziel hinaus.
2. Das Team hat sich an eine strenge Hierarchie (mit mehr Druck als Lob) gewöhnt und weist indirekt jede Verantwortung von sich.
3. Das Team nutzt die scheinbare neu gewonnene Freiheit schamlos aus und entdeckt eine neue Kultur des leichten Lebens und der Faulheit.
All diese Dinge sich schwer zu erkennen und noch viel schwerer zu beseitigen, weil wir hier direkt an die charakterlichen Eigenschaften der Personen stoßen, mit denen wir zusammenarbeiten. Noch schwerer wird es, weil sich diese Dinge manchmal mischen und Sie in einem Entwicklungsteam mit etwas Pech alle drei Problemklassen finden können.
Sie kommen diesen Dingen nur auf die Spur, indem Sie selbst ganz eng an den Leuten bleiben. Burndown-Charts, Sprintprotokolle und andere Auswertungen sagen Ihnen lediglich, dass Irgendetwas nicht funktioniert, lassen die Gründe dafür jedoch im Dunkeln. Auch in Gesprächen kommen Sie nicht wirklich voran, weil selbstverständlich alle jede Schuld von sich weisen und den Schwarzen Peter nur zu gern einem anderen in die Schuhe schieben. Der einzige Weg, wirklich verlässlich herauszufinden, was im Team nicht läuft, ist die Beobachtung. Wenn man bei jedem Meeting dabei ist, wenn man sieht, wie die Kollegen tagtäglich arbeiten, hat man genug Einblick, um seine Schlüsse zu ziehen und die geeigneten Maßnahmen zu ergreifen.
Ein sicheres Zeichen dafür, dass Kollegen die Sache etwas zu euphorisch betrachten (wobei das auch unser harmlosestes Problem ist), ist das ständige Austauschen und Diskutieren. Die Gefahr dabei ist, dass wir in hoher Frequenz auf der Stelle trampeln, aber kaum voran kommen, weil wir immer wieder Richtungskorrekturen vornehmen und uns so nur im Kreis drehen. Veränderungen sollen in Scrum auch vom Team ausgehen, und wir fördern dies auch in der Retrospektive. Das will ich in keiner Weise in Frage stellen. Es ist wichtig, dass das Team an allen Entscheidungen beteiligt wird. Doch wenn wir feststellen, dass sich immer wieder einzelne kleine Gruppen oder das gesamte Team zusammensetzen, um alle möglichen Dinge zu besprechen, und dabei auch jeder zweite Satz »wir könnten mal« oder »wir sollten mal« enthält, sollten Sie sich fragen, ob das ständige Diskutieren wirklich notwendig ist. Oftmals bleiben diese Gespräche auch ohne Ergebnis, und dann sind sie schlicht und ergreifend Zeitverschwendung. Kein Meeting ohne Ergebnis – dieser Grundsatz gilt immer.
Ein übermotiviertes Team neigt dazu, Änderungen schnell vorzunehmen, sie schnell wieder zu verwerfen und durch neue Änderungen zu ersetzen. Behalten Sie hier als Scrum Master den Überblick, zum anderen den Fuß im Zweifelsfalle auf der Bremse. Wenn man eine Änderung vorgenommen hat, die man nach zwei Wochen bereits wieder verwerfen möchte, sollten Sie das nicht einfach mitmachen, sondern nachfragen und sich die Sache genau erklären lassen. Warum funktioniert es nicht? Kann es sein, dass die Sache einfach mehr Zeit braucht? Hat man sich alles im Vorfeld wirklich überlegt, oder ist man blind in Irgendetwas hineingestolpert, ohne die Folgen zu bedenken?
Übermotivieret Kollegen brauchen einen Ruhepol an ihrer Seite, der sie immer wieder fragt: Brauchen wir das wirklich? Was sind die Folgen? Was erhoffen wir uns davon? Wie viel Zeit sollten wir der Sache geben? Achten sie als Scrum Master darauf, weder zum Bremsklotz zu werden, noch alles mitzumachen, nur weil das Team es wünscht. Das erfordert Fingerspitzengefühl und Erfahrung.
Schwieriger wird Ihre Situation, wenn Sie mit Kollegen zusammenarbeiten, die gelernt und verinnerlicht haben, dass sie reine Befehlsempfänger sind. Es ist recht leicht, das zu erkennen: der Kollege beschwert sich nicht, und wenn, dann ist weniger Wille zur Veränderung als Resignation zu erkennen. Im Meeting können Sie noch so oft nach seiner Meinung fragen, bekommen aber nur ausweichende nichtssagende Antworten (oder alles mit einem gigantischen Sicherheitspuffer, damit man sich keinen Rüffel für eine falsche Einschätzung einfängt). Verwechseln Sie diesen Kollegen nicht mit einem, der einfach nur etwas stiller ist und nicht zu vielen Worten neigt. Von dem einen bekommen Sie eine ehrliche Antwort, wenn Sie ihn fragen, von dem anderen nicht.
Ein Team aus Befehlsempfängern lässt den Product Owner komplett im Regen stehen. Alle Aufwandsschätzungen fallen äußerst großzügig aus, wenn Sie überhaupt eine Aussage bekommen. Oft genug heißt es nur »Müssen wir mal sehen, kann man nicht sagen«, weil jede konkrete Aussage (das hat die schmerzliche Erfahrung gezeigt) unangenehme Folgen haben kann. Wenn Sie das nicht in den Griff bekommen, arbeiten Sie als Product Owner zwar mit einem Backlog, letzten Endes aber doch wieder mit einer Top-Down-Hierarchie, in der Sie den Kollegen vorgeben, was sie zu tun haben. Mit einer Agilen Softwareentwicklung hat das nichts mehr zu tun.
Ein solches Team braucht vor allen Dingen Zeit und die wachsende Gewissheit, dass das Übernehmen von Verantwortung (und vielleicht auch ein Fehler) nicht immer gleichbedeutend mit Schlägen ist. Machen Sie als Scrum Master und Product Owner sehr deutlich, dass ein Fehler oder eine falsche Einschätzung kein Beinbruch ist. Das passiert, dafür reißt man niemandem den Kopf ab. Anfänglich wird Ihnen das zwar niemand glauben, aber durch Ihr Verhalten über einen längeren Zeitraum schaffen Sie Vertrauen. Bis Ihr Team zur echten Mitarbeit in der Lage und bereit ist, bleibt Ihnen nichts Anderes übrig als viele Dinge vorzugeben.
Der einfachste Weg, das gesamte Team zu entwickeln, ist der über einzelne Mitglieder. Es gibt immer einen, der etwas ehrlicher und mutiger ist als die anderen. Picken Sie diesen heraus und besprechen mit ihm eine Anforderung. Fragen Sie ihn nicht einfach nach seiner Meinung und tragen Sie ihm auf, sich mit einer Sache auseinanderzusetzen, besprechen Sie mit ihm die Anforderung. Erklären Sie, was Sie erreichen wollen, und warum Sie das machen, und wie Sie sich das vorstellen. Beginnen Sie ruhig damit, den Kollegen nach einer möglichen technischen Umsetzung zu fragen. Dort bewegt er sich auf sicherem Terrain. Sie werden feststellen, dass sich dieser Kollege beim zweiten, dritten vierten Gespräch schon wesentlich wohler fühlt und gelöster wird. Beginnen Sie dann, einen weiteren Kollegen hinzuzuziehen. Dieser sieht, wie gelöst und offen der erste bereits agiert. Das fördert wiederum das eigene Vertrauen in die Sache.
Den Super-GAU finden Sie in einem Entwicklungsteam aus Faulpelzen, vor allen Dingen dann, wenn Sie selbst über keinerlei Entwicklungserfahrung verfügen. Wir vertrauen unseren Kollegen, und in aller Regel ist das Vertrauen auch begründet. Wir sind jedoch nicht davor gefeit, dass sich das leichte Leben langsam einschleicht. Es ist vollkommen richtig, dass wir nicht wollen, dass sich unsere Kollegen vollkommen verausgaben und aufrauchen. Wir wollen, dass alle entspannt und konzentriert am Projekt arbeiten. Gerade in ungeliebten Projekten kann es jedoch vorkommen (und wenn es passiert, dann pflanzt es sich fort), dass einzelne Kollegen damit beginnen, Aufwände etwas großzügiger zu schätzen. Andere Kollegen machen mit; nach einiger Zeit werden die Schätzungen noch etwas großzügiger. Das alles geschieht sehr langsam und ist dadurch kaum zu erkennen. Wenn Sie selbst über keinen Entwicklerhintergrund verfügen, haben Sie kaum eine Chance. Die Auswertung der Velocity Ihres Teams hilft Ihnen jedenfalls nicht. Dafür brauchen Sie schließlich die Aufwandsschätzung. Und wenn Sie bei einer einzelnen Anforderung nachfragen, wird man Ihnen tausend gute Gründe nennen.
Bitte verstehen Sie mich nicht falsch: Den meisten Teams vertraue ich und fahre sehr gut damit. Vereinzelt gibt es jedoch immer wieder Kollegen, die das in sie gesetzte Vertrauen missbrauchen. Und diese herauszufiltern und auf den Pfad der Tugend zurückzuführen, bevor sie das ganze Team infizieren, ist nicht nur eine schwierige, sondern auch eine extrem wichtige Aufgabe.
Wenn Sie ein faules Ei im Team haben, kann dieser entweder sehr subtil und unbewusst und daher kaum merklich die Kollegen beeinflussen, oder Sie hören Formulierungen wie »wenn der das so macht, dann mache ich das jetzt auch so«. Keiner Ihrer Entwicklerkollegen sieht gern dabei zu, wenn sich ein anderer auf die faule Haut legt, und die merken das sehr schnell, glauben Sie mir. Entweder sprechen diese mit dem Kollegen, und die Sache gibt sich wieder, oder sie folgen seinem Beispiel, weil man selbst nicht der Dumme sein will. Dabei sinkt die Stimmung im Team merklich.
Das Entwicklingsteam wird den Kollegen jedoch nicht beim Scrum Master oder einem Vorgesetzten anschwärzen. Fragen Sie garnicht erst. Eine solche Sache zerstört das Vertrauen und Teamgefüge nachhaltig und unwiederbringlich. Keiner will mit einem Verräter zusammenarbeiten, und wenn Sie als Scrum Master den Verrat (mag eine harte Formulierung sein, aber ihr Team empfindet es genau so) fördern und belohnen, dann wird auch Ihnen niemand mehr Vertrauen schenken.
Sie erkennen leicht, wenn einer morgens immer der letzte und abends immer der erste ist. Darüber spricht man mal unter vier Augen, und die Sache normalisiert sich, oder man unterhält sich eben etwas ernster. Das großzügigere Schätzen von Aufwänden, die kaum spürbaren Spitzen der Kollegen untereinander in den Meetings, die subtilen Verhaltensänderungen bemerken Sie nur, wenn Sie selbst Entwickler sind oder waren. Haben Sie den verdacht, dass Ihr Team langsam kippt, holen Sie sich Hilfe, vielleicht bei einem erfahrenen Kollegen (oder fragen Sie mich).
Vermeiden Sie eine Stimmung des Misstrauens oder allgemeine Paranoia. Die meisten Teams machen einfach ihren Job und missbrauchen das in sie gesetzte Vertrauen nicht. Es ist auch vollkommen normal, dass ein Entwickler zwischendurch mal durch einen Blog stöbert und sich einen Kaffee holt. Es ist eine weiche Grenze zwischen normal und zu viel.
Genau so schwierig wie das Erkennen ist auch das Gegensteuern. Druck und Kontrolle zwingen unsere Kollegen zwar wieder in die Spur, provozieren jedoch andere ungewollte Trotzreaktionen und sind natürlich auch nicht gut für die Stimmung. Außerdem muss diese Kontrolle ständig aufrechterhalten werden. In so einem Unternehmen möchten Sie nicht arbeiten, oder? Wenn wir das nicht tun wollen, bleiben uns nur Vernunft oder Spaß an der Aufgabe als möglicher Ansatzpunkt.
Es reduziert sich immer auf ein oder zwei Personen. Auch wenn das gesamte Team kippt, hat es immer (na gut – in den allermeisten Fällen) seinen Ursprung bei einem oder zwei Kollegen, die einfach keinen Spaß an ihrem Job haben. Warum macht man es sich im Büro möglichst leicht? Weil man die Aufgabe nicht gern macht. Wir müssen uns also fragen, warum diese Kollegen so wenig Spaß an ihrem Job haben. Schließlich haben die sich doch irgendwann dazu entschieden, Softwareentwickler zu werden, weil sie das gerne gemacht haben, oder nicht?
Sprechen Sie mit den betreffenden Kollegen. Versuchen Sie, herauszufinden, was das eigentliche Problem ist. Ohne Druck, ohne Androhung von Konsequenzen. Sagen Sie nicht, dass Ihnen aufgefallen ist, dass er die Sache laufen lässt, dann wird Ihr Gesprächspartner blockieren. Je lockerer und ungezwungener Sie sind, desto leichter werden Sie verwertbare Informationen bekommen. Dem können Sie entnehmen, wie man den Kollegen wieder motivieren kann.
Das klingt jetzt alles nach: Wir haben uns alle ganz fürchterlich lieb, und wir wollen niemandem weh tun. Die Sache hat jedoch seine Grenze. Wenn es jemand übertreibt, und wenn jemand uneinsichtig ist, und sich die Situation nicht ändert, dann müssen wir im schlimmsten Fall zur letzten Konsequenz greifen.
