Product Owner optimiert eure Engpässe

Das ist Teil 2 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.

flask-304943_1280Wenn wir Software entwickeln, dann erstellen wir – wenn auch virtuell – ein Produkt. Produktentwicklung respektive der dafür eingesetzte Prozess wird immer einen oder mehrere Engpässe haben. Besonders Lean Management bzw. das darauf basierende Kanban zielen auf die Optimierung solcher Durchsatzprobleme ab (vgl. Theory of Constraints).

An allen Softwareprodukten, an denen ich mitentwickelt habe, war ein Engpass im Bereich der Entwicklung. Ideen und Wünsche haben die Kunden, Projektmanager und Product Owner viele. Natürlich können sie diese schneller formulieren als die Entwickler sie implementieren können.

Deshalb ist es wichtig genau diesen Abschnitt des Entwicklungsprozesses optimal auszulasten. Alternativ könnte der Engpass durch massive Aufstockung der Mitarbeiter vollständig aufgelöst werden, aber das ist allein aus Kostengründen unrealistisch.

 

Vorbereitung ist alles

Deshalb gilt: Je besser die Vorarbeitet ist, d.h. Wunsch-Features durchdacht, formuliert und präpariert werden, desto weniger Zeit muss der Entwickler dafür aufwenden. Unternehmen sprechen typischerweise auch vom Anforderungsmanagement. In einem späteren Beitrag werde ich die Einzelschritte und die Rollen in einem Softwareentwicklungsprozess beleuchten. Es gilt das Gleiche wie beim Essen: Je besser die Nahrung im Mund vorgekaut wird, desto einfach kann der Magen sie verdauen. Das heißt nicht, dass nicht weiter der Entwickler einbezogen werden soll oder dass weniger miteinander geredet werden soll, aber meiner Erfahrung nach werden immer wieder wenig durchdachte Anwendungsszenarien den Entwicklern über den Zaun geworfen. Im Sinne von “die werden dann schon mal machen”. Wird dann seitens der Entwickler nachgefragt, wundert sich der fachliche Verantwortliche gerne mal “was denn daran nicht klar sei”. In dem Zuge sei auf die Wichtigkeit einer gemeinsamen Sprache hingewiesen. Wie gesagt ist die Kommunikation wichtig und die Fachexperten können nicht an alles denken. Manches wissen sie auch nicht. Viele Probleme können aber im Vorfeld durchaus vermieden werden. Statt nach Lösungen zu suchen, kann es oft sinnvoller sein die tatsächliche Ursache des Problems zu untersuchen. Wo genau funktioniert der Geschäftsprozess nicht?

 

Evolvierbarkeit

Darüber hinaus muss jedem Produktverantwortlichen klar sein, dass eine Änderung nachweislich teurer wird, je später selbige erfolgt. Das betrifft die sogenannte Evolvierbarkeit. Obwohl Software nicht wie ein Auto verschleißt oder für Änderungen physikalisch auseinander gebaut werden muss, kosten späte Korrekturen mehr als frühe.

 

Schnelles Feedback

Bei Scrum und Kanban macht es sich ebenfalls bemerkbar, wie schnell erledigte User Stories vom Product Owner abgenommen werden. Ich habe für die Projekte, in denen ich Scrum Master bin, mit dem PO vereinbart, dass spätestens am Vormittag des Folgetages das Feedback kommen muss, ob die User Story korrekt umgesetzt wurde. Mir ist unter anderem von Microsoft bekannt, die nach einer Einführung einer 4-Stunden-Abnahmefrist der Durchsatz der tatsächlich abgeschlossenen Aufgaben signifikant gesteigert wurde.

 

Leerlauf vermeiden

Zu guter Letzt gibt es noch den Fall, dass die Arbeit so gut läuft, dass neue Wünsche schneller umgesetzt werden können als erwartet. Dann sollten die nächsten ToDos vorbereitet sein, damit die Software Ingenieure nicht Leerlauf haben.

 

Fazit

