Klingt das nicht etwas falsch, wenn man bedenkt, dass Scrum DAS Agile Framework ist? Bevor Sie mich jetzt am nächsten Baum für die Ketzer aufknüpfen, lassen Sie mich erklären, warum so eine große Gefahr darin liegt, zu glauben, man sei agil, weil man Scrum macht.

Wir alle wissen, dass Scrum eine Sammlung von einfachen Regeln ist. Wir halten uns an ein paar Zeremonien, erstellen ein paar Artefakte und verteilen ein paar Rollen. Das alles ist schrecklich einfach, und jedes Element in Scrum ist nachvollziehbar. Wir haben sogar gelernt, dass es uns nicht hilft, wenn wir auf eines dieser Elemente verzichten, weil damit das Gesamte bricht. Leider wird dabei immer wieder vergessen (und das beobachte ich sehr sehr sehr oft), dass Scrum nur eine Sammlung von Werkzeugen ist. Wer einen Hammer und eine Säge besitzt und damit sogar einigermaßen umgehen kann, kann deswegen noch lange keinen Tisch zimmern.

Scrum ist ein wunderbares System, wenn wir uns vergegenwärtigen, dass es eben nur eine Sammlung von Werkzeugen ist, die uns dabei helfen, agil vorzugehen. Die Werkzeuge zu benutzen, bedeutet deswegen noch lange nicht, dass wir automatisch agil vorgehen. Das ist ein riesiger Unterschied, und wenn Sie den verstanden haben, dann haben Sie schon sehr viel erreicht.

Um das wirklich zu verstehen, müssen wir uns sicherlich zuerst einmal klar machen, was Agilität eigentlich bedeutet. An dieser Stelle könnte ich wieder einmal das Agile Manifest zitieren, um diesen Artikel ein wenig zu strecken, aber ich denke, wir sollten uns auf etwas Griffigeres verständigen. Wie wäre es damit: Agilität bedeutet inkrementell und empirisch vorzugehen?

Die eine Hälfte dieser Definition habe ich mit dem Einsatz von Scrum automatisch abgedeckt. Wir teilen unsere Zeit in Sprints ein. Damit schaffen wir fast automatisch kleinere Einheiten, die wir ausliefern können (wenn wir nicht kompletten Blödsinn machen).

Soweit ist alles gut, aber was ist mit der zweiten Hälfte dieser zusammengestauchten Definitioon von Agilem Vorgehen? Genau an dieser Stelle steht immer wieder das große Versäumnis, weil Scrum hierfür mit dem Review nur ein unzureichendes Werkzeug zur Verfügung stellt.

Ich kann ein Review abhalten, indem einfach nur der Product Owner seine Anforderungen begutachtet und abnimmt – Haken dran, fertig. Ich kann zum Review auch Vertreter der Stakeholder einladen, die ihr Feedback geben. Damit bin ich schon auf einem besseren Weg. Ich habe einen von der Geschäftsführung dabei, einem vom Marketing, einen vom Support, aber in aller Regel keinen Anwender.

Mit den Kollegen vom Marketing und dem Support habe ich als Product Owner bei der Erstellung der Anforderungen gesprochen. Vielleicht haben wir diese Anforderungen sogar gemeinsam formuliert. Bei der Erstellung der Anforderungen hat der Product Owner den gesamten Input seiner Stakeholder aufgenommen, durch seine persönliche Wurstmaschine gedreht und das Ergebnis in wunderschöne User Stories gegossen. Jetzt sitzen alle beim Review zusammen, begutachten das Ergebnis und stellen fest, dass alle Tasks aller Stories abgehakt werden können.

Und was lernen wir dabei? Absolut nichts.

Wer glaubt, dass an dieser Stelle und in dieser Form der Agilität genüge getan sei, irrt vollständig. Ein empirisches Vorgehen bedeutet kontinuierliches Lernen, und genau das geht über die Scrum Zeremonien und Artefakte hinaus. Wenn kein Anwender beim Review anwesend ist, kann ich dabei nichts lernen. Ich kann kein Feedback einholen außer dem indirekten durch die Stakeholder, die ihrerseits nur Vertreter der Anwender sind. Alle Anwesenden können nur sagen, was sie denken, was wiederum die Anwender denken. Wir können in einem Review nur indirektes Feedback einholen (es sei denn, wir arbeiten an einem Inhouse Projekt).

Das eigentliche Lernen kommt erst im nächsten Schritt, für den Scrum keine Regeln hat, und der deswegen so gerne vergessen wird: wir stellen unsere Ergebnisse den Anwendern vor. Das können wir in einer Closed Beta machen, das können wir über einen AB-Switch und ein Feedbackformular machen, das können wir sogar in einem Labor machen. Viele Wege führen nach Rom, wichtig ist nur, dass wir wenigstens einen davon nehmen.

Erst dieser direkte Kontakt ermöglicht ein direktes Feedback der Anwender, aus dem wir lernen können. Das hier Gelernte überführen wir in unsere nächste Iteration. Erst wenn wir so vorgehen, können wir behaupten, agil zu sein.

Es ist kein Problem, mit der korrekten Anwendung der Scrum Regeln ein wunderschönes Wasserfall-im-Kleidchen-Projekt zu bauen. Stakeholder und Product Owner stellen ein initiales Backlog auf und gehen in den ersten Sprint. Am Ende der zwei Wochen ist der erste Baustein der fertigen Software fertig. Das Backlog hat noch weitere große Themen, die wir in Epics gegliedert haben, von denen wir uns eines nach dem anderen vornehmen. Zu Beginn unseres Projekts haben wir mit Vertretern unserer Zielgruppe gesprochen und eine ziemlich gute Vorstellung von einem Produkt entwickelt, dass eben dieser Zielgruppe gefallen sollte.

Diese Vorstellung, die wir im Kopf haben, arbeiten wir jetzt Stück für Stück, eingeteilt in Sprints, ab. Machen wir uns nichts vor, das ist die Realität in unendlich vielen Unternehmen, die Scrum machen und von sich selbst behaupten, agil zu sein.

Überprüfen Sie sich einmal selbst: wann haben Sie zum letzten Mal in Ihrem Unternehmen einen Teil Ihres Backlogs weggeworfen (oder deutlich umformuliert) weil Sie festgestellt haben, dass Ihre Anwender eigentlich etwas Anderes wollen?

Ich fasse meine Gedanken einmal kurz zusammen. Agiles Vorgehen bedeutet auch kontinuierliches Lernen durch das stetige Einholen von Feedback der Anwender. Wenn das unterlassen oder vernachlässigt wird, ist das Ergebnis kein Agiles Vorgehen mehr.

Facebooktwittergoogle_plusredditpinterestlinkedintumblr