SOFA-Talk / Kann Scrum auch pünktlich?

Markus Stroh - 15.7.2019

Wieder einmal kamen Kollegen aus den Standorten zusammen, um sich innerhalb des SOFA-Talks zu einem agilen Thema auszutauschen. Das Scrum Open Forum ARITHNEA hatte auch dieses Mal vier Kollegen auf den beiden roten Sofas, um sich gegenseitig zu challengen und die Fragen aus den eigenen Reihen zu beantworten. Mit dabei waren Volker Bogacki (Projektleiter und Vertreter der Scrum Initiative), Christian Eiden (Hybris Entwickler und Architekt), Sashel Niles Gruber (PHP Entwickler und Vertreter der Scrum Initiative) und ich selbst, Markus Stroh (Scrum Master, Vertreter der Scrum Initiative).

Das Thema: „Kann Scrum auch pünktlich? – Umgang mit Deadlines durch MVP Ansatz“

Den Blick in den Scrum Guide konnten wir dieses Mal kurz abhandeln und überspringen, denn es ist eigentlich offensichtlich, dass der Scrum Guide für dieses Thema der falsche Ort ist. Dennoch ist der Spagat aus einem Framework und der Ausgestaltung dieses Frameworks durchaus sinnvoll. Schließlich ist der MVP Ansatz nichts anderes als eine von vielen Möglichkeiten sein Ziel erreichen zu können und das auch im Einklang mit Scrum.

MVP – Begriffsklärung und Realitätscheck

Wer im Internet nach den Begrifflichkeiten des MVP sucht, findet auf Anhieb eine sehr klare und übergreifende Definition „Minimum Viable Product“, also ein Produkt oder Ergebnis, dass in sich die kleinste lebensfähige Form darstellt. Klingt nach einem Ansatz der für iterative Vorgehensweisen und agile Rahmenbedingungen interessant sein kann, bedenkt man zusätzlich die Schnelllebigkeit der Projekte und die häufige Unsicherheit der finalen Produktvision.

Unmittelbar kamen erste Wortmeldungen auf. Begrifflichkeiten wie „Most Valuable Product“ – klingt irgendwie nach Standard Scrum? – oder auch „Meist Vollständiges Produkt“ machten die Runde. Es wurde deutlich, dass die Definition von „Minimum Viable“ breit gestreut ist. Oftmals reicht es in der Realität eben doch nicht aus, wenn eine Corporate Website bloß mit einer Suchleiste und einem Bild-Text-Element an den Start geht. Schnell wurde klar, dass der MVP sehr kontextspezifisch gelebt wird.

Der Begriff eines Prototypen wurde ebenfalls diskutiert. Also der erste Wurf zu einem Themengebiet, um beispielsweise Akzeptanz zu prüfen oder Entscheidungshilfe geben zu können. Aber sind wir dann noch im Rahmen eines MVP? Eines Produkts, das auch releasebar sein muss oder soll? Einem Ergebnis das hoffentlich auch „Value“ produzieren soll? Man merkt schnell, dass die Diskussionswelten hier ein wenig verschmelzen und das Auftrennen nicht immer möglich ist.

Einige Zeit später kamen wir zu dem Diskussionspunkt das Minimum Viable und Most Valuable vielleicht sehr nahe beieinander liegen können. Wenn also eine Website in den Relaunch geht und damit eine bereits aktive Kundschaft umgarnt, dann ist es offensichtlich, dass eine nackte Website nicht das Ziel ist. Viel mehr geht es im Rahmen des Projekts zwar schon darum sehr früh erste Ergebnisse zu haben und den Weg dann weiter zu beschreiten, allerdings ist Minimum Viable hier klar im Aspekt der Kundschaft zu sehen. Was manchmal nach Goldrand und Schnörkel aussieht ist für die Stakeholder – Hint: Enduser oder Benutzer der Plattform – vielleicht essentiell und entscheidet darüber, ob auf dieser Plattform oder einer anderen eingekauft wird.

Die ersten Erkenntnisse zu Pünktlichkeit und MVP waren: Wir sollten miteinander reden und das möglichst früh und auch intensiv. Nur dann ist es uns möglich beidseitig zu begreifen was das tatsächliche Ziel ist und um welche Zielgruppe es sich handelt.

Umfänge, Vorausplanung und der erste Schritt zurück zu Wasserfall?

Nächster Diskussionspunkt war die Evaluierung der Umfänge. Um pünktlich sein zu können, müssen wir irgendwie begreifen und feststellen was die Anforderungen unseres Projekts sind. Klingt ein wenig nach Backlogaufbau! Schneller Konsens wurde gefunden in frühen zielgerichteten Workshops mit dem Kunden. Ein grobes Zielbild sollte da sein. Dann zoomen wir eine Stufe tiefer und bewegen uns auf der Ebene von Features oder EPICs bis wir dann im Mikrokosmos von User Stories enden. Der Detailgrad kann dabei variieren. Möglicherweise genügen uns hier skelettartige Beschreibungen und Überschriften. Hauptsache ein Gefühl dafür, was auf uns zukommt. Dinge die wir als wichtiger definieren und zeitnah umsetzen wollen werden dann refined und detailliert ausgearbeitet. Es entsteht ein erstes Bild vom Ziel und eine erschreckende Erkenntnis: Sind wir wieder im Wasserfall gelandet?

Agilität bedeutet nicht auf Planung zu verzichten

