Commitments in agilen Teams
Einige der letzten Artikel handelten von Continuous Discovery und Dual-Track Agile. In diesem Artikel möchte ich über eine andere Dimension effektiver Arbeitsweisen in einer agilen Umgebung sprechen – und zwar wie man mit Commitments umgeht.
Commitments sind oft ein Problem
Wenn man in agilen Teams das Thema Commitments anspricht (wie z. B. wenn man wissen möchte, was man bekommen wird und wann), versuchen die meisten, sich herauszuwinden, oder sie verweigern sich einfach.
Es ist ein permanenter Kampf zwischen den Managern und den Stakeholdern, die das Geschäft am Laufen halten möchten (mit Hilfe von Einstellungsplänen, Marketingprogrammen, Kooperationen und Verträgen, welche von konkreten Terminen und Ergebnissen abhängig sind) und den Mitgliedern des Produktentwicklungsteams, die verständlicherweise nur ungern Commitments für Termine und Produktauslieferung abgeben – zumindest solange sie noch nicht genau wissen, was sie liefern sollen und ob sie es überhaupt schaffen werden, die erforderlichen Geschäftsergebnisse zu liefern. Außerdem können sie nun mal nicht einschätzen, was es im Endeffekt kosten wird, wenn sie noch gar keine Lösung haben.
Der Grund dafür ist eine Lektion, die viele Produktteams schmerzlich lernen mussten, nämlich dass viele Ideen einfach nicht so funktionieren, wie wir uns das erhofft hatten, und dass man für die Ideen, die tatsächlich funktionieren könnten, normalerweise einige Iterationen benötigt, bis man an einem Punkt angekommen ist, an dem man das Produkt als Erfolg für das Unternehmen bezeichnen könnte.
Bei kundenspezifischer Software kann man vielleicht einfach nur so viele Iterationen durchführen, bis „das Unternehmen” mit der Software zufrieden ist (oder die Idee wieder verwirft). Bei einem Produktunternehmen wird das so nicht funktionieren.
Bitte verstehen Sie mich nicht falsch. Viele Leute haben mich über die Gefahren von Stakeholder-Roadmaps schimpfen hören. Der Artikel über den Opportunity Backlog ist nur der jüngste, der auf dieses Problem eingeht. Gute Produktunternehmen minimieren diese Commitments. Allerdings gibt es immer einige Commitments, die eingegangen werden müssen, damit ein Unternehmen effektiv geführt werden kann.
Was ist also zu tun?
Es geht darum, zu verstehen, dass der Zeitpunkt, an dem die Commitments eingegangen werden, die Ursache für all den Ärger mit den Commitments ist. Sie werden nämlich zu früh eingegangen; noch bevor wir überhaupt wissen, ob wir dieser Verpflichtung nachkommen können – und was noch viel wichtiger ist – ob wir damit überhaupt das Problem des Kunden lösen können.
Ich habe schon einmal über eine ähnliche Situation geschrieben (siehe hier). Beim Dual-Track Agile geht es beim Discovery Track darum, diese Fragen zu beantworten, bevor wir Geld und Zeit investieren, um qualitativ hochwertige Produkte zu erschaffen.
Bei Commitments dreht sich also alles um ein ständiges Geben und Nehmen. Wir bitten die Führungskräfte und die anderen Stakeholder, uns in der Product Discovery ein wenig Zeit zu geben, damit wir uns Gedanken um die benötigte Lösung machen können und die Lösung validieren lassen können; die Kunden sollen den Wert und die Nutzbarkeit bestätigen, die Entwicklern sollen die Umsetzbarkeit absichern und die Stakeholder müssen bestätigen, dass es für das Unternehmen auch tragfähig ist.
Sobald wir eine passende Lösung gefunden haben, können wir eine wohl überlegte und zuversichtliche Aussage dazu treffen, wann wir sie liefern können und welche Geschäftsergebnisse wir erwarten können. Wir können uns auch überlegen, ob es die Mühe überhaupt wert ist.
Beachten Sie, dass unsere Projektmanager extrem wichtig sind, wenn es um die Findung konkreter Daten für die Commitments geht. Denken Sie nur einmal daran, was passiert, wenn die Entwickler zwar davon ausgehen, dass etwas vielleicht nur zwei Sprints dauern wird, dieses Team aber schon mit anderen Arbeiten beschäftigt ist und sie erst in einem Monat mit neuen Arbeiten anfangen können. Diese Commitments und Abhängigkeiten werden von den Projektmanagern getrackt.
Der Kompromiss ist also ganz einfach. Das Produktteam bittet um etwas Zeit für die Product Discovery, bevor Commitments eingegangen werden. Nach der Discovery-Phase können wir dann Commitments für Termine und Ergebnisse abgeben, damit auch unsere Kollegen effektiv ihren Job erledigen können.
Dieser Text stammt aus dem Blog von Marty Cagan und wurde von uns ins Deutsche übersetzt.
Werde zertifizierter Scrum Master mit der Agile Academy
Wenn du dein Team als Scrum Master bei ihren Commitments stärker unterstützen willst und du auf der Suche nach weiterführenden Informationen bist, haben wir mehrere Möglichkeiten für dich.
Unsere zertifizierten Trainer bieten Fortbildungen auf der ganzen Welt an und ermöglichen dir ein passgenaues Training für dein Anliegen.
Für Scrum Master bieten wir folgende Trainings und kostenlosen Fortbildungsmöglichkeiten: