Dieser Artikel ist der Auftakt einer kleinen, vermutlich zwei bis dreiteiligen Serie, in der beleuchtet werden soll, wie Scrum abseits der allseits bekannten Rollen und Events denn eigentlich so funktioniert.
Manchmal habe ich den Eindruck, dass die vor Sport-Metaphern triefende Terminologie von Scrum sowie die zugehörigen Rollen und Events das Verständnis erschweren, wie Scrum eigentlich funktioniert.
Rugby gilt ja gemeinhin als eher brutaler Sport.
Ich muss zugeben, dass mein Herz nicht unbedingt für Sportarten wie Rugby schlägt (genaugenommen bin ich, was Sport angeht, ein eher desinteressierter Zeitgenosse) und entsprechend habe ich davon wenig bis gar keine Ahnung. In einer Kolumne der Welt hieß es mal, dass im Rugby die Tugenden des Rittertums gepflegt werden: Brutalität, Stursinn, Stolz und Tapferkeit.
Mir geht es anders als dem Autor: Ich kann in Brutalität und Stursinn nichts moralisch Gutes erkennen und so missfällt mir der Gedanke, dass die Erfinder von Scrum ausgerechnet solche Tugenden im Sinn hatten. Was ein Glück für mich, dass es das Internet gibt und sich die Anfänge von Scrum ganz gut zurückverfolgen lassen.
Eine vielleicht wenig bekannte Tatsache über Scrum ist, dass die grundlegenden Ideen auf die Japaner Hirotaka Takeuchi and Ikujiro Nonaka zurückgehen, die als bedeutende Wissenschaftlicher im Bereich Wissensmanagement gelten, und von diesen bereits im Jahr 1986 in einem Text mit dem Titel „The new new product development game“ beschrieben wurden.
Worauf sie sich beim Rugby bezogen war die Art des dynamischen Teamspiels, bei dem der Ball ständig zwischen den Spielern hin- und hergepasst wird, während sich das Team gemeinsam nach vorne bewegt.
Wir müssen nicht unbedingt auf Rugby gucken, um diese Idee zu verstehen: Auch in anderen Teamsportarten geht es um eine gemeinsame Zielsetzung und ein dynamisches (also an die Spielgeschehnisse angepasstes) Zusammenspiel.
Der Unterschied besteht darin, dass beim Rugby kein Vorwärtsspiel erlaubt ist. Der Ball darf zwar nach vorne gekickt werden, aber nur nach hinten oder zur Seite gepasst werden. Das bedingt, dass das Team ständig nah beieinander bleiben und sich selbst organisieren muss, um den Ball ins gegnerische Tor zu bekommen.
Im Kern geht es auch in Scrum darum: gutes Teamwork.
Die Charakteristik von gut funktionierenden Teams
Was macht gut funktionierende Teams aus?
Nun, wir kennen Aussagen wie „ein Team ist mehr als die Summe der einzelnen Mitglieder“ um zu beschreiben, was ein gutes Team ausmacht. Damit ist gemeint, dass ein gutes Team nicht (allein) durch die Kompetenzen der einzelnen Mitglieder gebildet wird, sondern eben erst durch deren effektive, koorperative und zielführende Zusammenarbeit.
Meine Meinung ist: Dort wo nicht im und am Team gearbeitet wird, gehen früher oder später die Lichter aus.
Interdisziplinär aufgestellt mit gemeinsamen Zielen
Ein gemeinsames Ziel ist wichtig: was bringt es für das Projekt oder das Unternehmen, wenn ein Spezialist in einer Phase des Projekts voll bei der Sache ist, aber die restliche Zeit an seiner eigenen Agenda arbeitet? Oder wenn der Spezialist nur dann beteiligt ist, wenn sein Spezialwissen gefragt ist, obwohl seine Kenntnisse, Erfahrung und sogar Art zu denken in anderen Phasen zu einem besseren Ergebnis beitragen könnten?
Die Interdisziplinarität ist ein weiterer Aspekt, der für den Erfolg von Teams einen entscheidenden Unterschied machen kann. Damit ist nicht gemeint, dass ein Tester oder Datenbankspezialist nun plötzlich Grafikdesign, Programmierung oder vielleicht Marketing übernehmen sollen. Aber es hilft eben, wenn die verschiedenen Spezialisten zusammarbeiten und so vermeiden, dass getroffene Entscheidungen im späteren Verlauf zu Problemen führen.
Natürlich kann es sehr wohl hilfreich sein, wenn die Spezialisten auch Kenntnisse aus den anderen Fachbereichen haben – und die Kundenbedürfnisse zu verstehen ist immer von Vorteil.
Autonom aber nicht auf sich selbst gestellt
Der Punkt, in dem sich eine hierarchische Denkweise und klassisches Management vielleicht nicht unbedingt immer mit Scrum einig sind, ist Autonomie.
Dabei geht es darum, dass ein Team – sobald die Zielrichtung klar ist – eigenständig agieren und entscheiden, also insbesondere die Taktik selbst festlegen kann.
In der Schaffensphase ist es einfach nicht hilfreich, wenn man sich ständig rückversichern, abversichern oder erklären muss. Das bremst aus, es demotiviert und frustriert.
Je mehr das Team selbst entscheiden kann, desto effektiver kann es sein. Immer wenn Entscheidungen nicht im Team getroffen werden können, entsteht eine Abhängigkeit, eine zeitliche Verkettung zwischen dem Fortschritt des Teams und der externen Entscheidung. Jeder der schon mal ein Buch über Projektmanagement und darin speziell über den kritischen Pfad gelesen hat, müsste die Bedeutung dessen verstehen.
Worum es bei Autonomie aber gerade nicht geht: ein auf sich gestelltes Team.
Zweck und Ziel der Organisation ist es, die Stärken der Menschen produktiv zu machen und ihre Schwächen unwesentlich. –Peter Drucker
Seien wir realistisch: bei aller Interdisziplinarität gibt es dennoch Schnittstellen zu anderen Abteilungen, anderen Teams. Nur weil ein Team das nötige Skillset hat, um neben der Entwicklung auch Infrastruktur zu betreiben, kann das nicht bedeuten, dass es sich um alles selbst kümmern muss. Auch sind wir in vielen Unternehmen wahrscheinlich weit davon entfernt, dass Marketing und Vertrieb direkt in die Teams integriert sind: dennoch muss die Zusammenarbeit gewährleisten, dass das Team weitestgehend zielorientiert arbeiten kann.
Alles andere ist organisierte Verantwortungslosigkeit.
Lernen auf verschiedenen (allen) Ebenen
Zuletzt möchte ich noch auf einen Aspekt eingehen, wo wir uns dem eher prozessorientierten Aspekten nähern: Lernen.
Ganz klar ist Lernen ein wesentlicher Aspekt für effektive Teamarbeit, denn nun ja: erinnert ihr euch noch an Disketten oder gar Lochkarten – und was bringt euch dieses Wissen für eure heutige Arbeit?
Dabei geht es beim Lernen aber nicht allein um fachlichen Wissenserwerb, sondern eben auch um Fortschrittsinformationen, Eigen- und Besonderheiten der Teamkollegen, Infos über das Projektumfeld (etwa Marktgegebenheiten und Kundenanforderungen) Kenntnisse und und und.
Einer der wesentlichen Voraussetzungen fürs Lernen ist Information und dementsprechend Informationsaustausch. Dieser kann in vielfältiger Form daher kommen: über direkte Face-to-Face-Kommunikation, über Informationsradiatoren aber natürlich auch jeglicher anderer Form von Dokumentation.
Der „New new product development game“-Artikel beinhaltet die Idee, dass Lernen sowohl auf der individuellen Ebene als auch auf der Teamebene und sogar auf Organisationsebene stattfinden soll.
Das zeigt einen Aspekt auf, der bei der Betrachtung von Scrum als reine Teammethode zu kurz kommt: Was nützt Optimierung an den kleinsten Einheiten im Team (sprich: Mitarbeiter und Teams) wenn nicht gleichzeitig auch die Interaktion zwischen den Teams oder beser gesagt im Gesamtteam optimiert wird?
Ob und welche Rolle ein Prozessrahmen dabei spielt, beleuchte ich einem der nächsten Artikel.
Scrum und die Bedeutung von Rhythmus