Agile Umsetzung und Demand Management im Konzern – Prozesse, Tooling, Rollen und Beteiligte
12-03, 14:05–14:45 (Europe/Berlin), Scaling Agile
Language: Deutsch

Das traditionelle Demand Management im Konzern basiert oftmals auf einer vorausschauenden Detaillierung der Anforderung, die in ihrer verpflichtenden Intention widersprüchlich zu der Idee einer lernenden, flexiblen Umsetzung mit selbstorganisierten Teams steht. Zudem sind diese Gegebenheiten in Prozessen und Tools implementiert, die auch eine unternehmensweite Harmonisierung, Steuerung und Verwaltung der Anforderungen ermöglichen sollen.

Wir wollen hier weder Grundsatzfragen im Sinne von agil vs. Wasserfall oder der Stärken und Schwächen aktueller Demand Management Prozesse diskutieren, sondern wollen vielmehr eigene Erfahrungen aus Sicht eines agilen Projektes zur Gestaltung der erforderlichen Schnittstelle von Demand Owner und Umsetzungseinheit teilen. Mit Prozessen, Rollen und auch einem Blick auf die Tools, wie dem hier eingesetzten ServiceNow für das konzernweite Demand Management und JIRA für die agile Umsetzung. Dabei ist auch die Charakteristik des Projektes bzw. der Projektumgebung aus unserer Sicht von Bedeutung, die ebenfalls kurz mittels eines Steckbriefes erläutert wird.


Ausgangssituation

Wenn agile Projekte Anforderungen verschiedener Anforderer umsetzen, stellen sich sehr schnell die Fragen nach Scope, Budget und Time: Wer zahlt was und was bekommt man dafür? Wie wird der „Preis“ bzw. Verrechnungsaufwand ermittelt? Wann wird geliefert?

Gerade größere Unternehmen haben dafür meist ein konzernweites Demand Management geschaffen, in dem alle Anfragen gesammelt bzw. von den Demand Ownern (=Anforderer mit Budget) eingestellt werden. Dieses Demand Management wird oftmals sowohl für die jährliche Budgetierung und Gestaltung des Projektportfolios, wie auch die unterjährige Einsteuerung von Anforderungen genutzt. Es kann dabei der Fall sein, daß durch diese enorme Bedeutung die Diskussion der Anforderungen „politisch aufgeladen“ ist, zudem Anforderungen durch traditionelles Requirement Engineerings mit sehr konkreten Umsetzungserwartungen verknüpft sind oder auch zur Gewinnung möglichst großer Budgetanteile Demands sehr umfassend definiert sind.

Diese Ausgangssituation trifft nun auf eine agile Umsetzung, die das generelle Versprechen der Agilität bzgl. Flexibilität, Wertorientierung, Effizienz und Geschwindigkeit jedoch auch nur dann einlösen kann, wenn eine ausreichende Business Agility gegeben ist.

Erfahrungsbericht

Am Beispiel eines agil skalierten Projektes, welches an einer Standardsoftware regelmäßig kleine, mittlere und auch große Entwicklungsarbeiten vornehmen muss die von Demand Ownern unterjährig mit sehr heterogenen Prioritäten aufkommen können, soll hier ein quartalsorientierter Planungsprozess skizziert werden und unsere Erfahrungen dazu geteilt werden. Ohne den Anspruch einer Allgemeingültigkeit, wohl aber mit dem Anspruch einer Übertragbarkeit für vergleichbare Projekttypen in ähnlichen Umfeldern.

Wenn sich das meist traditionell geführte Demand Management und die agilen Teams für die Umsetzung treffen, prallen oft auch unterschiedliche Vorstellungen aufeinander: wie werden Anforderungen aus dem Fachbereich eingesteuert, wann werden diese umgesetzt, welche Budgets sind dafür nötig und was bringen diese Anforderungen dem Fachbereich?

Gerade wenn die Bedarfe in einem Tool wie Service Now erfasst sind, die agilen Teams für die Umsetzung hingegen mit einem anderen Tool wie in unsrem Fall JIRA arbeiten, kommt es auch zu einem Medienbruch und den damit verbundenen Verlusten beziehungsweise Verzögerungen bei der Informationsweitergabe. Hier gilt es somit auch die Tools miteinander zu verknüpfen.

Die Frage, wer wo welche Informationen findet und wie das Zusammenspiel von Demand Management und agilen Umsetzungsteams gelingen kann, möchten wir in diesem Vortrag anhand konkreter Erfahrungen in einem agilen skalierten Projekt beantworten. Denn das Demand-Management muss aus Service Now oder JIRA Fragen der Demand Owner nach Scope, Termin und auch Kosten beantworten können. Und gleichzeitig müssen die agilen Teams vor Prioritätswechseln für die bereits laufende Iteration geschützt werden. Dies kann nur gelingen, wenn die Auskünfte an die Business Owner klar und verständlich sind und vor allem die erfolgreiche Lieferfähigkeit der agilen Projektmannschaft transparent gemacht wird.

Ich begeistere mich seit vielen Jahren für das agile Arbeiten, weil es mir persönlich einfach mehr Spass macht. Dies liegt sich an den Menschen, der Einladung zur Verantwortungsübernahme wie auch an der Art und Weise der Ergebnisorientierung die man eher im agilen Umfeld finden kann. Seit über 20 Jahren arbeite ich in bzw. leite Projekte, kommend aus der klassischen, umsetzungsorientierten Unternehmensberatung.