Wie wir Stand-up-Meetings führen (es ist kein Daily Scrum)

Für dieses Meeting wurde kein Board aktualisiert.

Wir arbeiten nicht gern mit Agile Frameworks™ wie Scrum. Wir wissen, wie es geht. Wir haben Teams geleitet, die mit Scrum und ähnlichen Methoden gearbeitet haben. In manchen Fällen passt es, und es kann gut funktionieren. Es ist nur nicht das, was wir im Alltag am effizientesten und angenehmsten finden.

Das Konzept eines täglichen Stand-ups lieben wir dagegen. Es ist meist das Erste, was wir einführen, wenn wir zu einem neuen Kundenteam stoßen, das noch keins hat. Aber wir führen Stand-ups nicht wie Daily Scrums, und deshalb zeigen wir hier, wie wir es tatsächlich machen, intern bei Norveon genauso wie mit den Teams, mit denen wir arbeiten.

Wie wir es heute aufsetzen würden

So würden wir es einem neuen Team erklären:

Das Ziel ist, interessante Dinge zu teilen, die für Ihr Team relevant sind, und Blocker anzusprechen. Was als „interessant“ gilt, hängt vom Kontext ab. Nutzen Sie Ihr Urteilsvermögen und zögern Sie nicht, die Gruppe zu fragen, ob etwas für sie interessant ist.

Wir treffen uns täglich um 12:03 vor dem Mittagessen für etwa 15 Minuten. An manchen Tagen sind es 10, an anderen vielleicht 20. Bei Bedarf achtet jemand auf die Zeit, aber wir verlassen uns darauf, dass sich alle kurzfassen.

Das Ganze ist flüchtig. Keine Boards, keine Notizen. Wenn etwas Kritisches geteilt wird, muss es asynchron schriftlich wiederholt werden. E-Mail, Slack, egal.

Das ist kein Reporting-Meeting. Es ist völlig in Ordnung, an manchen Tagen nichts zu teilen. Es ist sogar erwünscht. Sie werden kaum jeden Tag etwas erleben, das sich zu erzählen lohnt. Ja, das meinen wir ernst. Sie werden sehen, dass wir es selbst so machen.

Sie werden Updates hören, die Sie nicht direkt betreffen. Vielleicht Dinge, die Sie nicht vollständig verstehen. Das ist normal und so gewollt. Ihre Aufgabe ist es, aufmerksam zu sein, neugierig zu bleiben und zu versuchen, zu folgen, was alle teilen. Stellen Sie danach Fragen.

Alle paar Monate stellen wir dieses Format infrage. Dazu gehört auch die Frage, ob wir es abschaffen. Was wir hier vorschlagen, ist das Ergebnis jahrelanger kleiner Iterationen. Wir mögen es sehr, aber es passt nicht für alle gleich gut. Irgendwo müssen wir anfangen.

Was als „interessant“ gilt

Dieser Teil ist absichtlich vage. Was es wert ist, geteilt zu werden, hängt vom Team und vom Kontext ab.

Etwas konkreter, das kommt bei uns häufig zur Sprache:

Entdeckungen. Neue Technologie, neuer Teil des Stacks, neue Geschäftschance.
Feature-Fortschritt. Etwas Begonnenes, ein wichtiger Meilenstein, ein Release, Feedback aus den Daten.
Anstehende Projekte. Discovery-Ergebnisse, Research-Erkenntnisse, geschäftliche oder rechtliche Anforderungen.
Zuverlässigkeitsprobleme. Bugs, Ausfälle, Post-Mortems, Performance-Änderungen.
Organisatorische Änderungen. Neuzugang, neues Team.
Persönliche Ereignisse. Babys, Umzüge.
Blocker. Ein Review wird gebraucht, Kommunikationsproblem, fehlende Klarheit.
Büro-News. Neue Richtlinien, anstehende Teambuilding-Events.

Was dieses Meeting nicht ist

Genauso wichtig ist, wofür dieses Meeting nicht gedacht ist:

Ein Board aktualisieren. Das geht asynchron besser.

Aufgaben berichten oder nachverfolgen. Dito. Vor allem, weil nicht jeder jeden Tag ein Update teilen wird.

Leute zur Rechenschaft ziehen. Die Menschen hier sind Profis und sollten kein tägliches Meeting brauchen, um zu beweisen, dass sie vorankommen. Wenn jemand Schwierigkeiten hat, sollte das an anderer Stelle auffallen und dort besprochen werden.

