If you're not having fun...

Warum sollten wir etwas tun, woran wir keinen Spaß haben. Irgendetwas machen wir doch da falsch, oder? Genauso verhält es sich mit Dingen, von denen wir keinen Nutzen haben. Aber was machen wir dann?

 

"If you're not having fun, you're doing it wrong", sagte mein damaliger Scrum-Trainer Joseph Pelrine. Er meinte, dass wir ja typischerweise nicht in die Softwareentwicklung gegangen seien, um die Schmerzen zu verspüren, die heutzutage einfach häufig sind. Und ich kann das unterschreiben: Wenn wir nicht das bekommen, was wir uns erhoffen, machen wir vielleicht etwas falsch.

 

 

 

 

Bild: https://www.flickr.com/photos/x1brett/5779739601  

Wenn dein Kanban-Board nicht nützlich ist, ...

Kanban-Boards sind eine tolle Sache, auch wenn ich sie nicht unbedingt als zentralsten Aspekt werten würde. Sie helfen uns aber, den Fluss der Arbeit zu überwachen, Risiken und Probleme zu erkennen. Dann können wir aktiv eingreifen und wiederum beobachten, ob sich die Lage verbessert. Das Kanban-Board ist die Repräsentation unseres Arbeitssystems, mit der wir den Stand der Dinge beobachten können. Wenn das bei dir vielleicht nicht der Fall ist und du dich fragst, warum Ihr eigentlich diese blöden Zettel herumschieben sollt, dann macht Ihr vielleicht etwas falsch! Etwas, das uns Informationen liefern soll und nützlich sein soll und das aber nicht tut, ist unnütz. Dann sollten wir entweder damit aufhören oder es anders, besser, richtig machen!

Das klingt jetzt übermäßig hart, insbesondere, weil die Kanban-Community nicht dafür bekannt ist, Verhalten zu verurteilen. Das hat uns die Agile-Community voraus. Nichtsdestotrotz sollten wir keine Dinge tun, die einfach unnütz sind! Sie kosten Zeit, Energie und Geld und wenn wir die Ergebnisse nicht nutzen können, ist das Verschwendung.

Stell dir und deinen Kollegen also die Frage: Was wollen wir mit diesem Werkzeug erreichen? Und da gibt es eine ganze Menge, was man damit erreichen kann! Wenn einer oder mehrere der folgenden Punkte zutreffen, solltest du nochmal überlegen, wie ihr die Systemrepräsentation umbauen müsst, um das möglich zu machen:

• Fluss der Arbeit von Auftragsannahme bis -erbringung beobachten
• Probleme wie Blockaden, Abhängigkeiten sichtbar und greifbar machen
• Staus vor einzelnen Arbeitsschritten oder technischen Ressourcen identifizieren
• Belastung von Mitarbeitenden sehen

Meetings? Same same, but different!

Auch bei Meetings gilt Josephs Satz, gerne auch in der abgewandelten Form:

Wenn deine Meetings keinen Wert bringen, machst du etwas falsch.

Was du falsch machst, könnte durchaus auch sein, dass du ein Meeting stattfinden lässt, wo eine E-Mail ausgereicht hätte!

 

Meetings sind dazu da, um zu kooperieren. Wir wollen verschiedene Informationen zusammentragen, gemeinsam analysieren, Sinn herausarbeiten und möglichst auch noch Entscheidungen treffen, die gemeinsam getragen werden.

Stattdessen fühlen sich viele Meetings an, als würde man nur freundlich zusammen Kaffee trinken, weil irgendjemand gesagt hat, dass wir das tun müssten. Yes, I'm looking at you, Scrum Review!

Also müssen wir uns auch hier Gedanken darüber machen: 

• Welchen Wert wollen wir mit diesen Meetings schaffen?
• Tun wir das?
• Wie müsste es sein, damit dieser Wert erbracht wird?
• Was können wir möglichst schnell ändern, um diesem Wert zumindest näher zu kommen?

Auch hier gilt, dass wir auch über eine Abschaffung nachdenken sollten. Am besten koppeln wir das mit der Fragen:

• Was erreichen wir denn?
• Wie können wir das einfacher erreichen?

Ein Beispiel aus der häufig erlebten Praxis, mit dem eben erwähnten Scrum-Review. In meinen Agile-Trouble-Shooter-Lagebestimmungen treffe ich immer wieder Scrum-Reviews, in denen das Team versammelt zusammensitzt, meistens noch durch den Product Owner ergänzt. Hin und wieder taucht ein interessierter Manager auf. Während dieses "Reviews" geht jemand durch das geplante Sprint Backlog und es wird gezeigt, dass das nun funktioniert. Alle lächeln, wenn es klappt, aber die Anspannung vorher ist schon zu spüren. Nachdem alle Dinge angeguckt wurden, wird ggf. noch einmal überprüft, wie die Entwicklungsgeschwindigkeit war, und ob noch Fragen bestehen. Dann ist das Meeting vorbei. Wertbeitrag? Naja, eine E-Mail hätte es auch getan!

 

Was sollten wir eigentlich tun?

Das Ziel des Reviews ist eigentlich, den aktuellen Stand des Produkts zu inspizieren und dann gemeinsam (Stakeholder, Sc rum-Team, etc.) zu entscheiden, welche Richtung zukünftig Sinn ergibt. Oder vielleicht, wenn man von der Theorie abweichen will, Nutzerfeedback einzusammeln – was aber selten genug passiert.

Wir könnten also entweder den Termin fallenlassen und stattdessen den aktuellen Stand per E-Mail versenden oder wir besprechen tatsächlich mal, was sich verändert. Für den zweiten Punkt allerdings müssten wir von unserem ursprünglichen Plan abweichen – das wäre zwar ein Ausdruck von Agilität, aber ist auch selten genug ein für das Unternehmen erstrebter Zustand.

 

Fazit

If you're not achieving your results, you're doing it wrong. In vielen Fällen ist es wirklich einfach, von den erwünschten Ergebnissen das richtige Vorgehen abzuleiten. Dafür braucht es etwas Wissen über die angewendeten Frameworks, Methoden und Techniken und vor allem ein Pausieren zur Reflexion. Falls Dir das Wissen vielleicht fehlt oder du eine Moderation der Verbesserung benötigst, schreib mich gerne an.