Donnerstag, 11. April 2024

Ausbalancierte Product Ownership

Bild: Pexels / Ivan Rebic - Lizenz

Eine der vermutlich ältesten Debatten im Umfeld von Scrum und anderen agilen Ansätzen dreht sich um die Frage, wie gross der Entscheidungsspielraum eines Product Owners (oder vergleichbarer Projektmanagement-Rollen) ist. Darf er wirklich alles entscheiden, bis hin zur möglichen Einstellung seines Produkts, oder ist er lediglich dafür zuständig die Wünsche seiner Stakeholder zu sammeln und zu einem in sich stimmigen Ganzen zusammenzufügen?


Die Antwort ist natürlich auch hier "kommt darauf an", allerdings mit einer gewissen Ausdifferenzierung. Statt einem dieser beiden Extremtypen zu entsprechen, befinden sich die meisten Product Owner irgendwo auf einer dazwischenliegenden Skala, und auch das nicht stationär sondern je nach Kontext mal hier und mal dort. Das ist auch bereits mehrfach beschrieben worden, vielleicht am eingängigsten vom Produktmanagement-Experten Roman Pichler.


In seinem Text Be a Balanced Product Leader, Not a Feature Broker or Product Dictator gibt er den beiden Extremtypen Namen, nämlich genau die im Titel genannten: der Feature Broker hat kaum Gestaltungswilllen oder Gestaltungskompetenz und beschränkt sich darauf, zwischen den Stakeholdern so lange zu vermitteln, bis eine gemeinsame Priorisierung aller Anforderungen entstanden ist. Der Product Dictator hat Gestaltungswilllen und Gestaltungskompetenz und entscheidet alles komplett alleine.


Warum die Extreme schädlich sind, dürfte offensichtlich sein. Das "Produkt" eines Feature Brokers wird schnell zu einem inkonsistenten Sammelsurium von Kompromisslösungen werden, das eines Product Dictators wird zwar in sich stimmig sein, im Zweifel aber vor allem ihm selbst gefallen und nicht notwendigerweise auch den Kunden oder Anwendern. Der "Ausbalancierte Product Owner" befindet sich in der Mittel und hat Züge von beiden, hält sie aber im vernünftigen Rahmen.


Was Pichler ergänzend anmerkt ist, dass jeder Product Owner sich des Risikos bewusst sein sollte, sich unbewusst zu sehr in eine der beiden Richtungen zu bewegen. Vor allem wenn das in kleinen, für sich genommen unscheinbaren Schritten geschieht, kann man das irrige Gefühl haben, sich nicht aus der Mitte wegbewegt zu haben, während die Umgebung einen mittlerweile als einen der beiden Extremtypen wahrnimmt (und unter den damit verbundenen Dysfunktionen leidet).


Es ist daher ratsam, von Zeit zu Zeit zu überprüfen, wo auf der Skala zwischen Feature Broker und Product Dictator man sich befindet. Ob man das durch Selbstreflektion, Überprüfung festgelegter Kriterien oder Feedback von anderen macht kann von Fall zu Fall unterschiedlich sein, wichtig ist aber, dass es überhaupt stattfindet. Nur so kann man sicherstellen, in einer ausbalancierten Rollenausprägung zu bleiben (oder in sie zurückzukehren).

Montag, 8. April 2024

Macht der Scrum Master sich selbst überflüssig?

Bild: Pexels / Zen Chung - Lizenz

Zu den Mythen, die sich mit der Zeit um das Scrum-Framework gebildet haben, gehört der, dass der Scrum Master sich mit der Zeit selber überflüssig macht und irgendwann nicht mehr benötigt wird. Auf den ersten Blick erscheint das auch wie eine naheliegende Idee, bei näherer Betrachtung hat sie aber durchaus problematische Aspekte. Es lohnt sich, näher zu betrachten wo diese Aussage herkommt, wie sie gemeint ist und was für Folgen sie haben kann.


Um mit dem Einfachsten zu beginnen: in keinem der offiziellen Scrum-Dokumente befindet sich eine auch nur entfernt ähnliche Aussage. Weder in der aktuellen Version des Scrum Guide, noch in einer der älteren Versionen, noch in einem der Konferenz-Papers mit denen Ken Schwaber und Jeff Sutherland ihren Ansatz am Anfang bekannt gemacht haben ist die Rede davon, dass der Scrum Master irgendwann nicht mehr gebraucht werden könnte (wer nachlesen will - hier sind alle dieser Dokumente verlinkt).


