Werden wir mit Scrum effektiver?

Submitted by Angelika Drach on

Effizient (richtig machen) sind wir, wenn wir das was wir tun richtig machen, effektiv (das richtige machen) sind wir, wenn unser Output einen hohen Wirkungsgrad hat.

Ein Maß für Effektivität ist der Kundennutzen im Verhältnis zu Aufwand/Kosten. Agile Methoden wie Scrum oder Kanban bieten einen einfachen Mechanismus, um die Effektivität eines Prozesses zu steigern: In jeder Iteration werden die Produkt-Features mit dem höchsten Wertschöpfungspotenzial identifiziert und priorisiert umgesetzt. So einfach ist es in der Theorie.

Die Praxis sieht häufig so aus:

  • Fehlende Entscheidungsfreiräume des agilen Entwicklungsteam
    Der Product Owner ist nur für einen Ausschnitt des Produktes verantwortlich und muss nach Plan arbeiten. Die übergeordnete Planungsebene denkt aber nicht agil und priorisiert nicht nach der optimalen Wertschöpfung.
  • Kundennutzen ist nicht transparent
    Wie erkennt man das Feature mit der höchsten Wertschöpfung? Das ist nicht einfach. Viele Product Owner haben keine Ahnung welches Feature den höchsten Kundennutzen bietet. Oft haben sie keinen direkten Kontakt zum Kunden oder nur zu einem Vertreter, dem nicht klar ist, wie wichtig Priorisierung für die Effektivität ist. Wie soll man das Richtige entwickeln, wenn alles gleich wichtig ist?
  • Fehlendes Kunden-Feedback
    In vielen Organisationen wird Scrum praktiziert, ohne den Feedback-Prozess für die Produktgestaltung zu nutzen. Review und Grooming Meetings wären eine gute Gelegenheit, um mit den Kunden/Stakeholdern über Kosten-Nutzen und Prioritäten von Features zu verhandeln. Oft nehme ich aber wahr, dass die falschen Leute Entscheidungen unter falschen Annahmen treffen und diese nie überprüft werden.

Es scheint so, dass viele Organisationen den Wert von effektiven Prozessen noch gar nicht erkannt haben und daher Ihre Produktentwicklung nicht wirklich agil umsetzen. Ich verspreche mir viel von der aktuellen Diskussion über „Design Thinking“ und „Lean Startup“, die am Kern dieser Problematik ansetzen und hoffe dass sich agile Denkweisen bald auch weiter vorne in der Prozesskette durchsetzen.

 

4 Comments

Meine Ergänzung

Submitted by Michel Löhr on

Hallo Angelika,

du hast hier eine schöne Liste angelegt die ich gern um zwei Punkte erweitern möchte:

* Fehlendes oder mangelhafte Produktvision

Eine wichtige Tool für Product Owner ist die Produktvision (so wohl im Consumer als Business Bereich). Da fühlen viele Product Owner sich überfordert sich eine packende Vision aus zu denken für die (nahe) Zukunft. Es muss nicht detailliert sein aber Zielführend für das Team und Stakeholder.

Biespiel Apple iPod: "<>. The last part is important, since before the iPod, most MP3 players were clunky and awkward to use. Part of Apple's vision was to build a product that would generate passion and loyalty, and they succeeded."
Quelle: http://productmanagementjournal.blogspot.de/2009/09/vision-thing.html

* Fehlende Ausnutzung der User Experience

Initiative wie "Design Thinking" (wie du erwähnst), und auch "Lean Ux" sollten uns helfen bessere Software zu liefern die auch tatsächlich den Nutzer unterstutzen in ihr Ziele/Aktivitäten:

„User experience can never be designed because it is an experience and experience cannot be designed, it can be created“

Das fordert nicht nur der Product Owner aber das Team, und da fehlt meistens dieses Wissen und Erfahrung.

VG, Michel

Erkennen vs. umsetzen

Submitted by Rolf on

"Es scheint so, dass viele Organisationen den Wert von effektiven Prozessen noch gar nicht erkannt haben und daher Ihre Produktentwicklung nicht wirklich agil umsetzen."

Das könnte so sein. Man könnte aber auch fragen, ob sie das vielleicht ahnen oder durchaus erkannt haben, aber keinen Handlungsbedarf sehen, weil ihnen subjektiv der bisher erreichte Grad an Effektivität als das optimal Machbare erscheint. Und sich alle Beteiligten ohnehin daran gewöhnt haben, nur partiell brauchbare Ergebnisse zu bekommen bzw. zu erzielen.

Expeditionen statt Projekte!

