Ist das Manifest für Agile Softwareentwicklung noch zeitgemäß und wie denken Jeff Patton und David Pereira darüber?
Mein Agile Leadership Training beginnt damit, dass die Teilnehmenden die Wertepaare des Manifests für Agile Softwareentwicklung zuordnen.
Dabei kommt immer die Frage auf: „Ist das Manifest für Agile Softwareentwicklung noch zeitgemäß?“ Im Kurs wird der Punkt „funktionierende Software“ immer sehr kontrovers diskutiert. Beschreibt „funktionierende Software“ ein Produkt? Wenn „ja“, für wen? Oder ist damit das Liefern von Wert gemeint?
Das Problem: Funktionierende Software ist kein Garant für Ergebnisse.
Schauen wir uns an, wie Jeff Patton und David Pereira, zwei bekannte Vordenker im Produktmanagement, diesem Problem begegnen.
Das Manifest für Agile Softwareentwicklung ist für IT-Dienstleistungsanbieter
Jeff Patton schreibt, dass es kein Geheimnis ist, dass das Manifest für Agile Softwareentwicklung von Leuten geschrieben wurde, deren Fokus darauf lag, Software zu entwickeln. Er liest aus den Prinzipien und Wertepaaren heraus, dass das Manifest in Wirklichkeit für IT-Service-Anbieter geschrieben wurde.
Betrachten wir etwa das Erste der zwölf Prinzipien:
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.
Hieraus schließt Jeff Patton, dass die Begriffe „Kunde“, „Nutzer“ und „Unternehmen“ fast austauschbar sind. Was Sinn ergibt, wenn wir Software gegen Geld entwickeln. Dieser IT-Service-Dienstleister-Gedanke ist noch in den meisten großen Konzernen und Behörden tief verankert. Diese Dienstleister machen ihr Geld, indem sie Zeit- und Material-Verträge mit ihren Kunden abschließen. Das bedeutet also, der Service, den sie bieten, ist das Produkt. Ob die Nutzer das Produkt verwenden oder es sie begeistert, ist nicht das Problem des Unternehmens.
Und das ist das Problem!
Denn das IT-Dienstleister-Modell trennt die Verantwortlichen für die Produktergebnisse von denen, die für die Produktlieferung zuständig sind. Und das kann nicht gut für ein Unternehmen sein, denn der Erfolg eines Unternehmens ist nun mal zweifelsohne durch die Ergebnisse, die Nutzer mit dem Produkt erzielen, bestimmt. Mit Ergebnissen meine ich hier die Dinge, die die Nutzer tun, sagen und fühlen, welche sich positiv auf das Unternehmen auswirken.
Jeff Patton ist überzeugt, dass die Art und Weise, in der das Manifest für Agile Softwareentwicklung geschrieben ist, diese Trennung der Verantwortung von Produktlieferung und Produktergebnissen fördert. Aus seiner Sicht fehlt dem Manifest das Produktdenken. Sein Vorschlag, um das Produktdenken über die IT-Dienstleister-Modell-Denke zu stellen, lautet, ein weiteres Wertepaar in das Manifest aufzunehmen:
Erfolgreiche Ergebnisse zählen mehr als effiziente Umsetzung.
Wie in den übrigen Teilen des Manifests für Agile Softwareentwicklung bedeutet es auch hier: Obwohl wir die Werte auf der rechten Seite für wichtig erachten, schätzen wir den Wert auf der linken Seite mehr.
Das Manifest für Agile Softwareentwicklung löst Probleme einer vergangenen Ära
Für David Pereira stellt sich das Problem noch gravierender dar. Seiner Ansicht nach konzentriert sich das Manifest primär auf den Output, ohne das Ergebnis zu erwähnen.
Allerdings kann das Entwickeln von Features niemals Wert garantieren.
Und die Herausforderungen, mit denen wir heute konfrontiert sind, sind völlig andere als die, mit denen wir konfrontiert waren, als das Manifest für Agile Softwareentwicklung verfasst wurde.
Hierfür führt Pereira zwei Beispiele an:
- Das Resultat der Annahme, „Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten“, war, dass etwas gebaut wird, das den Business Stakeholdern gefällt, aber die Bedürfnisse der Anwender nicht berücksichtigt.
- „Eine funktionierende Software ist der wichtigste Maßstab für den Fortschritt.“ Diese Vorstellung ist aus seiner Sicht eben kein Maß für Fortschritt, denn alle Funktionen sind irrelevant, solange die Endnutzer nicht von ihnen profitieren können.
Aber die zentralen Fragen, welche 21 Jahre nach dem Manifest über Erfolg und Misserfolg in der Produktentwicklung entscheiden, werden im Manifest nicht beantwortet. Fragen wie:
– Was ist das Produkt?
– Wer sind die Kunden?
– Was bedeutet Wert für die Nutzer des Produkts und für das Unternehmen?
– Wie überprüfen wir, ob die Lieferung des Produkts wirklich den Wert gesteigert hat?
Sein Vorschlag für das Problem, dass funktionierende Software kein Garant für Ergebnisse ist, ist ein neues Manifest:
Das Produktmanifest.
Hier sein Entwurf:
Wie können wir das Manifest für Agile Softwareentwicklung heute noch verwenden?
Ich denke, der am weitesten verbreitetste Fehler ist, ein Manifest, welches vor über 20 Jahren geschrieben wurde, eins zu eins in der heutigen Welt anwenden zu wollen. Jeff Patton und David Pereira liefern hier zweifelsohne spannende Ansätze, um dies in Zukunft zu vermeiden.
Ich stimme beiden zu, dass wir die aktuellen Herausforderungen in der Produktentwicklung nicht mit einer Denkweise von 2001 lösen können. Gleichwohl sollte jeder Agile Leader oder Agile Coach wissen, auf was sich der Begriff „Agilität“ bezieht. Und deshalb werde ich das Manifest für Agile Softwareentwicklung weiterhin unverändert im Professional Agile Leadership Training mit den Teilnehmenden besprechen, aber den Fokus vermehrt auf den ersten Satz richten:
Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.
Kann es sein, dass der Verfasser nach dem Vorschlag für das weiteres Wertepaar im Agile Manifesto “Erfolgreiche Ergebnisse zählen mehr als effiziente Umsetzung.” eine links/rechts -Schwäche hatte?
“Wie in den übrigen Teilen des Manifests für Agile Softwareentwicklung bedeutet es auch hier: Obwohl wir die Werte auf der linken Seite für wichtig erachten, schätzen wir den Wert auf der rechten Seite mehr. ”
Sind es nicht die Werte auf der linken Seite, die wir als wichtiger erachten?
Vielen Dank D. Bertsch für die wachsamen Augen. Ich habe es korrigiert.
Hier der Direktlink zum “The Agile Product Manifesto” von David Pereira:
https://d-pereira.com/the-agile-product-manifesto-is-born/
Ich finde den Outcome-über-Output Ansatz auch gut. Das Product Manifest selber ist noch etwas ungeschliffen. Beim Scrum kann man fast alle Principles auf die Values zurückführen, das kann ich (zugegeben: in 10 Minuten) bei dem Product Manifesto noch nicht. Ich habe ab und an den Eindruck es ist ein Antipattern einfach als umgedrehte Anweisung (“tue das nicht” -> “tue genau das”) formuliert. Aber ich finde es trotzdem wertvoll, in eine Welt in der Produkte nicht mehr nur aus Features bestehen.
Und: sehr gute Analyse, auf welchen Glaubenssätzen oder mit welchem Mindset das Agile Manifest damals entstanden ist. Der nicht mehr so ganz passende One-Size-Fits-All ist inzwischen eine Herausforderung an eine Weiterentwicklung des Manifests. Wäre auch merkwürdig, wenn ein Manifest nach mehr als 20 Jahre unverändert gültig sein kann, in sich einer schnell veränderten (IT-) Umwelt.