Donnerstag, 14. Dezember 2017

Stillarbeit

FS
Bild: Freegreatpictures / Max Pixel - CC0 1.0
Ein Fall aus der Praxis: im Team eines von mir gecoachten Scrum Masters war eine spürbar steigende Unzufriedenheit mit den Retrospektiven spürbar. Der Grund lag in den unterschiedlichen Charakteren der Teammitglieder - während die einen eher extrovertiert und impulsiv waren handelte es sich bei den anderen eher um stille Menschen. Infolgedessen verteilten sich die Redeanteile sehr ungleich, die Introvertierten hatten das Gefühl nicht zu Wort zu kommen, die Extrovertierten fühlten sich als wären sie die einzigen die Dinge ansprechen. Schwierig.

Auch die Moderationsversuche des Scrum Masters hatten nicht das gewünschte Ergebnis sondern führten dazu, dass das Team jetzt auch mit ihm unzufrieden war. Die Extrovertierten nahmen es so wahr als würde er ihnen ständig ins Wort fallen, die Introvertierten fühlten sich auf unangenehme Weise bedrängt und ins Scheinwerferlicht gestellt. Moderation war also auch nicht die Lösung, zumindest nicht mit einem darin noch relativ unerfahrenen Moderator.

Der Ansatz der die Situation spürbar verbessern konnte war die so genannte Stillarbeit. Jeder Teilnehmer der nächsten Retrospektive wurde gebeten zunächst in Ruhe seine Themen auf Post Its zu schreiben. Danach wurden sie der Reihe nach vorgestellt (Diskussionen wurden an der Stelle noch wegmoderiert), gemeinsam priorisiert und erst danach der Reihe nach diskutiert. Bei der kurzen "Retro der Retro" am Ende gab es für diese Art der Durchführung durchweg positives Feedback.

Die Diskussion hatte zwar immer noch ein gewisses Ungleichgewicht, allerdings hatte jeder Teilnehmer seine Themen in Ruhe vorstellen können, so dass die Introvertierten sich weniger übergangen fühlten und die Extrovertierten nicht mehr das Gefühl hatten alleine Input liefern zu müssen. Für den Scrum Master wurde ausserdem die Moderation einfacher, da er die bereits vorgestellten Themen als Ausgangspunkt für weiterführende Fragen nutzen konnte und nicht mehr ständig darum bitten musste, dass überhaupt Beiträge geliefert wurden.

Natürlich ist diese Art der Themensammlung nicht immer die passende, in diesem und in anderen Fällen hat sie von mir gecoachten Teams aber sehr geholfen und ist später auch in andere Meetings übernommen worden.

Montag, 11. Dezember 2017

Kick the ball out of the tent

FS
Ein Parforce-Ritt durch eine ganze Reihe von Aspekten: Wasserfall, Komplexität, Lean, Agile, Flow, Prinzipien, Prognosen und vieles mehr. Erkennbar für ein Publikum ohne vertiefte Vorkenntnisse gedacht und gerade deshalb geeinet für jeden der Inspirationen für seine eigenen Einführungsworkshops braucht.



Ähnlich wie ich experimentiert Kniberg anscheinend mit seinen Vorträgen und verändert sie immer wieder, im wesentlichen sind die Folien aber mit diesen hier identisch.

Donnerstag, 7. Dezember 2017

User Stories

FS
Bild: Pxhere - CC0 1.0
Wenn immer es möglich ist sollten Scrum Teams versuchen ihre Anforderungen in Form von User Stories zu verfassen. Das ist zwar nicht im Scrum Guide vorgeschrieben und es muss auch nicht immer in der klassischen Form Als [Benutzer mit Rolle ...] möchte ich [Aktion ... durchführen können] um [Mehrwert ... zu haben] sein (es gibt auch andere), es empfiehlt sich aber trotzdem so vorzugehen. Die Vorteile sind unverkennbar.

Um im Sinn des agilen Prinzips Maximizing the amount of work not done vozugehen lohnt es sich darüber nachzudenken wie man die Menge neu implementierten Codes so gering wie möglich halten kann. Ein weithin beliebter Ansatz ist dabei die Fokussierung auf den (End)Anwender. Nur was der tatsächlich benutzen kann ist von Wert, alles andere kann im Zweifel weggelassen werden. Folgerichtig sollten Anforderungen idealerweise auf Use Cases (Anwendungsfällen) beruhen.

