Product Owner: Motor oder Sollbruchstelle agiler SW-Projekte? (Teil 1)
Bei Software-Projekten zählt am Ende nur das Produkt, das eine hohe Benutzerakzeptanz mit einer langen Lebensdauer vereinen soll – und das natürlich bei iterativer Weiterentwicklung, gutem ROI und kurzer „time-to-market“. Dieser Beitrag legt dar, warum die richtige Besetzung des Product Owners für agile Software-Projekte überragend wichtig ist.
Durchschnittlich scheitern ca. 70% aller SW-Projekte. Diese Quote ist seit Mitte der 80er Jahre bis heute stabil, wenn man dem bekannten „Chaos-Report“ glauben darf. Unter den Top-Ursachen rangiert dabei immer wieder die Anforderungsqualität: unklar, unvollständig, widersprüchlich, nicht detailliert genug, zu detailliert, nicht testbar, nicht normengerecht – das sind typische Attribute, die vor allem von Entwicklern und Testern angeführt werden, wenn Anforderungen Projekte behindern oder gar scheitern lassen.
Manche frustrierte Softwerker verwenden für dieses verbreitete Symptom achselzuckend sogar eine eigene Abkürzung: GIGO – garbage in, garbage out!
Gute Spezifikationen zu schreiben ist Ingenieursarbeit
Diese Problematik führte zur Einführen der Disziplin Requirements Engineering: Einschlägige Experten (heutzutage oft als CPRE zertifiziert) sind in der Lage, Anforderungen der sog. Stakeholder (englisch: Interessenvertreter) systematisch zu erheben und in die nötige Struktur und Qualität zu bringen, die die Entwicklungs-Phasen eines Projekts (im „Wasserfall“ sind das: Design, Implementierung, Integration und Test) benötigen – vergleichbar Ingenieuren in anderen Disziplinen: man stelle sich einen Maschinenbau-Ingenieur vor, der statt Konstruktionszeichnungen und Stücklisten nur eine vage textuelle Beschreibung der Maschine abgibt.
Soweit die Theorie. In der Praxis hat sich gezeigt, dass auch die besten REs nicht fehlerlos sind – wie übrigens auch die besten Software-Entwickler. Der Grund der erschreckend hohen Fehlerquote ist nicht etwa mangelnde Professionalität, sondern die rasend schnelle Weiterentwicklung der IT: Softwaresysteme werden in einer derartigen Geschwindigkeit komplexer und ändern ihre technischen Grundlagen, dass sich kein tragfähiger, gar „industrieller“ Prozess entwickeln und dauerhaft halten kann. Besonders deutlich wurde das im sog. „Methodenkrieg“ der 90er Jahre: Man versuchte vergeblich, durch immer formalere Spezifikation (ich habe schon Summenberechnungen in UML modellieren müssen) das Durchschlüpfen von fehlerhaften Anforderungen zu verhindern. Denn früh gemachte, aber spät entdeckte Fehler führen bekanntlich zu hohen Folgekosten bzw. Projektverzögerungen. Das sehen Betriebswirte ebenso ungern wie übrigens auch teure Investitionen in Halbfertigbestände – und nichts anderes ist es, wenn Software-Projekte über Monate oder Jahre Budget verbraten, bevor sie Nutzen erzeugen – oder als gescheitert abgeschrieben werden.
„Fail fast, deliver quick and often“: Agil macht alles besser – oder?
Allmählich musste jedem klar sein, dass mit steigender Komplexität die Vermeidung von Fehlern immer unmöglicher wird – das ist übrigens auch ein Problem der Abdeckung bei der Qualitätssicherung, die aber nicht Thema dieses Beitrags ist. Wenn man aber Fehler nicht vermeiden kann, sollte man sie so früh wie möglich erkennen und korrigieren, ggf. sogar für die Zukunft daraus lernen.
Nachdem zumindest für bestimmte Kategorien von Software alle schwergewichtigen, formalen und dokumentationslastigen Prozesse sich als tendenziell kontraproduktiv erwiesen hatten, postulierte eine Gruppe von Software-Pionieren eine revolutionären Idee: Man könnte ja zur Abwechslung mal miteinander reden. Man könnte direkt Software schreiben statt lange Dokumente. Man könnte Dinge in definiert kurzer Zeit ausprobieren und notfalls wegschmeißen, statt sie sich über ausufernd lange Zeit theoretisch (und dann doch nicht funktionsfähig) zu überlegen und sich formal gegen ihr späteres Scheitern abzusichern.
Diese und ähnliche Ideen wurden bekanntlich als agiles Manifest formuliert, nachzulesen unter agilemanifesto.org. Damit trat eine Methodik ihren Siegeszug an, der bis heute ungebrochen anhält: Die agile Software-Entwicklung.
Was Google kann, können wir auch, oder?
Softwareentwicklung ist heute kaum mehr ohne agile Methodik vorstellbar. Während früher höchstens alle paar Monate eine neue Softwareversion unter erheblichen Geburtsschmerzen auf den Markt kam, bringen heute viele Unternehmen teilweise zig Versionen pro Tag „in Produktion“ oder zumindest auf Integrations- und Testsysteme – und das meist in deutlich besserer Qualität. Das ist neben der Automatisierungsquote auch dadurch zu erklären, dass kleine Veränderungen einfacher zu kontrollieren als große – von der gefürchteten „big-bang“-Integration früherer Jahrzehnte ganz zu schweigen.
Besonders Start-Ups profitieren von kurzer „time-to-market“ und exzellentem ROI ihrer Softwareinvestitionen. Wie sehr, wird anhand der Tatsache deutlich, dass Google, Amazon und ähnliche Internet-Giganten vor nicht allzu langer Zeit selber Start-Ups waren! Im Zuge der agilen Entwicklung dieser Unternehmen entstanden viele Methoden und Technologien, die nun auch anderen zur Verfügung – zum größten Teil sogar open-source.
Solche Softwareerfolgsgeschichten rufen natürlich auch etablierte Unternehmen anderer Branchen auf den Plan. Wer heute etwas auf sich hält, „macht Scrum“. Dabei wird oft übersehen: Eines unterscheidet die „big player“ des Internets erheblich von durchschnittlichen Firmen aus anderen Branchen: Ihr ureigenstes Business baut auf Software auf. Sie waren nie etwas anderes als Internet-Unternehmen und haben das Netz erheblich mit geprägt. Oft gehören die Firmengründer zum Core-Entwicklungsteam, zumindest aber haben sie sehr klare Visionen, was ihre Software leisten soll; weil sie wissen, was technisch möglich ist und wie das Internet funktioniert. Bei diesen Firmen gehen agile Software-Entwicklung und „business agility“ Hand in Hand bzw. sind zwei Seiten einer Medaille.