Scrum? Agil? Egal
Erstaunlich, wie unklar das Verständnis und die Definitionen von Scrum und agiler Methoden noch sind. Scrum ist für viele (die meisten?) ein Synonym für agiles Vorgehen und agile Methoden. Daher werden die Begriffe Scrum und Agil immer wieder in einen Topf geworfen. Und ebenso Projekt- und Produktmanagement, was aber ein noch viel gewichtigerer Unterschied ist.
Auch die vielfältig vorhandenen Definitionen allwissender Quellen sind sich nicht immer einig:
“Scrum ist […] ein Vorgehensmodell der Softwaretechnik”
(wikipedia.de)
“Scrum is […] agile software development framework for managing […] product […] development”
(wikipedia.com)
“Scrum – Agiles Projektmanagement”
(Buchtitel von Roman Pichler)
Das Agile Manifest wiederum sagt dazu: “We are uncovering better ways of developing software”.
Es geht um Produkte
Es geht also um Softwareentwicklung und Projektmanagement?
Primär ja. Aber was ist denn Software?
Software ist ein Produkt, dass demjenigen, der sie nutzt einen Wert oder Nutzen bietet.
Mit Software wird entweder etwas überhaupt möglich gemacht, erleichtert oder zumindest angenehmer gemacht. Im geschäftlichen Umfeld ist Software in Code “gegossenes” und bereits vorhandenes Wissen der Geschäftsdomäne.
Das Ergebnis aller Mühen ist stets ein Produkt – nämlich die laufende Software selbst.
Bei Projekten hingegen muss es sich nicht zwangsläufig auch um Produkte gehen. Bei Projekten kann man z.B. auch schon vorhandene Produkte einsetzen, um ein Ziel zu erreichen.
Wichtigstes Buzzword: Product
Weil es in den letzten Jahren immer klarer wird, was den eigentlichen Erfolg von guter und erfolgreicher Software und deren Entwicklung geht: um Produkte.
Und zwar um Produkte, die für deren Benutzer einen unmittelbaren Wert darstellen, hilfreich sind oder auch nur Spaß machen. Auf jeden Fall um Produkte, die man oft und gerne einsetzt, weil sie etwas bringen.
Und diese erstaunliche Erkenntnis ist wesentlich älter als alle agilen Methoden und deren Derivate zusammen. Baue Produkte, die die Leute brauchen, wollen, lieben und kaufen – und setze dich dann zur Ruhe…
Schaut man sich die aktuelle Lage in vielen Unternehmen, Diskussionen und Veröffentlichungen an, so sieht man immer noch ein riesiges Missverhältnis der eigentlichen Bedeutung.
Google liefert zum Suchbegriff “Scrum” ca. 110 Mio. Treffer, zu “Agile Product” und verwandten Begriffen gerade mal ein paar zehntausend Treffer. Dieses Verhältnis beobachte ich auch in der Praxis. Über Scrum, Scrum Master, Velocity, Sprints wird viel geredet. Bei Begriffen wie Planning, Backlog, Grooming, Akzeptanzkriterien wird es schon ruhiger.
Product Owner first!
Und wie gute User Storys geschrieben und geschätzt werden, ist scheinbar immer noch eine Geheimwissenschaft. Aber genau dies entscheidet primär darüber, wie gut ein Produkt wird. Technisch kann ich das tollste Produkt bauen, dass die Welt je gesehen hat. Aber war es nicht das, was seine Nutzer erwartet haben und sehen sie in ihm keinen Wert, ist es gescheitert. Beispiele dafür gibt es unzählige.
Das ist die primäre Aufgabe eines Product Owners aber auch des restlichen Teams: das geforderte Produkt verstehen.
Unternehmen, die sich mit agiler Produktentwicklung und evtl. Scrum (oder Kanban etc.) befassen wollen, sollten zuerst ihre für Produkte verantwortlichen Mitarbeiter und Projektmanager agilisieren.
Stellt zuerst einen fähigen Product Owner ein, sorgt dann dafür, dass eure bisherigen Prozesse agil werden und dann überlegt euch, welche Methoden der Softwareentwicklung ihr braucht und einsetzen wollt. Gibt dem PO aber auch die nötigen Kompetenzen und den Spielraum, den er oder sie dafür braucht – und macht ihn nicht zum Proxy PO.
Denn nur weil Scrum eingesetzt wird, wird eine Produkt- oder Softwareentwicklung nicht agil. Umgekehrt schon.