Donnerstag, 16. März 2017

Scaled Agile: Integrations-Teams

FS
Bild: Flickr/Craig Anderson - CC BY-SA 2.0
Lange Zeit war die Scrum-Welt einfach. Wann immer es darum ging, dass irgendjemand die vielen Rollen der alten Welt in die neue Welt übertragen wollte konnte man auf den Scrum Guide verweisen: es gibt den Product Owner, es gibt den Scrum Master und es gibt das Entwicklungsteam, in dem alle anderen Personen einfache Mitglieder sind. Wie der Guide so schön sagt: Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment. Punkt.

Seit eineinhalb Jahren ist die Sache aber nicht mehr ganz so klar, denn mit dem Nexus-Framework von Ken Schwaber und Scrum.org gibt es erstmals einen Skalierungsansatz der von einem der Verfasser von Scrum stammt, der damit also "quasi-offiziell" ist. Und in dem taucht auf einmal etwas Neues auf, das Integrations-Scrum Team (offiziell "Nexus Integration Team"). Ein Team mit Product Owner, Scrum Master und Team-Mitgliedern, das dafür sorgen soll, dass die Ergebnisse der anderen Teams zusammenpassen. Was jetzt passiert ist war erwartbar - plötzlich kleben sich alle mittleren Manager und Koordinatoren dieses Label auf: die Architekten? Sind ein Integrations-Team. Das Testmanagemet? Ist ein Integrations-Team. Das Rollout-Management? Ist ein Integrations-Team. Und so weiter.

Natürlich ist das nicht das was Nexus will. Nexus Teams sind volatil, sie setzen sich bei Bedarf neu zusammen, ihre Mitglieder arbeiten in den normalen Scrum Teams mit wenn sie dort gebraucht werden und versuchen so viel wie möglich von ihrem Wissen dorthin zu verlagern. Auch der Nexus Guide ist eindeutig: Nexus Integration Team Members ensure that practices and tools are implemented, understood, and used to detect dependencies, and frequently integrate all artifacts to a definition of “Done.” Nexus Integration Team Members are responsible for coaching and guiding the Scrum Teams in a Nexus to acquire, implement, and learn these practices and tools. Machen wir uns nichts vor - das ist nichts was klassische Management-Teams tun, egal wie sie sich jetzt nennen.

 Was soll man also jetzt machen? Diesen "Etikettenschwindel" enttarnen? Ihn anprangern? Ihn bekämpfen? Vielleicht. Ich würde aber das Gegenteil empfehlen: ihn willkommen zu heissen. Ein unterschätzter Effekt der Selbst-Deklaration zu einem (speziellen) Scrum Team ist nämlich, dass agiles Arbeiten auch dort Einzug hält. Auf einmal müssen auch Architekten, Testmanager, Rollout-Manager und ähnliche Rollen mindestens einmal pro Monat Ergebnisse abliefern. Auf einmal müssen auch sie diese Ergebnisse in Reviews präsentieren. Und auf einmal müssen auch sie sich dem Feedback ihrer Stakeholder stellen - zu denen auch die "einfachen" Scrum Teams gehören. Populistisch gesagt - sie müssen herabsteigen aus ihrem Elfenbeinturm.

Ich korrigiere den letzten Satz. Sie dürfen herabsteigen aus ihrem Elfenbeinturm. Zu denjenigen die am meisten unter ihrer Realitätsferne gelitten haben gehören nämlich die mittleren Manager und Koordinatoren selbst. Statt nur theoretische Konzepte zu entwerfen dürfen sie selbst an der Umsetzung teilhaben. Statt nur final (wenn es oft zu spät ist) Abnahmen durchzuführen können sie frühes Feedback geben und nehmen. Ich habe viele Fälle erlebt in denen die Betroffenen von dieser neuen Art der Zusammenarbeit begeistert waren. Natürlich, es gibt auch Personen die lieber weitergemacht hätten wie bisher und jetzt destruktiv reagieren. Aus meiner (subjektiven) Erfahrung würde ich aber sagen, dass sie die deutliche Minderheit sind.
Powered by Blogger.