Der Urheber ist also irgendjemand, der nicht an der Entwicklung von Scrum beteiligt war, überspitzt könnte man sagen: ein Mensch mit einer starken Privat-Meinung. Wer genau das gewesen ist, lässt sich wahrscheinlich nicht mehr rekonstruieren, man kann aber zumindest sagen, wer diese Idee vermutlich bekannt gemacht und popularisiert hat - Geoff Watts, ein bekannter englischer Scrum Master, in seinem 2013 erschienen Buch Scrum Mastery: From Good To Great Servant-Leadership.


My second piece of advice is to go into the role of ScrumMaster with the intention of making the role of ScrumMaster for this team unnecessary. Create such a high-performing, self-organising team, with such a good relationship with the product owner, with such a keen understanding of the Scrum framework (and the principles behind the framework) that they don’t need any facilitation (of either process or people) and have no impediments left to remove. In other words, be so great that they don’t need you anymore. I’m not saying this will definitely happen, but the more you aim for it, the more quickly your team will develop and the better your team will perform.
Geoff Watts: Scrum Mastery (2.Auflage), S.27


Wie man aus diesem Abschnitt herauslesen kann, beschreibt Watts ein Idealbild, dessen Erreichung eher unwahrscheinlich ist. Das tatsächliche Ziel ist dabei weniger die Selbstabschaffung sondern die konstante Arbeit daran, das Scrum Team selbstorganisiert zu machen und ihm diese Selbstorganisation zu erhalten. Indirekt wird gleichzeitig vor dem häufigen Antipattern gewarnt, bestimmte Tätigkeiten in der Scrum Master-Rolle zu monopolisieren (was andere negative Folgen mit sich bringen würde).


Dass das Idealbild eines Scrum Teams ohne Scrum Master nur schwer zu erreichen ist, hat übrigens handfeste Gründe: Vieles von dem, was in dieser Rolle gemacht wird, erfordert ein Heraustreten aus den Alltagsabläufen und eine Konzentration auf langfristige Ziele. Da gerade in Scrum mit seinen kurzen Sprints aber ein permanenter kurzfristiger Lieferdruck herrscht, wäre eine Verdrängung der Langfrist- durch die Kurzfrist-Ziele hochwahrscheinlich, wenn sie von den selben Personen verantwortet werden (kurzfristige Verpflichtungen fühlen sich immer dringender an als langfristige).


Gleichzeitig ist es eine wichtige Eigenschaft des Scrum Masters, überparteilich zu sein, um bei Konfliken (z.B. zwischen den Entwicklern oder zwischen Product Owner und Stakeholdern) vermitteln zu können. Ohne ihn fällt diese Vermittlerrolle weg, und wird aufgrund des fehlenden Kontextwissens nur eingeschränkt durch einen externen Moderator oder Mediator ersetzt werden können. Schlimmstenfalls kommt es nur zu Schein-Konsensen, oder solchen die nicht lange halten.


Trotz dieser Faktoren wäre das Setzen des Scrum Master-Selbstabschaffungs-Ziels zunächst unproblematisch, da es aufgrund seiner Langfristigkeit kaum ins Gewicht fällt, wenn es auf absehbare Zeit nicht erreicht wird. Zu einem Problem wird es aber, wenn dieses Ziel in die Einsatz- und Budgetplanungen integriert wird. Und vor allem grosse Firmen versuchen genau das immer wieder, was verschiedene problematische Folgen mit sich bringt.


Zum einen werden in vielen Fällen keine internen Scrum Master-Positionen geschaffen, da man die ja "nur vorübergehend braucht". Das schwächt diese Rolle, es sorgt für eine hohe Fluktuation (aus Sorge vor Scheinselbstständigkeit sind externe Besetzungen meistens befristet) und macht sie zu einem primären Ziel von Sparprogrammen, da der Abbau von externem Personal einer der einfachsten und schnellsten Wege ist, um Kosten (scheinbar) zu senken.