Der Entwicklungsprozess sollte auf die Engpässe zugeschnitten sein. Häufig ist das die Entwicklung. Diesem Engpass muss sich der Rest des Prozesses unterordnen. Das Prinzip ist seit langem bekannt, wissenschaftlich belegt und kann eine erhebliche Beschleunigung der Produktentwicklung bewirken.

Mit Tag(s) versehen: , ,

8 Kommentare zu “Product Owner optimiert eure Engpässe

  1. […] Hier geht es zu Teil 2: Product Owner optimiert eure Engpässe […]

    Like

  2. Sebastian 22. April 2015 um 15:56 Reply

    In der Praxis kommt es immer auf den Einzelfall an, so zumindest meine Erfahrung. Einige Features die nachfolgen sind im Rahmen einer Erweiterung, Veränderung ohne globale Auswirkungen umsetzbar und dann gibt es Änderungen die das ganze Szenario ändern. Als unsere Firma noch kleiner war haben wir alles immer mit rein genommen, komme was da wolle. Inzwischen landen Scenario-Changer auf der To-Do Liste. (Ist an der Stelle müssig zu streiten inwiefern die Archtiektur immer auf alles vorbereitet sein muss) (Ich hab vor kurzem zum Tode eines der SAP Gründer ein Zitat gelesen das man sich nicht bei jeder Installation restslos verausgaben darf – full ack)

    Ich weiss nicht wie das bei euch läuft aber die User Story erfüllt wurde entscheidet letztlich der Kunde, selbst wenn das bedeutet das der Kunde auf einmal merkt das er das so doch nicht haben will(obwohl man ihm vorher tausend mal versucht hat zu erkären das dass Vorgehen wenig optimal ist)

    Jedenfalls lässt sich der Kunde nur selten drängeln. 4 Stunden sind da völlig unrealistisch. Ich arbeite allerdings in 90% in der Auftragsentwicklung in einem Preissegment das erweiterte Quality-Prozesse kaum zulässt. Du bist da scheinbar mehr in der Produktentwicklung. (Bei meiner letzten Produktentwicklung nach Scrum kam der Product Owner aus dem oberen Management und den haben wir vielleicht 1x im Monat gesehen – dann aber gleich mit extra Catering. Die Firma hatte sogar extra Berater eingestellt weil Scrum irgendwie nicht so recht funktonieren wollte….Mir wir durch deinen Blog Post gerade etwas mehr klar wieso ;) )

    Like

    • Uli Armbruster 23. April 2015 um 1:06 Reply

      Hi Sebastian, danke für deinen Input. Ganz klar, es kommt auf den Einzelfall an, aber nur bei sagen wir mal kosmetischen Änderungen im Sinne von UI und von Geschäftsprozessen. Alle anderen Änderungen, in aller erster Linie die an der Infrastruktur, aber in jedem Fall auch bei nicht mehr trivialen Geschäftsprozessen, die sich nicht in – sagen wir einfach mal – drei bis vier Sätze erläutern lassen, sind imho spätere Änderungen immer teurere Änderungen. Und zwar je schlechter der Code, desto teurer. Im Rahmen der ERP Entwicklung musste ich feststellen, dass es so was wie einfache Geschäftsprozesse selten bis gar nicht gibt. Natürlich reden wir teilweise nur von ein paar Stunden mehr Aufwand, aber das kann auch ganz schnell teurer werden.

      Da wir unser eigenes ERP entwickeln, haben wir genau diese Problematik nicht. In dem Szenario von Microsoft waren die Abnehmer ebenfalls Interne. Das ist definitiv der Idealzustand, gar keine Frage. Bei uns ist es sogar so, dass wir niemanden aus einer Führungsposition zum PO gemacht. Das war Absicht. Im gleichen Zug wurde mit dem Management geklärt, dass klar sein muss, dass der PO der Produktveranwortliche ist. Und damit fahren wir echt weltklasse.
      Wenn ich als externer Scrum Berater aber zu dem von dir geschilderten Projekt gerufen werden würde, dann müsste ich klar sagen: Sorry Leute, Scrum ist hier nicht das passende Werkzeug. Vermutlich habt ihr dadurch mehr Probleme als Nutzen. Deswegen kann ich deine Aussage völlig nachvollziehen!

      Like

  3. Alexander Zeitler 22. April 2015 um 17:13 Reply

    Schnelles Feedback ist für mich eigentlich der wichtigeste Punkt, gefolgt von Vorbereitung.
    Beides unbequem / unbeliebt, da entweder kurzfristig (Feedback) oder mittelfristig (Vorbereitung) intensive Arbeit ansteht.

    Ich frage mich auch, ob es immer Scrum sein muss. Man sollte die Prinzipien dahinter verstehen und umsetzen, dann ist der Name des Prozesses egal und man hat einen anpassbaren Practice-Baukasten für das jeweilige Projekt.

    Bei Themen wie Continuous Delivery oder Lean Startup kann Dir Scrum nach Lehrbuch durchaus im Weg stehen.

    Like

    • Uli Armbruster 23. April 2015 um 1:14 Reply

      Hey Alex,
      zunächst einmal: Schaltet doch die Open Space Anmeldung langsam frei :)
      Das habe ich wohl nicht ganz optimal rüber gebracht, aber genauso ist es gemeint. Ich nenne nur Kanban und Scrum gerne als Beispiele, weil diese Artikel auch für Nicht-IT-ler sind und das dann doch geläufiger ist. Und durch die Buzz-Words wird natürlich auch ein größerer Nutzerkreis angesprochen. Für mich gilt: Schlanke Prozesse sind gute Prozesse. Die elementaren Prinzipien dazu sind schon lange bekannt und stammen aus ganz anderen Bereichen als der Softwareentwicklung. Scrum, aber vor allem Kanban schaffen es imho besonders gut diese auf den Punkt zu bringen und in einem überschaubaren Framework zu orchestrieren. Bei allen Freiheiten finde ich es deshalb umso wichtiger, dass klar definiert ist, wo die Freiheit aufhört und „prozessschädigende Veränderungen“ anfangen.

      Like

      • Alexander Zeitler 23. April 2015 um 10:53 Reply

        Soweit ich weiß, wird die Open Space Anmeldung am 8.5. (dotnet cologne) freigeschaltet. Aber ich habe mich aus der Orga zurückgezogen, von daher bei Fragen bitte die anderen üblichen Verdächtigen kontaktieren ;-)

        Like

  4. Carsten 24. April 2015 um 12:00 Reply

    Gute Vorbereitung und schnelles Feedback scheinen mir widerstrebende Aktivitäten zu sein. Besser scheint mir auf die Vorbereitung zugunsten des schnellen Feedbacks im Zweifelsfall zu verzichten.

    Like

    • Uli Armbruster 25. April 2015 um 18:01 Reply

      Ich bin nicht sicher, ob ich dich richtig verstehe. Gute Vorbereitung bevor Wünsche bei den Entwicklern aufschlagen und schnelles Feedback – entweder in Form einer fachlichen Antwort bei einer Rückfrage oder aber bei der zeitnahen Abnahme einer User Story – sehe ich nicht als disjunkt. Oder meinst du, dass eventuell keine durchdachte Antwort gegeben werden kann, weil es schnell sein soll? Wenn ja, dann sollte ich es tatsächlich konkretisieren:
      Zum einen sind Rückfragen häufig einfache Fragen in der Form ‚Kommt es vor, dass ein Anwender sowohl x als auch y tut?“ oder „Ich bräuchte mal einen Auftrag, bei dem das so und so ist“. Da muss mir ein Fachexperte nur von der gängigen Praxis erzählen. Zumindest ist das bei mir so.
      Zum anderen bedeutet es für mich, dass sich der PO auch zeitnah und schnell um offene Punkte im Rahmen des Projekt kümmert. Vor allem, wenn das Projekt sehr hoch priorisiert ist. Ich meine jedoch häufig Probleme darin zu sehen, dass weniger priorisierte Dinge durch die starke Parallelisierung von Projekten begünstigt werden. Deshalb kann eine Vereinbarung wie dass User Stories innerhalb eines Tages abgenommen werden, durchaus sinnvoll sein.

      Like

Hinterlasse einen Kommentar