Wenn Du in einem Scrum-Team arbeitest, weisst du zweifellos, dass du nach einem Rahmenwerk zur Entwicklung, Auslieferung und Erhaltung von komplexen Produkten arbeitest. Dass ihr ein Product Backlog und einen Product Owner haben solltet:
"Scrum ist ein Rahmenwerk zur Entwicklung, Auslieferung und Erhaltung komplexer Produkte."
"Sofern ein Produkt existiert, gibt es auch das dazugehörige Product Backlog."
"Der Product Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht."Scrum Guide (de), https://www.scrumguides.org/
Für einige Organisationen und Teams kann dies eine ziemlich grundlegende Frage sein, denn: Kann ein Scrum Team geformt werden, kann eine Organisation eine geeignete Product Ownerin oder einen geeigneten Product Owner, ein Team und Rollen nach Scrum identifizieren, ohne vorher verstanden zu haben, was die Produkte der Organisation sind oder sein werden? Hm. Schwierig.
Sagt der Scrum Guide. Genau. Aber wie soll ein Product Backlog zustande kommen, wenn wir nicht wissen, was ein Produkt ist und was die Produkte der Organisation sind oder sein sollen? Wir müssen also zuerst wissen, was ein Produkt ist oder welche es zukünftig geben soll:
In den meisten Fällen scheint es einfach, die Produkte des Unternehmens zu identifizieren. Zum Beispiel könnte sich ein unternehmensinterner Anbieter von datenbasierten Reports einer Bank jeden Report, der aus dem Datawarehouse bezogen werden kann, den ein Nutzer aus dem Warehouse "ziehen" kann, als Produkt vorstellen. Aber selbst das könnte eine vereinfachte - eine zu einfache - Betrachtung sein. Nehmen wir z. B. die Schweizerische Bundes Bahnen:
Einige Mitarbeitende des Unternehmens werden argumentieren, dass die SBB bloss eines tut: Menschen und Güter von einem Standort zum anderen zu bringen. Dass es trotz der über 30'000 Mitarbeitenden, bloss ein "wirkliches" Produkt gibt.
(Ein Unterhaltszug der SBB)
Andere werden argumentieren, dass es viele Produkte innerhalb der SBB gibt: So verfügt die SBB z. B. über eine Website mit einem geschützten Bereich, über die man Bestellungen vereinfacht ausführen kann, bisherige Bestellungen einsehen kann u. Ä. Natürlich hat die SBB auch ein System zur Überwachung und Planung von Wartungsarbeiten. Oder zur Leitung des Fahrbetriebs. Oder zur Einsatzplanung von Mitarbeiter*innen. Oder Automaten für den Verkauf von Tickets auf Bahnsteigen. Oder eine eigene iOS App. Oder. Oder. Oder.
Aber halt: Sind das alles einzelne Produkte? Was zeichnet ein Produkt aus? Wie lässt sich ein Produkt definieren? Ich las mal eine - für mich sehr treffende - Definition:
Ein Produkt (physisch oder nicht physisch) ist etwas, was durch einen Prozess entsteht und in einem bestimmten Markt Vorteile bringt.
(Unbekannt)
Und was schreibt Wikipedia dazu:
"Unter einem Produkt wird in der Betriebswirtschaftslehre ein materielles Gut oder eine (immaterielle) Dienstleistung verstanden, die das Ergebnis eines Produktionsprozesses ist".
Also, hm.
(Ein Sessel in einer Seitengasse Englands)
Ein Sessel ist ein (physisches) Produkt. Hat ja ein Preisschild. Da sind wir uns einig. LibreOffice ist ein (digitales) Produkt - ohne Preisschild. Check. Beratungsdienstleistung ist ein (nicht physisches) Produkt. Okay. Aber: Ein Produkt kann sogar nur eine Idee sein, z. B. ein patentierbarer Algorithmus! Gar das Geheimnis, wie man eine höhere Reichweite auf LinkedIn bekommt? Nun, bei Letzterem bin ich mir persönlich nicht ganz sicher. Sicher ist, dass dies einige interessieren würde ;).
Wie auch immer: Alle diese Dinge entstehen durch einen Prozess, durch eine oder mehrere Tätigkeiten und erzeugen auf einem bestimmten Markt einen Vorteil. Restaurant ohne Stuhl. Diplomarbeit ohne LibreOffice. Agile Transformation ohne Beratung. Künstliche neuronale Netze ohne Idee. Ne, das geht net.
Interessant dabei ist auch: Der Prozess, der ein Produkt erstellt, muss nicht formal oder definiert sein. Die Schöpfer des Produkts sind sich des Prozesses möglicherweise nicht einmal bewusst. Aber eine Form der Aktivität geht in die Entwicklung jedes Produkts ein. Ach so.
Ein Produkt A kann Teil des Produkts B sein. Und das Produkt B ist Teil des Produkts A: Ein Schulfüller kann beispielsweise austauschbare Tintenpatronen haben. Der Schulfüller ist ein Produkt A. Aber auch die Tintenpatronen im Inneren des Schulfüllers sind es: Produkt B. Das eine funktioniert ohne das andere nicht. Beides ist einzeln erhältlich. Beides alleine sind Teilprodukte.
Wenn wir Teilprodukte innerhalb eines grösseren Produkts identifizieren, müssen wir darauf achten, dass jedes Teilprodukt einen Marktvorteil erzeugt. Die obige Definition besagt nicht, dass etwas gekauft werden muss, damit es ein Produkt ist, nicht immer muss ein Preisschild am Produkt befestigt sein. Aber um als Produkt betrachtet zu werden, muss der Artikel einen Bedarf oder Wunsch erfüllen.
Dies gilt für vorgefräste Beine eines Stuhls und Ersatztintenpatronen für einen Schulfüller. Bei der Definition von Produkten ist es wichtig, jedes Produkt so zu definieren, dass es einem Markt Vorteile bringt.
Wie kann man wissen, dass ein "Etwas" (das vermeintliche Produkt) etwas ist, was durch einen Prozess entstand und einem Markt der SBB Vorteile bietet? Wie können wir einer SBB helfen, ihre Produkte zu identifizieren?
Easy: Es ist einfach zu erkennen, dass der Transport von Menschen oder Güter von einem Ort zum anderen ein Produkt ist: Da ist ein Prozess, eine Aktivität, welche einen Mehrwert für Menschen ergibt, die bereit sind, dafür zu bezahlen.
Aber halt: Was ist mit der Website? Mit dem System zur Überwachung und Planung von Wartungsarbeiten. Dem System zur Leitung des Fahrbetriebs. Oder jenem für die Einsatzplanung von Mitarbeiter*innen usw.?
Ich behaupte, dass dies alles auch Produkte sind. Denn: Sie entstehen alle durch einen Prozess und sind Dinge, welche einem spezifischen Markt Vorteile bringen. Doch welchem Markt?
Hm, z. B. könnte man argumentieren, dass Mitarbeitende der SBB (Markt) davon profitieren, dass die Instandhaltungsüberwachung und -planung computergestützt statt manuell auf Papier erfolgt und somit Informationen eindeutig, zentral und für alle Beteiligten einsehbar sind (Vorteil).
Oder die Website der SBB, welche zukünftigen Passagieren erlaubt, ihre Reise zu planen und entsprechende Tickets zu kaufen. Oder Reservationen zu tätigen. Dafür gibt es einen Markt. Aber sicher!
Also ja, die SBB hat ein grosses Produkt - und viele Teilprodukte.
Auch wenn heute gefühlt alle bloss noch von Produkten sprechen: Wenn man von Produktentwicklung spricht, ist nicht alles ein Produkt!
Es kann z. B. gefährlich sein, etwas als ein Produkt zu betrachten, was bloss von einer Person oder einer ganz kleinen Gruppe genutzt wird, welche das Ergebnis "verfeinert": Dies könnte z. B. dazu führen, dass Software-Code (das Produkt) einer Gruppe von Software-Testern (dem Markt) zum Testen zur Verfügung gestellt wird, sodass diese die Qualitätssicherung durchführen können (Vorteil). Das Produkt also der ungetestete Code ist. Autsch. Das schmerzt dann.
Das ist nicht nur ein Schritt zurück in die sequentielle (oder phasenweise) Entwicklung, sondern auch eine Form der Suboptimierung - vielleicht dank dem Agilen Wasserfall. Stopp. So will ich das nicht verstanden haben.
Wie am Beispiel der SBB erkennbar: Es kann eine breite Palette an Produkten in einem Unternehmen geben. Und Menschen wie Güter von einem Standort zum anderen zu bringen, ist nicht "das eine Produkt" der SBB.
Wenn ein Produkt so gross ist, dass es mehrere Märkte bedient, empfehle ich nach mehreren (Teil-) Produkten zu suchen, welche einen einzigartigen Markt bedienen. Und mehrere Product Owner mit deren Product Backlogs zu definieren.
Es wäre einfach, LibreOffice als ein einziges Produkt zu betrachten. LibreOffice ist jedoch eine Produktreihe, welche unterschiedliche (Teil-) Produkte beinhaltet, welche wiederum unterschiedliche Funktionen bieten und unterschiedliche Märkte bedienen.
Klar, teilweise überlappen sie sich. Dennoch. Ich würde mir Writer, Calc, Impress, Draw, Base und Math als eigenständige Produkte vorstellen: Jedes hätte seine eigene Product Ownerin oder seinen eigenen Product Owner und sein eigenes Product Backlog.
Klar, bei einem solch grossen Produkt wie LibreOffice ist es sehr wahrscheinlich, dass es auch (Teil-) Produkte gibt, welche durch andere Produkte wie Writer und Impress genutzt werden: Ich denke da z. B. an die Rechtschreibprüfung. Dafür würde ich mir eine Product Ownerin oder einen Product Owner und ein Product Backlog vorstellen. In sich komplex genug. Oder wie habt ihr es so mit der Rechtschreibung? Voilà.
Und ja, wenn man so grosse Produkte wie die Website der SBB entwirft, weiterentwickelt und betreut: Da kommt die Frage auf: "Wie handhabe ich das denn nun?". Hier empfehle ich, z. B. einen Blick auf Large-Scale Scrum (LeSS) zu werfen: Immer noch Scrum. Immer noch eine Product Ownerin oder ein Product Owner mit einem Product Backlog. Einfach mit mehreren Teams.
(Grafische Darstellung des LeSS Frameworks)
"Und im Extremfall von LibreOffice - die haben bestimmt mehr als acht Teams am Start!?" Ja, richtig, denn abgesehen davon, dass dies ein OpenSource Produkt und daher speziell ist: Schau dir z. B. LeSS Huge, Scrum@Scale, Nexus oder SAFe an. Und sprich mit uns von dot consulting AG!
(Grafische Darstellung des LeSS Huge Frameworks)
Digitale Technologien und Innovationen, Digitale Strategie und Wertschöpfung, Geschäftsmodell Innovation, Entwicklung von Digitalen Produkten, Change Management, Organisationsberatung und -entwicklung, Innovation und Leadership, Agile und Resiliente Organisationen - da fühlen wir uns von dot consulting AG zuhause und unterstützen dich mit Leidenschaft!
Keine Kommentare bis jetzt
Lass uns wissen, was du darüber denkst.