Die folgenden Fragen unserer Kunden haben Sie sich möglicherweise selbst schon gestellt. Natürlich können diese nicht pauschal beantwortet werden, denn jedes Projekt, jeder Kunde, jedes Team ist anders. Dennoch hoffen wir, Ihnen in aller Kürze Antworten und Inspirationen zu geben.
Kunde: Unsere Probleme beginnen schon bei den Rollen im Projekt. Ist der Product Owner nun auch Projektleiter? Wer verantwortet das Projekt und berichtet darüber?
VENIT: Während der Projektleiter eher steuert, ist der Product Owner für sein Produkt und den Nutzen des Business Value verantwortlich. Die Rollen sind doch recht verschieden. Aber definieren Sie bitte nicht tagelang die Verantwortung und Aufgabe jeder Rolle, in der Zwischenzeit liefern andere Firmen bereits erste Prototypen. Aber um auf die Frage zurückzukommen, wie wäre es mit einer Aufteilung nach Produkterstellung (das Scrum-Team) und darüber ein Managementüberbau "Project Management"? Der Projektmanager bedient dann lediglich die etablierten Schnittstellen im Unternehmen und das Scrum Team wird nicht gestört.
Kunde: Der Projektleiter berichtet dann über das Projekt und sitzt allein im Steuerkreis?
VENIT: Nun, der Projektleiter ist möglicherweise der Scrum Master des Projekts. Sie merken schon, kombinieren Sie, wie Sie wollen! Versuchen Sie aber immer das Gute aus den jeweiligen Welten nicht zu blockieren. In den Steuerkreis sollte der Projektleiter den Product Owner als Produktverantwortlichen und gerne auch einen Vertreter des Teams als Verantwortlichen der Umsetzung mitnehmen. Schließlich ist der Product Owner die wichtigste Person, er entscheidet über die Umsetzung von Anforderungen. Stellen Sie daher, wenn möglich, den PM-Layer im Organigramm neben und nicht über den Produkterstellungs-Layer.
Kunde: Unser Management wird nicht akzeptieren, dass wir Anforderungen ändern. Es investiert Projektbudget und erwartet die geplanten Projektergebnisse.
VENIT: Kennt Ihr Management die Vorteile der agilen Methoden? Haben Sie es mit einem komplexen Projekt zu tun? Hinterfragen Sie, wie stabil die Kundenanforderungen in der Vergangenheit tatsächlich waren. War die Kommunikation unter den Entwicklern immer gut? Ist die detaillierte Planung zu Beginn nicht oft Augenwischerei? Eine Analyse dauert nicht lange und sorgt für ein besseres Verständnis. Begeben Sie sich aber nicht in die Rolle des Scrum-Verfechters, der sein Vorgehen auch noch anhand des Projekterfolges beweisen muss, sondern tragen Sie die Analyse vor und lassen Sie das Management entscheiden.
Kunde: Für viele in unserer Firma ist agil gleichbedeutend mit „kein Plan“. Und dann noch keine ausführliche Dokumentation? Bei uns undenkbar!
VENIT: Ja, den Satz "früher haben wir auch agil gearbeitet" kennen wir. Das sind Zeiten, in denen nach dem "Hey-Joe-Prinzip" irgendjemand ohne Dokumentation und Testing irgendetwas entwickelte. Agil bedeutet aber keinesfalls chaotisch, sondern diszipliniert vorzugehen. Es wird lediglich schnell und flexibel auf Kundenanforderungen reagiert. Die Dokumentation wird dabei durchaus vorgenommen und dient der Wartbarkeit und Änderbarkeit, es wird aber genau überlegt, wie viel davon nötig ist. Das ist doch wirtschaftlich!
Kunde: Wie können wir denn einen Projektplan erstellen, wenn wir nicht wissen, wann ein bestimmtes Projektergebnis zu erwarten ist?
VENIT: Die Planung einzelner Projektergebnisse ist tatsächlich nicht möglich, aber dafür wissen Sie sehr sicher, wann ein Sprint fertig sein wird. Der Terminplan beschränkt sich also auf die Fälligkeit der Sprints und mögliche Release-Termine, die Produktentwicklungsplanung erfolgt mit den Werkzeugen von Scrum. Die Iterationen lassen sich dabei in die klassischen Phasen integrieren, d.h. ihr Projekt startet beispielweise mit den Phasen Discovery und Planung und fasst dann drei Sprints zu einem Release zusammen (wobei nach Scrum jeder Sprint release-fähig wäre) und so weiter. Wenn Sie wollen, können Sie diese Iterationen als Arbeitspakete im klassischen Sinne führen.
Kunde: Das Reporting kann wie in einem klassischen Projekt erfolgen?
VENIT: Ja, allerdings unterscheidet sich Scrum hier. Aufgrund des Time-Boxing und der meist gleichbleibenden Teamgröße sollten Probleme hinsichtlich Ressourcenauslastung oder Timeline nicht auftauchen. Zur Überwachung des Fortschritts können Burndown-Charts der Restaufwände auf Sprint- und Projektebene eingesetzt werden, wenngleich diese suggerieren, alle zu Beginn definierten User Stories müssten auch abgearbeitet werden.
Kunde: Benötige ich weiterhin das Arbeitspaket Qualität?
VENIT: Ein Quality Manager könnte auf Projektebene installiert werden. Sie teilen das Thema Qualität sozusagen auf in die klassische, vorausschauende Qualitätsplanung, in der für jede Produktlieferung die Qualitätskriterien definiert werden, und in die Qualität in Scrum, die durch das Team erbracht wird. Es definiert zu Beginn, wann eine Aufgabe fertig ist (Definition of Done) und testet dann in den Iterationen intensiv, ob Anforderungen und Definition of Done eingehalten wurden. Konzentrieren Sie sich auf Scrum und over-engineeren Sie das Thema auf Projektebene nicht.
Kunde: Wo werden denn die Architekturfragen in Scrum geklärt? Was ist hier üblich?
VENIT: Es gibt verschiedene agile Architekturansätze und man muss individuell entscheiden. Kurz gesagt geht es ja immer darum, die Risiken hinsichtlich Architekturfragen zu minimieren, sowohl in der klassischen Methode durch die Architekturphase vorweg als auch beim agilen Vorgehen dadurch, dass durch frühzeitige Erfahrung aus der Implementierung und des Kundenfeedbacks Fehlentwicklungen erkannt werden. Denkbar wäre auch, die kritischen User-Stories hinsichtlich der Architektur an den Anfang zu stellen und damit schnell den wunden Punkt zu treffen. Stellen Sie in einem agilen Plan eine Architekturphase vorne an, so handelt es sich hierbei nur um initiale und keine abschließenden Tätigkeiten, es wird nur so viel wie nötig vorgearbeitet. Alles andere erfolgt während den Iterationen. Sicher dominiert das Thema, wie kritisch die Architekturfrage generell gesehen wird.
Kunde: Ich müsste für jede Änderung der Anforderungen einen Change Request dokumentieren und genehmigen lassen. Das wäre gar nicht umsetzbar!
VENIT: Tricksen Sie. Sie sind anscheinend in der alten Welt gefangen, aber versuchen Sie bitte mit Ihrem Entwicklungsteam weiterhin agil zu bleiben! Drei Punkte hierzu:
1) Sind Sie der Product Owner? Vergessen Sie nicht, dass Sie entscheiden, welche Anforderung wann umgesetzt wird. Sie können dies natürlich auch als Mitglied des Steuerkreises tun, oder Sie nehmen die Rolle als Unternehmer im Unternehmen ein und informieren die Mitglieder lediglich per E-Mail über die geplante Entscheidung und begründen diese.
2) Sollte es sich tatsächlich um einen Change handeln, so sind die Auswirkungen viel geringer als beim V-Modell. Hier müsste Analyse, Design und Implementierung komplett nochmals durchlaufen werden, die Dokumentation nicht zu vergessen. Ggf. wären sogar Testfälle zu schreiben. D.h. die Auswirkungen Ihres Change Request sind viel geringer, so dass die meisten Felder des CR-Sheets sicher leer bleiben können.
3) Nicht alles ist ein Change: Nutzen Sie "Change for free". D.h. Sie tauschen lediglich eine User Story durch einen neue. Da Sie auf Projektebene den Scope nicht auf Funktionen bezogen haben, gibt es auch keine Änderungen! Oder geben Sie als Product Owner jeder noch offenen User Story einen Preis, so gehen Sie als Kunde viel besser mit dem Restbudget um und bringt sich bei den Überlegungen ein. Sie erhalten neue User Stories? Wer sagt denn, dass diese den Weg in das Produkt schaffen. Sie müssen also erst einmal gar nichts tun. Sie haben 60 von 100 User Stories umgesetzt und erhalten 20 zusätzliche? Anstelle nun über 120 Stories nachzudenken, könnten Sie auch priorisieren und zum Entschluss kommen, dass nur noch 30 der 60 umgesetzt werden müssen. Warum? Da der Aufwand in keinem Verhältnis zum Kundenutzen steht und so den Gesamterfolg gefährdet. Erklären Sie es dem Steuerkreis und beenden Sie Ihr Projekt früher als geplant.
Kunde: Verstanden. Und wie baue ich dann meinen Business Case, wenn der Umfang durchaus verhandelbar ist?
VENIT: Sehen Sie es doch so: Zumindest sind die Termine und Kosten in agilen Projekten meist fix. Sie kennen sicher Beispiele, in denen es in nicht-agilen Projekten anders war. Wie oft wurde dann der initiale Business Case nach Projektverschiebung und Outscoping angepasst? Jede Herangehensweise hat hier ihre Probleme.
Generell sinnvoll ist es, den Business Case nicht auf Projektergebnisse, sondern alleinig auf dem Kundennutzen aufzubauen. Wenn Sie fair sind, bewerten Sie nur das Minimal-Ziel an Nutzen. Aber bitte seien Sie nicht kleinkariert und bewerten jede Anforderung! Zusammen mit den Konstanten Zeit und Ressourcen haben Sie ein recht gutes Gerüst. Und vergessen Sie das Beste nicht: Sie haben durch die iterative Herangehensweise und die inkrementelle Auslieferung von Produktergebnissen bereits einen großen Nutzen erreicht. Dieser entsteht nicht wie beim V-Modell erst am Ende. So könnte sich das Projekt schon während der Laufzeit lohnen!
Kunde: Stichwort Risikomanagement
VENIT: In Scrum sind alle Mitarbeiter in den jeweiligen Bereichen für das Risikomanagement verantwortlich, im klassischen Modell der Projektleiter. Das lässt sich leicht kombinieren.
Kunde: Eine letzte Frage – wann sollten wir Lessons Learned Workshops durchführen?
VENIT: Scrum sieht in der Iteration eine Retroperspektive vor. Dies sind nichts anderes als Lessons Learned Sessions, die dabei helfen, sich kontinuierlich zu verbessern, schnell Erfahrungen zu sammeln und diese in der nächsten Iteration bereits anzuwenden. So kann schnell entgegengesteuert werden. Ergänzen Sie diese durch das Studium bestehender Lessons Learned zu Projektbeginn und führen Sie am Ende jeder Phase entsprechende Lessons Learned durch.
Kunde: Agile und nicht-agile Methode passen also gut zusammen?
VENIT: Wenn möglich, so entscheiden Sie sich für einen der beiden Wege. Ihnen ist zu wünschen, dass Sie durch die Anforderungen im Unternehmen nicht zu sehr ausgebremst werden und agile Methoden nicht ad absurdum geführt werden. Dennoch haben Sie gesehen, dass sich die Methoden nicht widersprechen müssen und Sie sich durch etablierte Projektmanagementstrukturen nicht aufhalten lassen müssen.
