Agile Wege zum Done - Tipps

Done. Erledigt. Fertig. Das ist der Moment auf den eigentlich alle Projekte hinsteuern, zumindest in der Theorie. Viel zu oft führen agile Methoden leider nicht zum Done, sondern zu neuen agilen Wegen und neuen agilen Projekten. Dabei ist doch das Done, das abgeschlossene Projekt, der Sinn allen agilen Managements. Auf uxdesign.cc schreibt Josh Seiden über agile Arbeitsweisen und über das magische Wort Done. Dabei hebt er eine wichtige Frage hervor: Woher weiß man eigentlich, wann man das vieldiskutierte Done erreicht hat. Wann ist ein Erfolg eingetreten? Es scheint ein gängiges Problem in der Entwicklung und im Projektmanagement zu sein, übers Ziel hinaus zu schießen und einfach weiter zu machen. Im Folgenden fassen wir Seidens Thesen für Sie zusammen.

Zu wissen, wann man fertig ist, ist nicht nur ein Problem in der Entwicklung, sondern auch in der Kunst. Leonardo DaVinci sagte einmal, dass ein Kunstwerk nie vollendet, sondern irgendwann einfach aufgegeben wird. Er war also davon überzeugt, dass man jedes Kunstwerk immer noch verbessern kann. Mit moderner Technologie verhält es sich oft ähnlich. Haben Sie zum Beispiel die Aufgabe ein Webdesign für eine Firma zu erstellen, so können Sie dies innerhalb eines Tages tun, oder sich viele Wochen lang damit beschäftigen. Es gibt immer noch etwas zu verbessern, hinzuzufügen oder zu verschönern. Oder Sie sollen einen Roboter kreieren, der in einem Restaurant die Kellner ersetzen soll. Sie könnten einfach da aufhören, wo der Roboter zum Tisch rollt und die Speisen abstellt. Sie könnten aber deutlich höhere Ziele verfolgen, zum Beispiel den Roboter auf menschenähnlichen Beinen gehen, ihn lächeln lassen oder ihn so programmieren, dass er Smalllatk machen kann. Genau das ist es: Sie müssen ein Ziel definieren, um zu erkennen, wann Sie es erreicht haben.

Die Macher und Anwender von Scrum haben dies schon recht früh erkannt. Daher ist die Definition des Done im Scrum ein gemeinsamer Standard, den alle Anwender anerkennen und nutzen. Im Scrum ist das Done nicht nur das Ziel, sondern der eigentliche Sinn des gesamten Scrum-Konzepts. Im Grunde wird beim Scrum alles in die Wege geleitet, damit das Done erreicht werden kann. Jeder einzelne Sprint existiert nur, um das Done zu erreichen. Wenn Sie nicht glauben, Ihr Ziel in diesem Sprint zu erreichen, dann starten Sie ihn gar nicht erst, sondern zerlegen ihn in kleinere Einheiten, damit jeder einzelne Sprint sein Done in der angegebenen Zeit auch wirklich erreichen kann.

Jeder, der einmal versucht hat, User Experience und Scrum zusammenzuführen, weiß, dass dabei Konflikte entstehen. Es sind meist taktische Probleme, denn sowohl UX als auch Scrum haben das hohe Ziel, hervorragende Produkte mit einem Mehrwert für den Nutzer zu schaffen. Aber oft sind die beiden Methoden nicht unter einen Hut zu bringen. Die Definition von Done ist dabei sehr kontrovers diskutiert. Beim Scrum ist Done so definiert, dass die Software funktioniert. Die meisten herkömmlichen UX-Methoden hingegen wollen erst dann von Done sprechen, wenn eine Software designt, getestet, ausprobiert und überarbeitet wurde, so dass sie bei den Usern gut ankommt. Im Lean UX kommt noch ein weiterer Aspekt hinzu: der Nutzen für den User. Hier wird das Done erst dann als erreicht erachtet, wenn das Produkt vom Nutzer oder Kunden abgenommen beziehungsweise abgesegnet wird. Es gibt also sehr unterschiedliche Ansichten, wann die Arbeit fertig ist. Und diese könnten kaum unterschiedlicher sein.

Beim Scrum muss die Software funktionieren. Beim Lean UX muss der Kunde damit zufrieden sein. Das ist etwas ganz anderes. Schon im Planungsprozess kann dies zu regen Diskussionen führen. Wer der UX-Methode anhängt, wird deutlich mehr Zeit für die Erledigung einer Aufgabe ansetzen als jemand, der dem Scrum-Ansatz verschrieben ist. Klar, denn entwickeln, testen, prüfen, überarbeiten braucht viel mehr Zeit als nur ein funktionierendes Produkt zu entwickeln. In einem agilen Team kann dies zu viel Frustration führen.

Josh Seiden arbeitete daran, diese Diskrepanz zu fassen zu bekommen und die Problematik zu entschärfen. Gemeinsam mit zwei Scrum-Trainern fand er Wege zur Lösung. In seinem Artikel stellt er einige Ansätze vor. Ein guter Ansatz ist der, täglich eine neue Aufgabe zu definieren. Keine Story darf länger als einen Arbeitstag in Anspruch nehmen. Größere Aufgaben müssen zerstückelt werden, um in einen Tag zu passen. Jede dieser Storys sollte idealerweise eine sichtbare Änderung am Produkt zum Ziel haben, so dass Team und Kunde den Fortschritt sehen können. Laut Seiden können mit diesen Regeln Vertrauen und Transparenz enorm gesteigert werden.
Der zweite Ansatz besteht darin, die traditionelle Definition von Finished Design aufzugeben. Kein Design ist jemals fertig. Hier ist Josh Seiden mit DaVincis Statement einverstanden. Das ist in einer Welt, in der sich die Umstände ständig ändern, umso richtiger. Zudem ändert jedes Produkt auch das Umfeld des Nutzers. Eine nie vollständig abgeschlossene Entwicklung steckt also generell in jedem Produkt selbst. Natürlich muss man verstehen, dass ein Pre-Release nicht gleich einem fertig abgenommenen Produkt ist.
Schließlich weist Seiden noch darauf hin, dass es ungeheuer wichtig ist, zwischen „Done“ und „Abgenommen“ zu unterscheiden. Done ist für alle Scrummer so wichtig, weil es ihre tägliche Arbeit bestimmt. Allerdings ist Done ja nicht immer auch „erledigt“. Ein Erledigt kann aus 27 verschiedenen Done bestehen. Oder mehr. Done ist wichtig. Jede einzelne Aufgabe muss angegangen und erledigt werden. Aber ein finales fertiges Produkt kann oft nicht mit einem einzigen Done gleichgesetzt werden.