User Stories greifen diese Idee auf und reichern sie um weitere Elemente an: in verständlicher Sprache erklären sie wer der Anwender ist, welche neue Funktion er braucht/bekommt und welcher Mehrwert damit verbunden ist. Neben dem oben genannten häufigsten Muster gibt es auch andere Variationen, etwa Um [Ziel ... zu erreichen] ermöglichen wir [Benutzer mit Rolle ...] die Aktion [...] durchzuführen oder ganz schlicht Nutzer: [...], Aktion: [...], Mehrwert: [...].

Natürlich werden trotzdem immer wieder Anforderungen auftauchen die nicht in dieses Muster passen: Arbeit an technischen Komponenten, Anpassungen an Architekturvorgaben, Bugfixes, Absicherung durch Tests, Code Cleaning, Abbau technischer Schulden, etc. Da viele von ihnen ein Zeichen von fehlender Anwender-Zentrierung oder (Spät)Folgen nachlässiger Arbeit sind kann es hilfreich sein das Verhältnis zu tracken: wieviel Prozent der umgesetzten Anforderungen sind User Stories und wie viele nicht? Bei einem zu niedrigem User Story-Anteil kann sich ggf. eine Retrospektive lohnen.


PS: es gibt leider auch Teams in denen der Begriff User Story ein generisches Synonym für Anforderungen aller Art ist. Mitglieder dieser Teams mögen sich bitte zur Behandlung in der nächsten Coach-Klinik melden.

Montag, 4. Dezember 2017

Scaled Agile: Chief Product Owner

FS
Bild: Flickr / Rod Waddington - CC BY-SA
Wenn Teams nach Scrum arbeiten gilt in Bezug auf die Rolle des Product Owners das Highlander-Prinzip: Es kann nur einen geben. Der Scrum Guide formuliert das an gleich zwei Stellen sehr eindeutig: "The Product Owner is the sole person responsible for managing the Product Backlog." und "The Product Owner is one person, not a committee." Für ein einzelnes Team ist das auch nachvollziehbar, aber was passiert wenn mehrere Teams an einem gemeinsamen Produkt arbeiten?

Passend zum teamübergreifenden Konstrukt des Tribes findet man in vielen Organisationen die Rolle des Chief Product Owners oder CPO (auch Head PO, Lead PO, o.ä.) der die übergreifende Produktvision verantworten soll. Er gibt damit das Fernziel vor, das erreicht werden soll und aus der die Product Owner nach dem Pull-Prinzip die Arbeit der Teams ableiten können. Diese Konstellation ist im Rahmen des Frameworks zulässig, da die Vision zwar erwähnt wird, aber nicht festgelegt ist, wer ihr Owner ist. Es kann also auch jemand anderes als der PO sein. Wie aus ihr allerdings konkrete Arbeit (an einem Increment) abgeleitet wird liegt sehr wohl bei ihm.

Was explizit nicht zum Aufgabenbereich des CPO gehören kann ist die Arbeit an den Backlogs, er soll also weder Arbeitsaufträge an die Teams vergeben noch deren Reihenfolge oder Priorität festlegen. Das bleibt dem PO vorbehalten, der dafür auch Teil mehrerer Scrumteams sein kann. Dass lässt sich indirekt aus dem Scrum Guide ableiten, der zum einen festlegt, dass nur der PO das Backlog verantwortet, zum anderen aber auch, dass mehrere Teams aus einem Backlog arbeiten können.

Diese Aufteilung in CPO (Produktvision) und PO (Product Backlog) kann in der Anwendung schnell künstlich wirken und im schlimmsten Fall zu Konflikten führen, durch die Ressourcen gebunden und die Organisation gelähmt werden. Im Rahmen des Scrum-Frameworks ist es aber die einzige mögliche Aufteilung. Das heisst zwar nicht, dass man nicht alles anders organisieren könnte - aber dann ist es kein Scrum mehr.
Powered by Blogger.