Was fordert agile Softwareentwicklung von den Kunden?
18.03.2021 | Oliver Seitz | 8 min Lesezeit
merken
Stern Icon
Stern Icon
Briefumschlag Iconper E-Mail erinnern X Icon
Ladekreisel
Bitte geben Sie eine E-Mail Adresse ein!
Das Datum darf nicht in der Vergangenheit liegen!
Stern Icondiesen Artikel merken
Stern Icondieser Artikel ist auf der Merkliste

Agile Softwareentwicklung aus Kundensicht: Mein Auftragnehmer möchte agil arbeiten – und jetzt?

-

Ich bin euch etwas schuldig. Mittlerweile schmücken diverse Artikel zur agilen Softwareentwicklung unser digatus Magazin. Alle informieren umfassend über Methoden, Prinzipien, Werte, Rollen, Manifeste und vieles mehr. Nachdem ich erzählt habe wie großartig das Ganze ist, möchtet ihr jetzt (hoffentlich) endlich mit der agilen Entwicklung starten! Aber was genau muss ich denn jetzt als Kunde tun und was besser nicht? Wie unterscheidet sich das für mich von klassischer Entwicklung? Was sind die Spielregeln? Wie unterstütze ich die Entwicklung? Genau diese Antworten bin ich noch schuldig und damit richtet sich dieser Artikel direkt an euch, die Kunden.

Worauf solltet ihr bei der Vertragsgestaltung von Entwicklungsprojekten achten?

-

In aller Regel wird der Auftragnehmer für einen Dienstvertrag plädieren. Aber Moment: Da fehlt mir ja die komplette rechtliche Sicherheit, dass ich das bekomme was ich möchte! Das mag wohl stimmen. Aber während der Werkvertag dir zusichert was du möchtest, ermöglicht dir der Dienstvertrag zu bekommen was du brauchst. Der Werkvertrag, einmal abgeschlossen, liefert genau was spezifiziert wurde. Das erfordert ein wahres Meisterwerk an Spezifikation. Genau das wollten wir doch vermeiden. Anstatt drei Monate an einem Spezifikationsroman zu schreiben, erstellen wir doch lieber den ersten Prototypen. Davon profitieren wir viel mehr:

Ich weiß, ob der Auftragnehmer fähig ist umzusetzen was ich plane.
Ein Werkvertrag allein garantiert mir noch nicht, dass der Auftragnehmer überhaupt bzw. in der gewünschten Qualität liefern kann. Für Menschen, die ihre Zeit gerne vor Gericht verbringen sicher verlockend, aber ein erfolgreiches Projekt sieht anders aus.

Drei Monate Entwicklung gleich drei Monate Erfahrung.
Erfahrung die in Optimierungen des Plans gesteckt werden kann. So präzise, dass sich keine Änderungen ergeben, kann ich meine Software gar nicht durchdenken. Was oftmals nämlich in Vergessenheit gerät ist, dass die Software von vielen Nutzern in unterschiedlichen Rollen bedient wird. Zu meinen, dass man sich vollkommen in den Job der Kollegen eindenken und ihnen das optimale Werkzeug liefern kann, ist ein typischer Fall von Selbstüberschätzung.

Vermeidung von Kommunikationspannen.
Kommunikation ist einer der komplexesten Vorgänge in unserem Leben, gemessen an der Einfachheit zu kommunizieren und der Wahrscheinlichkeit falsch zu verstehen. Wieso also riskieren, dass ein Projekt durch das Fehlinterpretieren einer schriftlichen Spezifikation gefährdet wird? Unsere Auffassung ist manipuliert durch unterschiedlichste Faktoren wie Vergangenheit, Erziehung und Bildung. Im Dialog kann ich solche Missverständnisse sofort beseitigen und spare somit Zeit und Geld.

Wenn ihr also einem Auftragnehmer begegnet, der euch einen Werkvertrag vorlegt, solltet ihr selbst eher skeptisch werden. Höchstwahrscheinlich leidet dieser nämlich unter genau der angesprochenen Selbstüberschätzung und entwickelt nicht agil, sondern „agil“.
Agile Entwicklung arbeitet mit einem Vertrauensvorschuss, die klassischen Vorgehensweisen eher mit fragwürdigen Versprechen.

An welchen Meetings solltet ihr teilnehmen?

-

Ist der Dienstvertrag abgeheftet, beginnt die Arbeit. Für die Entwickler und für euch. Denn agile Softwareentwicklung bedeutet einen intensiven Austausch. Der mit SCRUM arbeitende Auftragnehmer wird von euch erwarten am Sprintreview und Sprintplanning teilzunehmen. Je nach Teamgröße kann dieser Termin bis zu einem Tag in Anspruch nehmen.
Sprintreview und Sprintplanning sprechen euch an, die Kunden und sind eure Möglichkeit in den Entwicklungsprozess einzugreifen. Das Entwicklungsteam fordert darin eure Meinung zu den Ergebnissen des letzten Sprints (Produktinkrement) und fragt was ihr als nächstes benötigt.

Das Sprintreview ist die Abnahme der geleisteten Arbeit des letzten Sprints. Das Team stellt euch hier die umgesetzten Funktionalitäten vor. Dadurch habt ihr die Möglichkeit Funktion und Qualität zu bewerten. Eventuelle Probleme werden notiert und können im kommenden Sprint behoben oder nach hinten verschoben werden. Um der vorher angesprochenen Selbstüberschätzung entgegenzuwirken, rate ich euch diejenigen aus eurem Unternehmen mitzunehmen, die später am Meisten mit den vorgeführten Features arbeiten werden. Es wird sich auf jeden Fall lohnen, denn das Wissen der Person, die täglich mit dem Problem konfrontiert ist, kann aus einem guten ein sehr gutes Endprodukt machen.