Der Blick in die Zukunft ist wichtig, ohne dabei alles vorab feingliedrig zu ergründen. Wenn man in gezielten Workshops die Produktvision abklopft und die Erkenntnisse minimalistisch erarbeitet, dann gelangt man schnell in die Situation eine Timeline oder Milestones festlegen zu können. Dabei kann ein Milestone auch nur bedeuten, dass wir von Sprint Goals sprechen, also einem gezielten Fokus auf den wir hinarbeiten wollen.

Wir erhalten schlussendlich mit überschaubarem Aufwand ein Gefühl dafür, was wir erreichen wollen und können erste Schritte auf dem Weg dorthin festlegen.

Mit Inspection, Adaption and Transparency zum Ziel

Damit wir pünktlich ans Ziel kommen ist es unabdingbar zu prüfen, ob wir von unserem Weg abweichen. Wie wir abweichen. Ob diese Abweichung vielleicht sogar gewollt ist. Und welche Konsequenzen sich daraus ergeben. Um nicht in typisch deutschen Pessimismus zu verfallen bemerken wir vielleicht auch, dass wir besser unterwegs sind als gedacht. Also Spielräume haben für einen früheren Release oder weitere Features, die wir zuvor ausgesiebt hatten, um den Fokus auf die wesentlichen Dinge zu bewahren.

Das Thema Tools, agiles Reporting und Charts wurde schnell zu einem tieferen Diskussionspunkt in der Runde. Wir können einen MVP abstecken, einen Weg vornehmen, aber ohne aktive Inspektion werden wir nicht feststellen, ob wir auf dem richtigen Kurs sind. Die Optionen sind individuell und vielfältig. Wir können die Vollständigkeit von EPICs überprüfen. Schauen, wie viel noch in unserem Backlog liegt. Wir können versuchen mit Velocity und Schätzungen zu Erkenntnissen zu gelangen, ob der Zielkorridor noch passt. Velocity gibt uns auf jeden Fall eine grobe Abschätzung darüber, wie wir in der Vergangenheit performen konnten und was im Rahmen unserer Möglichkeiten liegt. Wenn man das auf den Horizont einer Deadline mappt, dann kommt man ganz banal zu einer grob machbaren Anzahl an Stories bzw. Story Points. Diese Zahl kann man jetzt auf Features, EPICs oder Stakeholder verteilen und diesen Verbrauch hinterher kontinuierlich wieder überprüfen.

Es wird deutlich, dass der eigentlich schlanke agile Gedanke im Realitätscheck oftmals andere Formen annimmt als erhofft. Es liegt jedoch an uns wie wir damit umgehen. Wenn wir damit Transparenz etablieren und allen klar ist worauf man hinarbeitet, dann bieten sich mit ein paar wenigen Hilfsmitteln doch sehr gute Ansätze, um adaptieren zu können. Dann muss die Priorität im Backlog möglicherweise angepasst werden. Dann wandern Anforderungen nach oben oder unten, eigentlich alles wie gewohnt.

Mit wehendem Haar einen Blick in den Sonnenuntergang

Ob Scrum pünktlich kann oder nicht, hatten wir nach einer Stunde intensiven Austauschs zum Ende unseres Talks nicht vollumfänglich beantwortet. Es gab trotzdem viele Lichtblitzmomente und die Gewissheit, dass man der Individualität eines jeden Projekts auch Respekt zollen muss. Und, dass es auch ein paar Elemente gibt, auf die wir achten können:

  • Wir alle tragen dazu bei pünktlich im Ziel anzukommen und Kommunikation ist ein Schlüssel.

  • Ein schlanker und effizienter Blick auf die Produktvision ist wertvoll.

  • Inspection und Adaption mittels Toolsupport ist unerlässlich und hilft uns wahrzunehmen, ob wir uns noch auf dem richtigen Weg befinden.

  • Am Ende steht immer ein Trade-Off. Sofern sich im Laufe der Entwicklung Rahmenparameter verändern, wird sich immer mal ein Termin verschieben, mal muss mehr Geld in die Hand genommen oder Anforderungen umpriorisiert werden.

Wir haben entsprechend sehr gute Mechanismen und Ansätze, um so präzise wie möglich am Ziel anzukommen und vielleicht unterwegs auch auf neue Entwicklungen und Ideen reagieren zu können. Möglicherweise können wir sogar Benefits generieren, die wir zu Beginn unserer Reise noch gar nicht erkennen konnten.

 

Take-away

Mein persönliches Fazit ist, dass wir mit Scrum im Gepäck und MVP Ansatz als Fokus ein gutes Duett haben, das zum einen Sicherheit und den Blick auf das Ergebnis bietet, im Kern aber agil und flexibel bleibt. „So viel wie nötig“ muss immer wieder neu hinterfragt werden, dann steht einem erreichen der Deadline auch nichts im Weg und vielleicht ist das Ergebnis bis dahin ein abweichendes von der Urvision, dadurch aber nicht zwangsweise schlechter, sondern nur „anders“.

Tags: Agile Business - Inside-ARITHNEA

Kommentar

newsletter-phone

ARITHNEA Newsletter

Aktuelle Trends, interessante digitale Lösungen, neue Best-Practice-Projekte von ARITHNEA oder Infos über wichtige Branchenevents – mit unserem monatlichen Newsletter sind Sie im Digitalen Business stets up to date.

Kostenlos Abonnieren