Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Warnhinweis: Produkte entstehen nicht von selbst

Wozu Scrum? Die Antwort auf diese Frage variiert von Unternehmen zu Unternehmen – und dennoch geht es meistens um schnellere Auslieferungen, bessere Qualität, stärkere Kundeneinbindung, zufriedene Mitarbeiter.

 

All das ist wichtig und gut, doch beantwortet es nicht die Frage nach dem Wozu. Denn ich kann großartigen Code schreiben, alle zwei Wochen releasen, meine Kunden ständig dabeihaben und immer noch nicht wissen, welchen Zweck ich damit verfolge. Solange die Geschäftszahlen stimmen, mag das nicht weiter schlimm erscheinen. Gewinn ist ein täuschend echter Unternehmenszweck.

 

Verändern sich aber die Marktbedingungen (und das ist heute eher die Regel als die Ausnahme), ist die eigene Ausrichtung zu überprüfen: Ist das, was sich bisher blendend verkauft hat, auch heute noch das Richtige? Und spätestens da stellt sich die Frage nach dem Wozu. Um sie zu beantworten, muss ich erstmal verstehen, wie mein Produkt aussehen könnte und was es zum Produkt macht. Wir haben dafür eine eigene Rolle in Scrum: Den Product Owner. Ohne die Frage nach dem „Wozu“ wären Product Owner überflüssig: Die Entwicklungsteams könnten direkt mit Kunden und Benutzer sprechen, seine Anforderungen aufnehmen und dann umsetzen.

Was ist das denn: ein Produkt?

Laut Wikipedia ist es das Ergebnis eines vom Menschen bewirkten Transformationsprozesses, in dem Produktionsfaktoren wie Güter und Dienstleistungen in einen Output umgewandelt werden. Das ist sicher nicht falsch, aber es zieht am Wesentlichen vorbei.

 

Ein Produkt ist für mich so etwas wie ein Leuchtturm in der Beziehung des Menschen zu seiner Umwelt. Ein Anker, eine feste Referenz, die unser Leben besser, schöner, einfacher, anspruchsvoller macht.

Ein Kunstwerk, ein Schlüssel, ein Zug, ein Studium, ein Hut, eine Tasse Kaffee. Das alles sind Produkte – feste Bestandteile des menschlichen Lebens, milliardenfach produziert und in Anspruch genommen, weil sie nützlich sind.

Ein gutes Produkt fügt sich ungezwungen in die Interaktion zwischen Mensch und Umwelt. Es wird nicht als Last oder Hindernis, sondern als Stärkung empfunden. Als etwas, das man gerne in die Hand nimmt, trägt, bedient, in Anspruch nimmt.

 

In der Softwareentwicklung fällt der Bau guter Produkte nicht leicht. Mit Software lässt sich sehr viel sehr schnell bauen. Diese Fülle an Möglichkeiten, die ja die Kraft von Software ausmacht, ist zugleich ihre Achillesferse. Benutzer wollen einfache, intuitiv bedienbare, gut aussehende und zugleich leistungsstarke Software. Zu oft fühlen sie sich jedoch überfordert und frustriert, haben eine vorbelastete Beziehung zu Software und würden am liebsten ohne sie auskommen, wenn sie die Wahl hätten. Da sie diese Wahl nicht haben, werden sie bisweilen stiefmütterlich behandelt. Es sollte niemanden verwundern, wenn die gleichen Benutzer bei der erstbesten Gelegenheit dem Konkurrenten in die Arme laufen und dem alten Produkt keine Träne nachweinen.

 

An welchem Produkt arbeitest du mit? Was macht es stark? Wie beeinflusst es die Interaktion zwischen Mensch und Umwelt? Wer sind diese Menschen? Die Antwort auf diese Fragen nennen wir Produktvision. Es lohnt sich, Zeit dafür zu investieren. Denn nur die Produktvision kann die Frage nach dem Wozu beantworten. Software wird nicht entwickelt, um fehlerlos zu laufen. Oder um möglichst viel Abfragen in möglichst geringer Zeit zu bearbeiten. Sie ist da, um Spuren im Alltag der Menschen zu hinterlassen. Du kannst bei dem, was du entwickelst, beim besten Willen keine Produkteigenschaften feststellen? Dann versuche es mit folgenden Fragen:

  • Wer sind deine Kunden? Was haben sie davon, dass es euch gibt?
  • Welcher Bedarf deines Kunden wird durch euer Produkt erfüllt?
  • Welche sind die vier bis fünf kritischen Funktionalitäten, die den Erfolg des Produktes ausmachen?
  • Wie wird das Unternehmen vom Produkt profitieren?