Den Tag planen. Tun Sie das in kleineren, fokussierten Gruppen. Nicht jeden Tag, und Teammitglieder sollten ihre Projekte so autonom wie möglich steuern dürfen.

Leute zwingen, früh am Morgen anwesend zu sein. Ja, das haben wir erlebt.

Ein bestimmtes Ziel erreichen. Da das kein Scrum ist, gibt es womöglich keinen Sprint und kein Sprint-Ziel. Ziele zu erreichen ist das Nebenprodukt eines eingespielten, effizienten Teams.

Warum wir glauben, dass das funktioniert

Die wichtigsten Vorteile eines kurzen täglichen Treffens:

Empathie aufbauen. Bevor Sie einen großen PR zum Review bekommen, haben Sie den Engineer schon darüber sprechen hören. Sie kennen den Kontext der technischen Entscheidungen, die Schwierigkeiten, die Abwägungen. Sie wissen auch etwas über die Verfassung der Person. Ist sie spät dran? Gestresst? Sie können Ihre Kommunikation anpassen. Dasselbe gilt, wenn der PM vom Druck aus dem Geschäft erzählt.

Entdecken, was andere tun. Über die Jahre haben wir so viel über die Arbeit von Engineers in Bereichen gelernt, die wir weniger kannten, einfach indem wir ihnen täglich zugehört haben, wie sie erklären, womit sie gerade ringen. Noch besser wird es, wenn Designer und PMs dabei sind und ebenfalls teilen.

Gelegenheiten für Diskussionen schaffen. Wenn Sie nur auf Ihre Aufgaben und Tickets fixiert bleiben, sind Sie kurzfristig vielleicht produktiver, aber Ihr Fokus wird sehr eng. Damit schränken Sie auch ein, was Sie bewirken können.

Den Puls des Teams fühlen. Fühlen sich die Leute gut, produktiv, positiv? Oder kämpfen alle? Für uns als verteiltes Team, in dem man nicht auf Gespräche an der Kaffeemaschine zählen kann, ist das besonders wichtig.

Ein Gespür dafür bekommen, wer woran arbeitet. Wenn man jemanden monatelang über ein Thema sprechen hört, bleibt das hängen. Sie wissen, an wen Sie Fragen weiterleiten, wenn es so weit ist.

Teamdynamik verbessern. So wie regelmäßige 1:1s mit der Führungskraft eine Arbeitsbeziehung aufbauen, ist regelmäßiger Austausch mit Teamkollegen weit effektiver als ein Workshop einmal im Quartal.

Und ein kleiner Bonus für Teams vor Ort: Es vor dem Mittagessen zu machen, ist ein natürlicher Abschluss des Vormittags und bringt die Leute dazu, gemeinsam zu essen. Günstiges Teambuilding. Überraschend effektiv.

Fragen, die wir immer bekommen

Wir haben das über die Jahre in vielen Teams eingeführt. Unterm Strich war es positiv. Nicht 100 % der Leute haben 100 % des Nutzens bekommen, aber der ROI war gut genug, um weiterzumachen. Diese Fragen und Einwände hören wir immer wieder.

„Das stört. Ich bin besser dran, wenn ich mich auf meinen Code konzentriere.“

Da es jeden Tag stattfindet, können Sie Ihren Tag darum herum planen. Zugegeben, es stört. Aber wie regelmäßige 1:1s ist es eine Investition. An einem einzelnen Tag lohnt es sich vielleicht nicht spürbar, der Nutzen zeigt sich erst mit der Zeit.

Sie denken vielleicht, Ihre Rolle besteht nur darin, Code zu schreiben, Figma-Designs zu erstellen oder PRDs aufzusetzen. Sie umfasst mehr. Ihr Team zu verstehen, ist wichtiger, als Sie erwarten würden. Die Zeit macht die spätere Zusammenarbeit einfacher und erspart Ihnen Kopfschmerzen.

„Das sollten wir asynchron machen.“

Es geht um Empathie und Nähe, und das schriftlich zu erledigen, halten wir für kontraproduktiv. Wir sind noch nicht überzeugt, dass das Lesen einer Slack-Nachricht dieselbe Wirkung hat wie zu sehen, wie jemand dasselbe mündlich teilt.

Außerdem hinterlassen schriftliche Updates eine Spur und fühlen sich irgendwann wie Reporting an. Genau das wollen wir vermeiden.