Das Sprintplanning dient zur Planung des nächsten Sprints. Ein guter Product Owner wird zusammen mit euch die User Stories bereits nach Priorität sortiert haben. Die einzelnen Aufwände hat das Entwicklerteam zuvor mit dem Product Owner in einem Grooming oder Refinement Meeting geschätzt. Wichtig ist zu wissen, wer bestimmt wie viel im nächsten Sprint erledigt wird: Das Team. Schließlich ist es auch das Team, welches die Arbeitslast am Ende bewältigen muss. Durch ordentliche Vorbereitung dauert das Sprintplanning meist wesentlich kürzer als das Sprintreview.

Sprintreview und Sprintplanning können also als kleine Werkverträge angesehen werden, die jeden Sprint zwischen Entwicklerteam und Kunde geschlossen werden. Sie stellen sicher, dass die Entwickler nicht planlos Arbeiten, sondern einen äußerst genauen Plan verfolgen. Dementsprechend ist aktive Mitarbeit wichtig. Ein guter SCRUM Master wird euch darauf auch durchaus hinweisen.

Kommunikation als wichtiger Faktor im Entwicklungsprozess

-

Neben Sprintreview und Sprintplanning ist stetige Kommunikation auf Augenhöhe essenziell. Das bedeutet: Reserviert euch Zeit, in der ihr für das Entwicklerteam erreichbar seid. Wenn ein Product Owner erst eine Woche auf Antworten warten muss, hat er am Ende nicht mehr genügend Zeit den nächsten Sprint vorzubereiten.
Gerade zu Beginn werdet ihr vermutlich nur so durchlöchert mit Fragen. Dementsprechend wichtig ist es einen Kreis mit Leuten aufzubauen, die ohne großes Nachdenken antworten können. Hier spielt auch wieder das Thema der Selbstüberschätzung mit rein. Fragen beantworten die Leute, die später mit der Antwort leben müssen. Meistens sind das die Leute, die die Frage auch am schnellsten beantworten.
Häufige Kommunikation ist gut, Kommunikation auf Augenhöhe ist besser. Mit dominantem Verhalten werdet ihr nicht weit kommen. Ihr braucht die Entwickler, um eure Ideen umzusetzen. Die Entwickler brauchen euch, um Anforderungen zu erarbeiten. Hier ist kein Platz für Hierarchie. Ihr sagt den Entwicklern nicht was sie tun sollen, sie teilen euch mit was sie brauchen. Trotzdem gilt weiterhin „der Kunde ist König“. Die Entwickler werden also nicht plötzlich ihren eigenen Plan entwickeln.

Warum sich ein frühzeitiger Produktiveinsatz der Software lohnt

-

Nehmen wir an: Der Dienstvertrag ist unterschieben, ihr nehmt an Sprintreview und Sprintplanning teil und es herrscht rege Kommunikation. Dadurch habt ihr alle Maßnahmen getroffen, die dem Team helfen Fahrt aufzunehmen. Sicherlich wird es vorkommen, dass man euch um das ein oder andere Extra bittet. Das zähle ich jetzt aber ganz elegant zu dem Punkt Kommunikation. Da ist allerdings noch eine letzte Sache, auf die ich aufmerksam machen möchte. Setzt eure Software so früh wie möglich produktiv ein. Dadurch überprüft ihr zwei Dinge.

Das Team implementiert die wichtigsten Features zuerst.
Ziel ist es, die zentralen Anwendungsfälle zügig umzusetzen, ohne sich in Details zu verlieren. Wenn eure Software nach Monaten der Entwicklung immer noch nicht den einfachsten Anwendungsfall abbilden kann, dann läuft etwas falsch.

Die implementierten Features sind praxistauglich.
Sprintreview und Tests tragen bereits wesentlich zur Qualitätsverbesserung bei. Allerdings werden dabei Features und nicht Szenarien getestet. Praxistauglichkeit überprüft man nicht in gestellten Szenarien, sondern live. Die Suche, auf wenigen Daten performant, ist mit echten Daten viel zu langsam. Diese Animation, im Test noch so nett anzusehen, nervt und kostet Zeit. Alles Punkte die in einem gestellten Test leider nicht so sichtbar sind wie im täglichen Einsatz.
Wir bauen hier keinen neuen Marsroboter, bei dem ein wirklicher Praxistest tatsächlich recht schwierig ist. Wir haben nur oft Angst unfertige Software zu präsentieren. Die Kollegen sind bestimmt zunächst irritiert, warum man ihnen etwas Unfertiges vorsetzt. Und wieder ist Kommunikation der Schlüssel: „Wir lassen gerade eine Software für X, Y, Z entwickeln und wir möchten, dass die Software dich am Ende optimal unterstützt. X funktioniert bereits, Y, Z noch nicht. Nachdem du dich in dem Bereich sehr gut auskennst, bitte ich dich Szenario X mit dieser neuen Software zu erledigen und mir Feedback zu geben was gut funktioniert und was nicht“. Der Kollege fühlt sich in den Prozess involviert, als Feedbackgeber wertvoll und hat Sicherheit die Software soll ihn unterstützen, nicht ablösen. Er ist für den Erfolg des Projektes ab sofort maßgeblich mit verantwortlich. Ein nachträgliches „Aber das funktioniert so ja überhaupt nicht“ wird es nicht geben.

Fazit

-

Ja, ihr als Kunden habt schon einiges zu tun. Aber das ist gerade der Unterschied zu klassischen Vorgehensweisen. Anstatt sich mit abstrakten Anforderungen und komplexen Verträgen herumzuschlagen, verwenden wir eure Zeit lieber, um tatsächlichen Mehrwert zu schaffen.

Autor Profilbild

Oliver Seitz

-