Minimum viable Team

Bild: Pexels / Benji Mellish - Lizenz

Unbemerkt von den meisten Anwendern stecken in agilen Ansätzen wie Extreme Programming oder Scrum zwei Bestandteile der zumindest herausfordernd und in manchen Zusammenhängen sogar sich gegenseitig blockierend sind. Zum einen sollen die hier beschriebenen Produktentwicklungsteams crossfunktional sein, also alles selbst erstellen können was für eine Funktionserweiterung nötig ist, zum anderen soll ihre grösse unter zehn Mitgliedern liegen. Das beisst sich häufig.

Ein banales Beispiel macht das deutlich: in stark regulierten Branchen wie im Banken- oder Börsenbereich sind zahlreiche Gesetze und Vorschriften einzuhalten. Werden sie missachtet können Aufsichtsbehörden wie die Bafin oder die EZB Strafen verhängen oder sogar Produkte vom Markt nehmen. Es empfiehlt sich also, neue Produktinkremente von Juristen, Verbraucher- und Datenschützern freigeben zu lassen. Diese ins Team zu nehmen würde die Grössenbegrenzung sprengen, sie draussen zu lassen die Crossfunktionalität beeinträchtigen.

Wenn man dem Reflex wiedersteht die Teams einfach grösser zu machen bleibt nur eine Alternative: selten benötigte Aufgaben aus den Randbereichen des eigenen Tätigkeitsbereiches werden an Unterstützer- oder Spezialistenteams ausgelagert. Zurück bleibt eine Gruppe, die für die häufig durchgeführten Kerntätigkeiten verantwortlich ist, gewissermassen ein "Minimum viable Team". Die meisten agilen Teams gehören diesem Typ an, es stellt sich aber die Frage - welche Fähigkeiten sind in einer solchen Einheit unverzichtbar?

Ausgehend davon, dass die meisten agilen Teams Software produzieren ist die naheliegende Antwort die, dass es Software-Entwickler sein müssen. Mit den Worten von Extreme Programming-Begründer Ron Jeffries: "If you want a program, you can't get one without a programmer. All the designers and PMs and all those very important skills are stymied until someone can write the program." Mit anderen Worten: nahezu alles lässt sich in der IT von aussen zuliefern, nur die IT selbst nicht. Scheint offensichtlich - oder?

Wie so häufig gilt auch hier die Antwort: kommt drauf an. In den meisten Fällen liegt Jeffries zwar richtig, in einer frühen Phase der Produktentwicklung kann es aber sein, dass auch in einem Software-Kontext noch kein Entwickler nötig ist. Der initiale Tauglichkeits- oder Marktfähigkeitsbeweis ist oft noch ohne sie zu bewältigen. Ein scheinbarer Widerspruch, aber eben nur ein scheinbarer. Wie er aufzulösen ist kann man im lesenswerten Artikel "How to Build an MVP App Without Writing Code" erfahren.

Natürlich sind die hier genannten Beispiele der Bank-IT und der MVP-Apps Extremfälle, mit denen die meisten Teams nie zu tun haben werden. Der Punkt sind aber auch nicht diese beiden speziellen Konstellationen an sich. Wirklich wichtig ist die Frage die sie verdeutlichen: wenn ein Team nicht alles selbst erzeugen kann, was ist dann in keinem Fall verzichtbar? Sich diese Frage zu stellen (und das mit wirklicher Unvoreingenommenheit und Ergebnisoffenheit) ist das was zu einem wirklichen Minimum viable Team führen kann.