NBA41: Die Devs bitte nicht ansprechen
Shownotes
Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile oder ihr hinterlasst mir eine Sprachnachricht: +4950329677123
Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/60-nba41-die-devs-bitte-nicht-ansprechen
—
NBA40: Die menschliche Seite des Task Splittings
Agile Usergroup
- Webseite mit Infos: https://no-bullshit-agile.de/agile-usergroup.html
- Forum zum Austausch: https://forum.no-bullshit-agile.de/d/54-agile-virtuelle-usergroup
LinkedIn Post
Allen Holub Heuristics
Zusammenfassung
In einem LinkedIn-Post von Stefan Roock wurde ein Zitat thematisiert, das den Product Owner auffordert, während des Sprints nicht mit den Entwicklern zu sprechen. Dies stieß auf Kritik, da es eine sehr einseitige Sicht auf die Arbeit von Entwickler*innen widerspiegelt. Entwickeln bedeutet nicht nur reines Coden, sondern vor allem auch Austausch und gemeinsames Finden der besten Lösungen – ein zentraler Bestandteil agiler Arbeitsweisen. Während Ruhephasen wichtig sind, führt ein striktes Kommunikationsverbot zu Problemen, da während der Entwicklung oft neue Fragen oder Erkenntnisse auftreten. Agile Prinzipien, insbesondere der Fokus auf Interaktion über Prozesse, sprechen für flexiblen Austausch und das Einbeziehen aller Beteiligten zur richtigen Zeit. Das starre Trennen von Rollen wie Entwicklern und Product Ownern könnte zu einem "Stille-Post"-Effekt führen, der die Zusammenarbeit erschwert. Stattdessen sollte offen über Ängste oder Befürchtungen gesprochen und Lösungen gefunden werden, die sowohl die Konzentration schützen als auch Kommunikation ermöglichen. Der Post regt dazu an, über diese Dynamik nachzudenken und praktische Wege zu finden, die Balance zwischen Ruhe und Austausch zu halten.
Transkript
Ich habe auf LinkedIn, wie schon gesagt, von Stefan Roock einen Post gesehen. Der ist tatsächlich schon ein bisschen älter. Ich weiß nicht genau, wie der LinkedIn-Algorithmus funktioniert und warum ich den jetzt erst gesehen habe, aber da der so ein Originalzitat hatte, hat er dazu ein paar Anmerkungen gemacht. Und das Zitat, muss ich sagen, hat so lange in mir resoniert, und ich habe da immer wieder drüber nachgedacht und gedacht, ja, ich erzähle mal in einer Folge so ein bisschen meine Erfahrung, meine Einschätzung, meine Meinung dazu.
Das Zitat war wie folgt:
Mein Chef hat mir als Product Owner gesagt, dass ich mit den Entwicklern während des Sprints nicht sprechen soll.
Uff, das war so meine allererste Reaktion. Ja, Stefan schrieb das auch in seinem Post, und ich teile das. Wahrscheinlich ist die Idee gar nicht falsch, das ist wahrscheinlich gar nicht aus Bosheit so vom Chef gesagt worden. Ich vermute, dahinter steht so ein bisschen der Gedanke, dass die Devs mal in Ruhe entwickeln sollen in ihrem Sprint. Ich glaube, es ging um Scrum. Aber das, was ich jetzt erzähle, gilt ja nicht nur für Scrum.
Mein erster Punkt oder Gedanke war dazu: Ja, aber was ist denn das für eine Einschätzung, was Entwicklerinnen wohl tun? Man könnte da reininterpretieren: Entwicklerinnen coden nur und sollen bitte nicht sprechen. Meiner Erfahrung nach – und das ist auch meine ganz feste Überzeugung – ist das reine Coden nur ein ganz kleiner Teil der Aufgabe von Devs. Der viel größere Teil ist ja der Austausch und das Nachdenken darüber, was die beste Lösung ist – was auch immer die beste ist. Aber allein darüber muss man sich ja schon unterhalten.
Also, dieser Blick darauf, dass die jetzt alles haben, was sie brauchen, und jetzt bitte „durchentwickeln“ sollen – das ist schwierig, auf jeden Fall. Es ist immer so, und da komme ich gleich mehrfach drauf zurück, es gibt hier kein Schwarz-Weiß, wie so oft. Natürlich braucht man eine Ruhephase, eine Konzentrationsphase – das ist klar. Aber das andere Extrem – dass alle Infos da sind und ab jetzt nicht mehr gestört wird und nur noch durchentwickelt wird, ohne Rückfragen zu stellen – ist vielleicht das andere Extrem.
Was ist denn mit Rückfragen? Vielleicht ist es bei euch anders, aber ich weiß aus meiner Erfahrung heraus, dass selbst mit Splitting, Refinement und allem, was dazugehört, bei mir während der Entwicklung tatsächlich noch Detailfragen auftauchen. Das ist ja auch richtig so. Man lernt ja. Auch in dieser kurzen Zeit kommen neue Erkenntnisse, und der Fokus ist auf einmal ein ganz anderer. Und was macht man dann an der Stelle, wenn man jetzt ganz extrem sagt: „Bitte entwickelt jetzt auch zwei Wochen oder vier Wochen – oder was auch immer der Sprint ist – durch!“? Soll man diese Rückfragen asynchron stellen, nur per Mail oder so? Kann ich mir schwer vorstellen. Das geht, natürlich geht das mal, aber das stoppt mehr, als es beschleunigt.
Für mich ist ein weiterer Punkt: Wir schauen ins Agile Manifest, so wie ich das so gerne und so oft tue. Der erste Punkt im Agile Manifest: Individuen und Interaktionen mehr als Prozesse und Werkzeuge. Selbst wenn in einem Guide oder in irgendwelchen Richtlinien steht, „das ist unser Prozess“, gilt: Interaktion steht bitte über dem Prozess. Da würde ich auch wenig mit mir diskutieren lassen. Natürlich gibt es Prozesse, die vielleicht rechtlich relevant oder verwirrend sind. Klar, daran muss man sich dann halten. Aber grundsätzlich gilt eben: Interaktion mehr als Prozess. Und ich denke, das ist auch wirklich im Sinne von „Wir wollen schnell entwickeln und das Richtige tun“ – nicht im Sinne von „Wir wollen das entwickeln, von dem wir denken, dass wir es brauchen, und nicht jetzt noch lange über irgendwas quatschen.“ Ich nenne das jetzt mal bewusst so despektierlich.
Wie schon gesagt, Coding ist für mich nur ein Teil des Dev-Seins. Das Nachdenken, das Herausfinden, ob es überhaupt das Richtige ist, was man sich gerade überlegt, und dazu der Austausch mit dem PO – um auf Scrum zurückzukommen und das Originalzitat von Stefan: Das Zusammenspiel gehört doch irgendwie dazu. Für mich ist es auch wichtig, dass da nicht so ein Stille-Post-Effekt entsteht. Also: Diese Gruppe darf nur mit dieser Gruppe sprechen, und diese Gruppe spricht dann mit der anderen. Die Devs bitte nur mit dem PO, und der PO klärt es mit den Stakeholdern oder dem Management oder sonst wem. Stille Post ist immer schlimm – ich denke, das wissen wir alle.
Ich würde immer sagen: die richtigen Leute zur richtigen Zeit. Und auch das kann man nicht zu 100 % sagen, sondern es ist immer eine Abwägung. Es gab auch einen Kommentar unter dem Post, den fand ich gut und spannend: „Wie soll das funktionieren? Kommt dann im Review irgendwie raus: ‚Ja, konnten wir nicht fertigstellen, weil wir noch offene Fragen hatten.‘“ Das wäre natürlich auch bitterböse.
Es hängt viel dran, und ich finde es deswegen so schön, dass man mal nur so ein Zitat oder einen Originalton nimmt, um selber in Ruhe drüber nachzudenken: Was tut das mit mir? Und deswegen möchte ich mit dieser Folge das eigentlich nur aufgreifen und euch fast auffordern, da auch mal drüber nachzudenken – und vielleicht sogar noch einen Schritt weiter zu denken: Wie löst man das denn?
Also, wenn das wirklich so ist – und ich glaube, das ist so –, dass wir uns alle permanent austauschen wollen, im Sinne der Sache, dann kann so eine Regel nicht gut sein. Da müsste man eigentlich das Gespräch mit diesem Chef suchen und sagen: „Okay, ich vermute mal, das und das ist deine Angst. Die Leute sollen in Ruhe gelassen werden, nicht alle zehn Minuten rausgerissen werden. Aber wie sieht dann der nächste Schritt aus? Wie können wir das organisieren?“
Und genau so soll diese Folge auch sein: Denkt da noch mal drüber nach. Ich vermute, ihr habt weitere Punkte dazu.
