Warum planen wir überhaupt?
Nur weil Scrum oder SAFe das so vorsieht?
Das Planen muss doch einen Zweck verfolgen, oder?
Reicht es nicht einfach eine Reihenfolge dessen festzulegen, was umgesetzt werden muss?
Wäre es ein einzelnes Scrum Team auf weiter Flur, ohne jegliche Abhängigkeiten (Dependencies) zu anderen Teams, könnten es folgende Gründe für das Planning geben:
- Arbeiten mehrere Developer parallel an einem Produkt, kämen sie sich ohne jegliche Abstimmung darüber wer was macht zweifelsohne ins Gehege. Abstimmung ist also sinnvoll, wenn nicht gar notwendig. Nicht selten arbeiten ja auch gleich mehrere Entwickler an ein und derselben Kundenanforderung.
- Stakeholder sind neugierig. Sie wollen wissen, was sie in Kürze zu erwarten haben.
Bewegen wir uns im Rahmen von SAFe und sind Teil eines Agile Release Trains, bedarf es unter Umständen noch mehr Abstimmung. Da arbeiten gegebenenfalls gleich mehrere Teams am gleichen Produkt und es könnte gut sein, dass Team B auf die Zuarbeit von Team A angewiesen ist, um mit der Implementierung ihrer To Dos überhaupt anfangen zu können. Hier spricht man von sogenannten Dependencies und es ist wohl für jeden einsehbar, dass es hier schon gar nicht mehr ohne ein wenig Abstimmung – Planung – geht. Siehe hierzu auch SAFe: Inner und Outer Dependencies.
Und natürlich wollen auch im größeren Rahmen von SAFe die Stakeholder wissen, wann sie die Umsetzung ihrer Anforderungen erwarten dürfen. Hier wird gleich der größere Rahmen / Zeitraum eines ganzen Program Increments (PI) beplant. Zumeist ein Zeitraum von 8 – 12 Wochen.
Anmerkung: Wer schon einmal Stakeholder Management (richtig) gemacht hat weiß, wie schwierig es sein kann, denn Stakeholder sind oftmals kein einfaches Volk. Es gehört dazu ihnen gegenüber auskunftsfähig zu sein und halbwegs verbindliche Zusagen sind nicht selten ein Mittel um wichtige Stakeholder bei der Stange zu halten. Man braucht sie, die Stakeholder. Ohne Stakeholder keine Projekt / kein Agile Release Train.
Alles legitime Gründe für ein Planning, oder?
Das Commitment
In pure Scrum wird von Sprint zu Sprint geplant. Jeder Sprint fängt mit einem Sprint Planning an. In SAFe wird in größeren Zyklen geplant. Es werden im Rahmen eines PI Plannings gleich alle Development-Sprints eines Program Increments (PI) beplant. Der Plan, oder die Pläne im Rahmen von SAFe, stellen das Commitment gegenüber Product Owner, Product Manager und den Stakeholdern dar.
Was ist ein Commitment?
Ein Commitment im Sinne von Scrum oder SAFe ist kein Versprechen, das man mit Blut unterschrieben hat oder bei dessen Nichteinhaltung man die Seele an den Teufel verliert. Nein, man muss auch nicht beichten gehen, wenn es mal nicht funktioniert hat.
Ein Commitment im Sinne von Scrum sollte aber den unbedingten Willen darstellen das abzuliefern, was man im Rahmen des Scrum oder PI Plannings geplant hat umzusetzen. Der Plan ist das Commitment dem Product Owner und den Stakeholdern gegenüber.
Was ist das richtige Mindset?
Das Manifest für agile Softwareentwicklung sagt aus, dass es die höchste Priorität sein sollte Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Alle Stakeholder, die berechtigt sind Anforderungen zu stellen, sind Kunden des Scrum Teams, respektive der Scrum Teams eines Agile Release Trains. Alle Kunden, mit deren vielen Anforderungen zufriedenzustellen, ist eine Herausforderung der sich die Teams mit Schwung und Elan stellen sollten.
Verlässlichkeit …
… ist eine Eigenschaft, die Kunden / Stakeholder von Scrum Teams erwarten.
Werden Anforderungen (Objectives und User Stories) für die Umsetzung in den Sprints eines Program Increments (PI) eingeplant, erwarten Kunden spätestens am Ende des Program Increments die Lieferung qualitativ hochwertiger Increments, die weitgehend dem ursprünglichen Plan entsprechen. Wenn ein paar nice-to-have-Funktionalitäten fehlen, ist das in der Regel nicht weiter schlimm. Das MVP des gemäß Planning (= Commitment) Zugesagten sollte aber geliefert werden; und das in guter Qualität.
Das richtige Mindset von Entwicklern sollte also beinhalten, dass nach bestem Wissen und Gewissen versucht wird die Kunden / Stakeholder zufriedenzustellen. Kennt man die Erwartungshaltung der Stakeholder, kann man das richtige Mindset in einem Satz zusammenfassen.
Um unsere Stakeholder zufriedenzustellen, wollen wir so viele derer Anforderungen so schnell wie möglich in guter Qualität umsetzen.
Soll nicht heißen, dass permanent Überstunden geleistet werden sollen um den übergroßen Bedarf der Stakeholder zu befriedigen, soll aber auch nicht heißen, dass man bummeln soll. Sprints soll mengenmäßig so beplant werden, dass sie eine machbare Herausforderung darstellen.
Siehe auch: Nur ein wenig Mehrwert reicht nicht
Empfehlung: Sprints zu 80 % mit Prio 1-Anforderungen (= MVP-relevant) und zu 20 % mit Prio 2-Anforderungen (= nicht MVP-relevant) beplanen. Kann am Ende eines Sprints / PIs alles MVP-Relevante in guter Qualität abgeliefert werden, sollten die Stakeholder zufrieden sein.
Brauche Sie Unterstützung bei der Implementierung des richtigen Mindsets, dann