„Niemand wird verstehen, woran ich arbeite.“

Manchmal arbeiten Sie an etwas Kniffligem, das nur Sie vollständig verstehen. Das ist in Ordnung. Nehmen Sie sich etwas mehr Zeit, den Kontext zu erklären. Vielleicht müssen Sie ihn öfter wiederholen, was Mehrarbeit ist.

Aber es hat einen doppelten Nutzen: Mehr Leute werden in Ihr Thema eingearbeitet, und Sie werden besser darin, tiefe technische Arbeit verständlich zu machen. Beides lohnt sich.

„Ich bin Designer, mich interessiert nicht, was die Entwickler machen.“

Wir halten das für die falsche Sichtweise. Engineers zu verstehen, und von ihnen verstanden zu werden, entscheidet mit darüber, ob Sie beim Bauen von Software erfolgreich sind. Wenn Sie Entwicklung nur als Implementierungsdetail sehen, begrenzen Sie, welche Designs Sie tatsächlich vor Nutzer bringen können. Das wollen Sie vermutlich nicht, es sei denn, Ihr Job besteht nur aus Mockups und statischen Assets.

„Ich bin Engineer, mich interessiert nichts außerhalb des Engineerings.“

Ebenfalls der falsche Ansatz. Wer Produkte baut, profitiert enorm davon, mehr als nur die Technik zu verstehen. Design mag nicht Ihr Thema sein, aber wenn Sie täglich ein paar Minuten davon mitbekommen, erkennen Sie Abkürzungen, Design-Debatten laufen reibungsloser, und Sie haben bessere Argumente gegen zu komplexe Lösungen.

Wir möchten Sie ermutigen, Ihren Job als mehr als nur Programmieren zu verstehen. Dabei hilft es, sich für andere Bereiche zu öffnen, und hier lernen Sie mit ein paar Minuten Aufmerksamkeit am Tag dazu. Kein schlechter Tausch.

„Wir haben schon zu viele Meetings.“

Wenn Sie viele andere Meetings haben, würden wir eher diese überprüfen und ausmisten. Das tägliche Stand-up senkt die Zahl der Meetings insgesamt, weil es Probleme und Missverständnisse früh abfängt. Es zu streichen, macht 15 Minuten frei, kostet aber später viele Stunden mehr.

„Das ist nicht Scrum-konform.“

Richtig. Es ist kein Daily Scrum und hat nicht dieselben Ziele.

„Sie sagen, es sei kein Reporting, aber genau das ist es.“

Wir verstehen, warum es sich so anfühlen kann. Aber wir halten nicht fest, was geteilt wird, und es verlässt das Team nicht. Sie sind eingeladen, zu teilen, was interessant ist, und das ist nicht immer direkter Fortschritt bei Ihren Aufgaben, was das Ganze zu einem miserablen Reporting-Tool macht. Da nutzen wir viel lieber unseren normalen Ticket-Tracker, um zu sehen, was läuft.

„Ich traue mich nicht, nichts zu teilen.“

Wenn Sie neu im Team sind, ist das normal. Keine Sorge. Sie werden sehen, dass andere es tun, und mit der Zeit sollte es weniger einschüchternd wirken.

„Kann man wirklich nichts teilen?“

Ja. „Nichts wirklich Interessantes seit dem letzten Mal“ funktioniert. „Immer noch an derselben Aufgabe, nichts Neues“ funktioniert auch.

Wenn jemand mehrere Tage hintereinander nichts zu teilen hat, kann das ein Warnzeichen sein. Erfahrungsgemäß steckt meist einer von drei Gründen dahinter:

Die Person hält ihre Themen nicht für interessant. Dann hilft ein kurzer Hinweis, warum andere von einem bestimmten Teil ihrer Arbeit hören wollen könnten.
Sie hat ein tieferliegendes Problem. Mit dem Prozess, der Arbeit, dem Team, dem Unternehmen oder dem Leben im Allgemeinen. Das muss man sich im Einzelfall ansehen, und es zeigt sich meist auch außerhalb des Stand-ups.
Sie steckt fest und fühlt sich nicht sicher genug, das zu sagen. Das löst sich meist von selbst, sobald sie sieht, dass andere offen über Blocker sprechen.

Bei der Entwicklung dieses Stand-up-Formats kam kein Framework zu Schaden. Ihre Ergebnisse können abweichen.