Zum anderen führt auch bei internen Scrum Mastern die Idee, dass diese irgendwann überflüssig werden, zu "Optimierungsversuchen". Eine immer wieder anzutreffende Variante ist die Deckelung der Zeit, in der ein Team Anspruch auf diese Rolle hat (z.B. auf ein Jahr), eine andere besteht daraus, dass sie ab dem Überschreiten bestimmter Zeiträume nur noch in Teilzeit zur Verfügung steht, um in der restlichen Zeit ein weiteres Team übernehmen zu können (und irgendwann zwei weitere, und drei, etc.).


Beide Varianten führen dazu, dass sowohl die Teams als auch die Scrum Master unter einen permanenten Rechtfertigungsdruck gesetzt werden und immer wieder erklären müssen, warum sie das Selbstorganisations-Ziel noch immer nicht erreicht haben. Das zieht kontinuierlich Zeit und Energie von den wichtigen Aufgaben ab (und was passiert, wenn das Ziel, ohne Scrum Master klarzukommen, mit einem Gehaltsbestandteil verbunden wird - man kann es sich denken. Nichts Gutes jedenfalls).


Zusammengefasst: das Ziel, dass der Scrum Master sich selbst überflüssig macht, ist kein offizieller Teil von Scrum, und es ist nie ein Teil davon gewesen. Dort wo es propagiert wird, wird es als ein kaum zu erreichender Idealzustand verstanden, das eigentliche Ziel ist ein ganz anderes. Und dort wo es missverstanden wird oder den falschen Menschen in die Hände fällt, kann es Fehler im Systemdesign, Ressourcenverschwendung und ständigen Stress zur Folge haben.


Das alles ist wirklich schade, da die Grundidee eigentlich gut und erstrebenswert klingt. Aufgrund der damit verbundenen Risiken sollte man es sich allerdings mehrfach überlegen, bevor man sie in der eigenen Firma äussert. Im Zweifel startet man dadurch eine Dynamik, die sich nur schwer wieder einfangen lässt und ohne Notwendigkeit Konflikte verursacht.

Donnerstag, 4. April 2024

Sturgeon's Law

Wenn wir über Sturgeon's Law (Sturgeons Gesetz) reden, müssen wir damit beginnen, dass es häufig verwechselt wird, und zwar mit einer anderen Beobachtung, die ebenfalls auf den amerikanischen Autor Theodore Sturgeon zurückgeht - mit Sturgeon's Revelation (Sturgeons Offenbarung). Allerdings bauen die beiden aufeinander auf, um das Gesetz zu verstehen muss man also die Offenbarung kennen. Beginnen wir also mit ihr. Sie lautet in aller Schlichtheit:


Ninety percent of everything is crap (Neunzig Prozent von allem ist Mist)
Theodore Sturgeon, Sturgeon's Revelation


Dieses Statement benötigt Kontext. Sturgeon war ein früher Fantasy- und Science Fiction-Autor und lebte in einer Zeit, als diese Genres noch neu waren und von Kritikern als künstlerisch wenig anspruchsvoll betrachtet wurden. Von ihnen wurden zuerst alle Science Fiction und Fantasy als "zu Neunzig Prozent Mist" bezeichnet, was Sturgeon dazu brachte, sie mit der Qualität der restlichen Literatur zu vergleichen. Dabei entstand seine Erkenntnis, dass auch bei der maximal zehn Prozent wirklich gut waren.1


Angesichts dieser Vergleichbarkeit stellte sich für Sturgeon eine Folgefrage: warum war das Ansehen der neuen Genres so viel schlechter? Seine Antwort (und gewissermassen seine zweite Erkenntnis) war, dass sie nicht mit dem Durchschnitt der bisherigen Literatur verglichen wurden, sondern mit den Klassikern und Bestsellern. Diesen Vergleich konnten sie natürlich nur verlieren. Sturgeon's Law (von dem es verschiedene Varianten gibt) sollte derartig unfaire Vergleiche verhindern:


Nothing is always absolutely so. [...] The best science fiction is as good as the best fiction in any field (Nichts kann undifferenziert beurteilt werden [...] Betrachtet man nur die besten Science Fiction-Werke, sind sie ähnlich gut wie die besten Werken anderer Stilrichtungen)
Theodore Sturgeon, Sturgeons Law