Submitted by H.-P. Korn on

Diese Beschreibung der "real existierenden" Praxis deckt sich mit meinen Erfahrungen - und ich könnte noch einige andere Punkte hinzufügen. Dass „Design Thinking“ und „Lean Startup“ hier etwas verändern kann ich jedoch nicht nachvollziehen. Für mich sind das bloss neue "label" für bereits lang bekannte Einsichten.
Ich sehe die Schwierigkeit vielmehr darin, dass nach wie vor Produktentwicklungen als klassische Projekte betrachtet werden:
Ausgangspunkt ist ein bereits zu Projektbeginn möglichst klares Ziel (= das, was zu erarbeiten ist) und daraus abgeleitet Termine und Kosten. Ziel (= Ergebnis), Termine und Kosten werden dann fixiert. Allenfalls wird das Projekt in Etappen mit (ev. nutzbaren) Zwischenergebnissen unterteilt.
Wehe aber, wenn sich dann im Projektverlauf herausstellt, dass die Dinge anders als gedacht laufen: Das wird dann als "Fehler" und zu korrigierende "Planabweichung" mit einem ausgeklügelten "Change Request Management" als "Störungsbegrenzung" und nicht als Regelfall und nützliche Erkenntnis gesehen.

Wir müssen uns also von der Illusion der mittel- und langfristigen Vorausplanbarkeit verabschieden. Das aber ist schwer: Es bedeutet nämlich, mit Unsicherheiten in Bezug auf das effektive Ergebnis zu leben. So etwa hat bereits PRINCE2 im Jahr 1989 ein derartiges inkrementell-ADAPTIVES Vorgehen auf Basis konkreter PRODUKT-Inkrememente formuliert, bei dem nach jedem Inkrement der "Business Case" zu überprüfen ist und nur das jeweils nächste Inkrement ("Phase" genannt) im Detail konzipiert wird. Die gelebte Realität sieht aber vielfach immer noch anders aus...

Vielleicht sollten wir aufhören von "EntwicklungsPROJEKTEN" zu reden und statt dessen "EntwicklungsEXPEDITIONEN" betreiben. Expeditionen mit einer groben Vision, aber mit einem offenen Ergebnis, das sich erst im Lauf der Zeit konkretisiert.

Wo aber sind die Kunden, die sich auf so etwas einlassen??

Denkfehler und typische Konstruktionsfehler mit SCRUM

Submitted by Martin Eberl on

Liebe Frau Drach,

etwas Richtig zu tun bedeutet Effektivität, dass ein wünschenswertes Ergebnis für Nutznieser schafft. Machen wir das Richtige auch noch gut, kommen wir auf dem kürzesten Weg an - Effizienz.

Wenn wir in SCRUM von Selbst-Organisation und funktionsübergreifenden (Feature) Teams sprechen, kann sich der Prozess effizienter darstellen. Das ist aber nicht das primäre Ziel von SCRUM. Die von Ihnen genannten Mängel, entstehen aus meiner Sicht ganz eindeutig durch Konstruktionsfehler. Wenn die Management-Architektur bzw. Organisation nicht sauber definiert und eingehalten wird, scheitert ein SCRUM Projekt mit großer Wahrscheinlichkeit. SCRUM lebt von kurzen Feedback-Schleifen und der zeitnahen Integration des Kunden. Proxy-Product Owner erfüllen in den seltensten Fällen die Funktion. Zeitliche Verzögerungen in der Kommunikation mit Kunden, schwächen die Dynamik der Teams im hohen Maße. Ein bloses Lippenbekenntnis, der Einsatz von Tools und die Verwendung von Wortbildern aus SCRUM, bleibt wirkungslos bzw. unbrauchbar.

Es ist wichtig SCRUM richtig einzuführen und sich über den Aufbau einer Funktions-Heterarchie in der Organisation im Klaren zu sein. Wenn der primären Organisation die Vorfahrt überlassen wird, entstehen erhöhte Koordinationsaufwände und Konflikte. Dadurch kann dem Team sehr schnell der Sinn von SCRUM verloren gehen, weil es ja eh immer anders kommt als man denkt. Wenn dann noch am Ende der Glaube verloren geht, scheiter die SCRUM Umsetzung.

SCRUM ist eben mehr als nur Tools, Wortbilder und Prozesse. Es ist Autonomität, Funktions-Heterarchie, Disziplin, Kundenorientierung, Systemik und Kybernetik. Es ist die Gestaltung, Lenkung und Entwicklung von Entwicklungsräumen.

Viele Grüße aus München
Martin Eberl

Pages

Add new comment