Nimm dir zum Schluss noch zehn Minuten, um deine Erkenntnisse in einen „Elevator Pitch“ zusammenzufassen – einem Statement, das so knapp und prägnant ist, dass während einer Fahrt im Aufzug die Vision kommuniziert werden kann.

 

Unsere Produktvision bei bor!sgloger lautet übrigens wie folgt: Nach ihrem Arbeitstag sollen unsere Kunden nach Hause gehen und dorthin die Energie und Zufriedenheit mitnehmen, um mit ihren Kindern zu spielen.

  • Hans-Peter Korn

    Diese Artikel spricht einen essentiellen Aspekt an:

    Tagtäglich wird in Scrum von einem „PO“ und einem „Produkt-Backlog“ geredet … und dennoch erlebe ich immer wieder ganz grosse Augen, wenn ich Teams frage: „Was ist den eigentlich euer „Produkt“? Und dann folgen Antwortversuche, die recht widersprüchlich sind … und nicht so recht zu den im Artikel genannten vier speziellen Fragen passen.

    Und bei Produkten, an deren inkrementelle Herstellung mehrere Feature- und Component-Teams parallel arbeiten, wird es vollends schwierig, wenn eines dieser Teams anhand dieser vier Fragen ihr „Produkt“ beschreiben soll. In der Regel stellt ein einzelnes Team nämlich gar nichts her, wovon ein Kunde „etwas hat“. Erst die integrierten Ergebnisse mehrerer oder gar aller an diesem Produkt arbeitenden Teams schaffen ein für den Kunden nutzbares Produkt.

    In solchen Situationen ist die Vorstellung unrealistisch, dass jedes Team eine Anwendung als Ganzes oder (im Rahmen eines umfassenden Anwendungssystems) einen aus Nutzersicht abgeschlossenen Funktionsteil („End-to-End-Functionality“) innerhalb von zwei bis vier Wochen komplett, integriert, getestet und produktionsreif realisieren kann.

    Realistischer aber ist es, in solchen Multi-Team-Situationen die Teams nach Services oder Servicedomains zu gliedern – etwa im Sinn der „Service Oriented Architecture“. Die „Kunden“ dieser Teams sind dann nicht die „Enbenutzer“ sondern die Nutzer der Services. Das können auch andere Services (= Teams) sein.

    Es gibt dann also pro Team einen „Service Owner“ und ein „Service Backlog“.

    Mit dieser Service-Optik können die zu einem umfangreichen Gesamtprodukt beitragenden und parallel arbeitenden Teams so zusammenarbeiten:

    • Teams werden in erster Linie nach Softwareservices (und insbesondere auch nicht nach Projekten) strukturiert.

    • Sie sind längerfristig (mind. 18 Monate) personell stabil und daher auch als Organisationseinheiten der Primärorganisation gestaltet.

    • Vorzuziehen ist dabei die Strukturierung nach nutzerorientierten Services („Feature Teams“).

    • Je größer das für ein spezielles IT-System benötigte Expertenwissen und die Integritätsanforderung an dieses System ist und je häufiger es von verschiedenen nutzerorientierten Funktionen (d. h. von diversen Service-Teams) benötigt wird, umso eher sollte dieses IT-System als „System-Service“ von einem spezifischen „Component Team“ bearbeitet werden.

    • Jedes Team verfügt über permanente, stets voll ausgelastete und daher „ungeteilte“ Mitglieder/Spezialisten, die insgesamt zum Definieren/Realisieren/Testen der Softwareservices des Teams nötig sind.

    • Jedes Team kann pro Release (nicht unbedingt pro kurzen Sprint) und allein (d. h. ohne umfassende Zulieferungen anderer Teams oder von Spezialisten außerhalb des Teams und nur gelegentlich unterstützt von temporär zum Team gehörenden „Shared Resources“) ein technisch und funktional getestetes Serviceinkrement als in sich geschlossenen TEIL einer teamübergreifenden End-to-End-Funktionalität herstellen.

    • Das Serviceinkrement eines Teams ist abgegrenzt durch möglichst wenige und gut definierbare Schnittstellen zu den SServiceinkrementen der anderen Teams

    • Das Inkrement jedes Teams ist zu Beginn der Releasebearbeitung so weit definiert, dass die Schnittstellen als „Stubs“ realisiert werden können

    • Jedes Team realisiert innerhalb der Releaseabarbeitung sein Inkrement entweder kontinuierlich (Kanban-basiert) oder timeboxed (in Sprints) schrittweise, sodass innerhalb dieser Stubs Zwischenresultate möglichst früh technisch integriert und funktional getestet werden können, um den teamübergreifenden Integrations- und Testaufwand am Ende der Releaseentwicklung zu minimieren