So weit, so naheliegend, aber was haben diese eher literaturwissenschaftlichen Überlegungen mit der Welt der Prozesse und Methoden zu tun, um die es auf dieser Seite schwerpunktmässig geht? Mehr als man denkt, denn Sturgeon's Law lässt sich hierher übertragen. Auch neue Methoden werden ständig entwickelt (z.B. POPCORN oder FAST) und oft auf die erwähnte ungerechte Art mit den bereits existierenden, fertig ausentwickelten Ansätzen verglichen. Sturgeon würde auch dem widersprechen.


Ein Vergleich neuer und bestehender Methoden macht nur Sinn, wenn die Vergleichsobjekte der beiden Gruppen basierend auf ähnlichen Kriterien ausgewählt wurden
Sinngemässe Übertragung von Sturgeons Law


Dementsprechend können bewusst rudimentäre neue Ansätze, wie die gerade erwähnten, nur mit den vergleichbar minimalistischen unter den bewährten Vorgehensweisen verglichen werden, z.B. den sieben Mudas. Umgekehrt wären die passenden Vergleichswerte für die klassischen, schwergewichtigen Projektmanagement-Methodiken von PMI und Prince2 nicht einfache Frameworks wie Scrum oder Extreme Programming, sondern eher die "agilen Schwergewichte" wie SAFe oder Disciplined Agile.2


Natürlich verhindert eine derartige Zuordnung von äquivalenten Vergleichsobjekten viele der aus starken Unterschieden ableitbaren Pauschalurteile, wie z.B. "das ist doch viel zu umfangreich" oder "da wird doch ganz Vieles gar nicht bedacht". Genau das ist aber der Vorteil, den die Anwendung von Sturgeons Law bringt - man muss jetzt ähnlich grosse, ähnlich weit ausentwickelte Ansätze einander gegenüberstellen. Ihre Unterschiede (bzw. deren Fehlen) werden dadurch deutlich besser erkennbar.


PS: Unabhängig von Sturgeons Erkenntnissen und Handlungsempfehlungen kann man natürlich Vorlieben für schwer- oder leichtgewichtige Frameworks haben, das ist jedem unbenommen. Diese untereinander zu vergleichen ist aber häufig ein Vergleich von Äpfeln mit Birnen, und daher meistens nur wenig zielführend.



1Natürlich ist diese Zahl hochgradig subjektiv, aber dass ein Großteil aller erschienenen Bücher nur kleine Auflagen hat, liegt auch an der Qualität
2Und im Vergleich zwischen den agilen Frameworks müsste man z.B. FAST an dem ähnlich grossen Scrum messen, statt an dem deutlich grösseren SAFe

Montag, 1. April 2024

Kommentierte Links (CXII)

Grafik: Pixabay / Geralt - Lizenz
Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

John Cutler: How to Learn and Practice Product Management in a Feature Factory

Zu den am weitesten verbreiteten Antipattern zur agilen (oder einfach nutzerorientierten) Produktentwicklung gehören die so genannten Feature Factories, in denen eine möglichst schnelle Implementierung neuer Funktionen wichtiger ist als die Überprüfung, ob sie auch vom Markt nachgefragt werden. Wie John Cutler mit voller Berechtigung anmerkt, kann man aber selbst in einer solchen Umgebung daran arbeiten, bessere Praktiken zu entwickeln und anzuwenden (er nennt exemplarisch 10, es gibt sicher noch weitere). Bestenfalls verbessert man dadurch das Unternehmen in dem man ist, schlimmstenfalls lernt man, was man nach einem Wechsel im nächsten machen kann.

Robert Ruzitschka: “We” instead of “I” - The team as the smallest unit of delivery

Von den Antipattern zu einer good Practice: Robert Ruzitschka betont richtigerweise, dass die Wertschöpfung in der Anwendungsentwicklung vor allem auf Teamebene staatfindet, und das besonders gut in solchen, darauf verzichten, einzelnen, besonders erfahrenen Mitgliedern eine herausgehobene Rolle zuzugestehen. Nicht etwa, weil das im Einzelfall nicht zielführend wäre (im Gegenteil, wer erfahrener ist, erledigt Aufgaben oft schneller und besser), sondern wegen der Folgen für das Gesamtsystem. Selbst wenn sich es nicht wollen, werden solche "Superstar-Entwickler" zu Flaschenhälsen und Risiko-Faktoren (→ Bus-Faktor). Teams mit breiter Wissens- und Verantwortungsverteilung sind deutlich resilienter.

Dmitry Bagdasaryan: Cultural Intelligence in Hi-Tech Leadership - Navigating Global Business Dynamics

In meinem Psychologiestudium habe ich mich zwar auch mit dem Thema der Intelligenz befasst, die hier von Dmitry Bagdasaryan beschriebene Unterart der Kulturellen Intelligenz kannte ich aber noch nicht. Verkürz gesagt verbirgt sich hinter diesem Begriff die Fähigkeit eines Menschen, sich in kulturell divers aufgestellten Situationen und Umfeldern aufmerksam, verständnisvoll und anpassungsfähig zu verhalten. Vor dem Hintergrund, dass auf kulturellen Missverständnissen und Konflikten beruhende Verzögerungen und Fehlentwicklungen teuer sein können, ist das eine Eigenschaft, an der zu arbeiten sich lohnt.

Randy Silver: The Secret Weapon of Great Leaders: Effective Delegation

Vor einiger Zeit habe ich über die Autonomie-Falle geschrieben, in die jeder zu tappen droht, der Entscheidungen an Menschen delegiert, die dafür nicht vorbereitet sind. Randy Silver hat darüber nachgedacht, was das Ergebnis einer solchen Vorbereitung sein sollte, und kommt dabei auf die folgenden drei Punkte:
1. Den Menschen muss klar sein, wie Entscheidungsprozesse funktionieren
2. Den Menschen muss klar sein, woran sie richtige Entscheidungen erkennen
3. Den Menschen muss klar sein, warum sie die Richtigen sind, um diese Entscheidungen zu treffen
Klingt total selbstverständlich, ist aber leider nicht immer gegeben.

Tanner Wortham: Guessing Is Not a Viable Strategy

Da hat Tanner Wortham völlig recht, strategische Entscheidungen sollte man nicht auf Vermutungen (oder in seinen Worten auf Raten) aufbauen. In einer Umgebung, in der aufgrund ständiger Veränderungen auch Erfahrungswerte kaum möglich sind, sind auch diese keine Option - was bleibt also? Die Antwort: ein vorsichtiges aber entschlossenes Vorantasten durch kontrollierte Experimente. Woran man erkennt, dass man ein solches vor sich hat, beschreibt er anhand von sechs nützlichen Lackmustests.

Donnerstag, 28. März 2024

Entgleiste Meeting-Moderation


Das hier ist eines der Videos, bei denen der alte Spruch stimmt: das Lachen bleibt einem im Hals stecken. Entdeckt habe ich es in den Kommentaren eines Linkedin-Posts, in dem die These aufgestellt wurde, dass Retrospektiven bestenfalls sinnlose Zeitverschwendung sind und schlimmstenfalls eine an Mobbing grenzende Zwangs-Infantilisierung erwachsener Menschen. Das Bittere daran ist, dass es viele Teams gibt, in denen genau das der Fall ist. Das Video ist verstörend nah an einer häufigen Realität.


Anzutreffen sind derartige Katastrophen-Termine immer dann, wenn der Scrum Master, Agile Coach oder Design Thinking-Facilitator den anderen gegen ihren Willen "spielerische Elemente" aufzwingt, unter denen sie eher leiden als von ihnen in irgendeiner Form zu profitieren. Alleine ich habe über die Jahre eine mittlere zweistellige Anzahl derartig entgleister Meeting-Moderationen erlebt, einige davon noch verheerender als hier zu sehen (!) - und alle aus bestem Willen heraus so durchgeführt (was das Ganze um so tragischer macht).


Das soll natürlich nicht heissen, dass Ice Breaker und Gamification per se schlecht wären, viele Teams lieben sie. Genau darin steckt aber ein entscheidender Punkt: wer solche Elemente als Moderator nutzen möchte, sollte genau darauf achten, ob die Teilnehmer sie wollen oder sich davon zumindest nicht gestört fühlen - sowohl grundsätzlich als auch im jeweiligen Einzelfall. Immer dann, wenn das nicht der Fall ist, kann man nur dringend raten, damit sofort aufzuhören. Wenn nicht, wird man das Gegenteil dessen erreichen, was eigentlich beabsichtigt ist.

Dienstag, 26. März 2024

Wie und wann man in Scrum Stakeholder einbinden kann

Bild: Pexels / Theo Decker - Lizenz

Auf die Frage nach den Rollen, bzw. Verantwortlichkeiten, in Scrum werden die meisten Kenner dieses Frameworks ohne zu Zögern mit den Entwicklern, dem Product Owner und dem Scrum Master antworten. Das ist auch grundsätzlich richtig, lässt aber eine vierte aus, die im Scrum Guide (Version von 2020) immerhin dreizehn mal an verschiedenen Stellen genannt wird: die der Stakeholder, also der (team-externen) Interessenvertreter. Wie kommt es, dass diese Gruppe so häufig übergangen wird?


Eine Antwort darauf ist, dass die Stakeholdern im Scrum (scheinbar) nicht am Sprint beteiligt sind. Bei oberflächlicher Betrachtung kann es so erscheinen, als würden sie nur als "Publikum" im Sprint Review erscheinen. Bei näherer Betrachtung können sie aber durchaus stärker eingebunden werden. Zum einen aufgrund der Vorgaben des Scrum Guide selbst, zum anderen durch verschiedene Praktiken, mit denen die bewusst offen gelassenen Lücken von Scrum gefüllt werden können.


Die Stakeholder im Sprint Planning

Um mit einer kleinen Überraschung zu starten - die mögliche Mitwirkung der Stakeholder im Planning steht im Scrum Guide. The Scrum Team may also invite other people to attend Sprint Planning to provide advice. heisst es dort. Eine Möglichkeit, von der viel zu selten Gebrauch gemacht wird.


Die Stakeholder im Daily Scrum

Es ist kein offizieller Teil von Scrum, aber eine häufige Praxis: Daily Scrum Meetings finden öffentlich statt, so dass jeder, der ein Interesse hat, als Zuschauer teilnehmen kann. Häufig reicht das bereits als ein Kommunikationsinstrument aus, ggf. ergeben sich daraus auch Themen für Folgegespräche.


Die Stakeholder im Backlog Refinement

In Scrum ist das Refinement nicht notwendigerweise ein Meeting sondern eine Tätigkeit, in deren Rahmen Backlog-Einträge erstellt, präzisiert und priorisiert werden. Analog zum Sprint Planning können dabei Experten und Kundenvertreter bei Bedarf einbezogen werden.


Die Stakeholder in der Sprint Review-Vorbereitung

Nirgendwo steht, dass die Stakeholder erst im Review-Meeting die Sprint-Ergebnisse sehen dürfen. Oft gilt sogar ein je früher, desto besser, da dadurch mehr Zeit bleibt die Features auszuprobieren, Feedback vorzubereiten und, falls die Zeit das zulässt, sogar noch Änderungswünsche zu platzieren.1


Die Stakeholder im Sprint Review

Nochmal zum Scrum Guide. Ihm zufolge wird den Stakeholdern im Review nicht nur das Ergebnis gezeigt und sie geben nicht nur Feedback, sie erarbeiten darüber hinaus zusammen mit dem Scrum Team nächste Schritte und passen gemeinsam die Planung an. Es ist eine aktive, mitentscheidende Rolle.2


Die Stakeholder in der Sprint Retrospektive

Der seltenste Beteiligungsfall: Retrospektiven sind im Normalfall strikt Scrum Team-intern, um dort vertraulich und in psychologischer Sicherheit auch an schwierigen Themen arbeiten zu können. Aber wenn es dabei um die Zusammenarbeit mit Anderen geht, können die auch gezielt eingeladen werden.


Spezielle Stakeholder-Termine

Über die offiziellen Scrum-Events hinaus kann es Sinn machen, weitere Stakeholder-Termine einzurichten. Welche das sind kann je nach Bedarf unterschiedlich sein, es sollten nur nicht zu viele werden. Und übrigens: auch das Scrum of Scrums ist bei näherer Betrachtung ein Stakeholder-Meeting.


Noch einmal zusammengefasst: wer in den Stakeholdern nur das Publikum für die Sprint Reviews sieht, wird nicht das volle Potential von Scrum nutzen. Sie können (und sollen) an verschiedenen Stellen ihre Expertise einbringen und in diesem Rahmen aktiv mit den drei anderen Rollen, bzw. Verantwortlichkeiten, zusammenarbeiten. Und dort wo das noch nicht passiert sollte der Scrum Master tätig werden. Zu dessen Aufgaben gehört nämlich laut Scrum Guide removing barriers between stakeholders and Scrum Teams.



1Das geht natürlich nur, wenn nicht erst alles am letzten Tag fertig wird. Nochmal eine eigene Geschichte
2Um zu zeigen wie weit das gehen kann: vor der Verschlankung von 2020 stand im Scrum Guide sogar, dass im Review Budgets neu festgelegt werden können

Donnerstag, 21. März 2024

Vollständige Tätigkeit

Bild: Pexels / Yan Krukau - Lizenz

Ein Hoch auf die Wissenschaft! Diesesmal sind es Arbeits- und Organisationspsychologen der Universität Halle, die eine verbreitete Annahme überprüft haben, so dass man diese jetzt auf der Basis valider Empirie vertreten kann. Die Rede ist von End-to-End-Verantwortung, oder "Vollständiger Tätigkeit", wie sie hier genannt wird, und von den Auswirkungen, die diese Art von ganzheitlicher Beschäftigung mit einem Thema auf Menschen haben kann.


Das Konstrukt der „vollständigen Tätigkeit“ als Ziel guter Arbeitsgestaltung heisst der Forschungsbericht, der auf Basis von 800 Betrachtungen und Interviews entstanden ist, durchgeführt mit Menschen unterschiedlichster Berufsgruppen. In dieser Forschung wurde überprüft, welche so genannten Beanspruchungsfolgen (vereinfacht gesagt Auswirkungen auf die Psyche) unterschiedliche Ausmasse der Verantwortung über die eigene Tätigkeit haben (siehe auch hier).


Ein erstes Ergebnis ist, dass "unvollständige Tätigkeiten", die jeweils nur einen Teil einer Wertschöpfung umfassen, eher zu negativen als zu positiven Beanspruchungsfolgen führen. Da in diesem Vorgehen zahlreiche Abhängigkeiten zu anderen Gruppen bestehen, empfand die Mehrheit der untersuchten Personen ständigen Zeitdruck, der Versuch allen Abhängigkeiten gerecht zu werden führte ausserdem zu ständigen Kontextwechseln und Unterbrechungen. Insgesamt entstanden Ineffektivität und Ineffizienz.


Umgekehrt führten "vollständige Tätigkeiten", die grosse Teil der Wertschöpfung umfassen, eher zu positiven als zu negativen Beanspruchungsfolgen. Das in diesem Vorgehen mögliche eigenständige Zielsetzen, Planen und Kontrollieren führte bei der Mehrheit der untersuchten Personen zu mehr Engagement, Zufriedenheit und Commitment, was sich in Form von gesteigerter Kreativität und Effizienz auch auf die Arbeitsleistung auswirkte.


Eine wichtige Differenzierung ergab sich dabei durch das Ausmass der kognitiven Beanspruchung, die durch die jeweiligen Anforderungen des End-to-End-verantwortlichen Arbeitens entstand. Wurde dieses als zu hoch empfunden, konnte es auch bei "vollständigen Tätigkeiten" zu eher negativen als positiven Beanspruchungsfolgen kommen, da dann erneut negative Treiber wie Zeitdruck und Stress auftreten können (zwar aus anderen Gründen, aber mit den selben Folgen).


Übertragen auf die Gestaltung beruflicher Stellen bedeutet dass, dass sich diese idealerweise in der Mitte eines Spannungsfeldes zwischen möglichst umfassender Verantwortung und noch bewältigbarer kognitiver Belastung befinden sollten (wobei diese "Mitte" in den meisten Fällen eher ein beweglicher als ein fixer Punkt sein dürfte). "Agile Praktiken" wie das Pull-Prinzip, Inspect & Adapt und das Automatisieren repetitiver Tätigkeiten könnten bei dieser Gestaltung wesentliche Erfolgsfaktoren sein.

Montag, 18. März 2024

Ein Bild sagt mehr als 1000 Worte (XXXXI)

Grafik: Design Thinking! Comics

Den Vergleich von Produktentwicklungs-Vorhaben mit einer Acherbahnfaher kenne ich schon länger, aber noch nicht in dieser schönen Visualisierung.