Ist das Daily Standup für Teammitglieder zwingend?

Daily StandupVon Zeit zu Zeit erhalte ich Anfragen von Lesern, zu denen ich natürlich sehr gerne auch Rückmeldung gebe. Im aktuellen Fall handelt es ich um eine Frage, die uns vor längerer Zeit auch einmal bewegt hat: “Ist das Daily Standup für Teammitglieder zwingend?”
Gerne führe ich meine Gedanken hierzu aus, freue mich aber auch über Ergänzungen anderer Leser über die Kommentarfunktion.

Was ist ein Daily Standup?

Um alle Leser abzuholen, möchte ich noch einmal vorstellen, worum es sich bei Daily Standups eigentlich handelt. Daily Standups sind tägliche Kurzbesprechungen des Projektteams und einer der Grundbestandteile agiler Softwareentwicklung. In Scrum wird hierfür die Bezeichnung “daily scrum” verwendet. Es ist ein fest verankertes Element in Scrum. Aber auch in Teams, die mit Kanban arbeiten, werden tägliche Standup-Meetings häufig eingesetzt.

Als Grundregel kann angesehen werden, dass dieses Meeting maximal 15 Minuten dauern sollte. Jeden Tag, zur selben Uhrzeit am gleichen Ort. In dieser Zeit beantworten alle Teilnehmer die folgenden Fragen:

  • Was wurde seit dem letzten Standup-Meeting gemacht?
  • Was wird bis zum nächsten Standup-Meeting erledigt?
  • Gibt es Hindernisse, Herausforderungen oder Optimierungsbedarfe, die angegangen werden sollten?

Optimalerweise findet dies an einem Taskboard statt, wie in obigem Bild dargestellt, damit alle auch direkt sehen können, von welcher Aufgabe der Kollege gerade spricht. Gemeinsam wird dann dieses Taskboard auch im Standup-Meeting aktualisiert, etwa erledigte Aufgaben verschoben.

Ist ein Teilnahmezwang für Daily Standups sinnvoll?

In der weniger agilen Praxis werden die Standup-Meetings häufig in Frage gestellt. So sind sowohl bei den Projektteams selbst als auch beim Management der Sinn und Nutzen nicht selten umstritten.

Zunächst einmal ist es meines Erachtens sinnvoll, den täglichen Einsatzbesprechungen eine ernsthafte Chance zu geben. Hat das Team also noch gar keine Erfahrung damit gemacht, wäre es ein guter Schritt, diese für einen längeren Zeitraum, zum Beispiel für 4 oder 6 Wochen oder bei Scrum-Teams für 2-3 Sprints einfach einmal auszuprobieren. Einen Zwang würde ich für nachteilig halten, da hier ganz klar mit Gegenwehr gerechnet werden muss. Vielmehr sollte das Team gemeinsam einen solchen Test-Zeitraum beschließen. Wenn dann negative, schlecht begründete Kritik auftaucht, kann derjenige darauf verwiesen werden, dass sich gemeinsam für eine Testphase entschieden wurde, die erst einmal abgewartet werden sollte. Wenn ernsthafte Verbesserungsvorschläge vorgetragen werden kann geschaut werden, dass diese möglichst schon frühzeitig mit in die Standups eingebracht werden.

Wir haben die Erfahrung gemacht, dass Standup-Meetings von Teammitgliedern insbesondere in den folgenden Fällen kritisiert werden:

  • Die Meetings ziehen sich ewig hin und kommen nicht auf den Punkt. Dann sollte darauf geachtet werden, dass die Timebox eingehalten wird und Themen, die nur einen kleinen Teil der Gruppe betreffen erst im Anschluss an das Daily Standup besprochen werden.
  • Es wird gar nicht zusammen gearbeitet. Wenn jeder eh an seiner eigenen Baustelle arbeitet, dann erscheint der gegenseitige Austausch natürlich überflüssig. In diesen Fällen steht das Team vor einer größeren Herausforderung und sollte sich eventuell einmal damit beschäftigen, wie Teamwork in der agilen Softwareentwicklung verstanden und angewendet wird.
  • Es fehlt eine Moderation. Bei Scrum-Teams macht dies häufig der Scrum-Master, die Moderation kann aber auch abwechselnd von Teammitgliedern übernommen werden. Es sollte aber immer klar sein, wer gerade Moderator ist und dieser sollte z.B. darauf achten, dass die Redeanteile möglichst ausgeglichen sind. Nur wenn auch alle zu Wort kommen, macht es für sie auch Sinn, sich an dem Meeting zu beteiligen.
  • Es fehlt eine feste Zeit und ein fester Ort. Wenn die Meetings nicht allen Teammitgliedern in Fleisch und Blut übergehen und einen festen Platz im Kalender aller Teammitglieder haben, geht unnötig viel Zeit dafür verloren zu klären, warum Kollege A und Kollegin B gerade noch nicht anwesend sind. Manche Teams arbeiten auch mit “Strafen”, falls jemand unentschuldigt fehlt oder zu spät kommt. Dies können z.B. 10 Cent für das Team-Sparschwein sein, die dann nach etwas sammeln in einen Kuchen für das Team investiert werden.
  • Probleme werden nicht angegangen. Wenn immer wieder die gleichen Herausforderungen auftreten oder ein Kollege im Standup jeden Tag das gleiche erzählt, da er offensichtlich ein Problem mit einer Aufgabe hat, sollten beim Team die Alarmglocken angehen und für eine dauerhafte Lösung gesorgt werden. Standup-Meetings sind eine gute Möglichkeit, kontinuierliche Verbesserungsprozesse anzustoßen.

Nach dem wir nun ein paar Jahre Erfahrung mit Daily Standups haben, kann ich mir kaum noch vorstellen, wie ein Team, dass sehr eng zusammen arbeitet, ohne diese kurzen Einsatzbesprechungen effektiv und effizient zusammen arbeiten kann.

Weitere Informationen zu Daily Standups:

Foto: tomnatt

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

About these ads

Sprint-Review: Konstruktives Feedback geben, wenn es einmal schlecht läuft

Review / Demo / Sprint-Review / Scrum ReviewDer Sprint neigt sich dem Ende zu und das Review-Meeting, welches im Rahmen jedes Scrum-Sprints zur Präsentation der Arbeitsergebnisse durchgeführt wird, steht an. Spätestens jetzt zeigt sich, was das Scrum-Team in den letzten Wochen geleistet hat und erreichen konnte. Der Product Owner ist gefordert, “seinem” Team Feedback dazu zu geben, wie er mit den Arbeitsergebnissen zufrieden ist.

Doch wie sollte er damit umgehen, wenn es einmal wirklich schlecht gelaufen ist und das Team bei weitem nicht die Fortschritte erreichen konnte, die gemeinsam geplant wurden?

Dem Team zuhören

Zunächst einmal ist es wichtig, dem Team die Chance zu geben, aufgetretene Hindernisse im Sprint-Verlauf darzulegen. Womöglich waren sie durch größere Ereignisse im Live-Betrieb von der Arbeit am Sprint-Ziel verhindert, haben aber ihr bestes gegeben, das System am laufen zu halten. Dies kann z.B. der Fall sein, wenn ein ungewöhnlich starkes Nutzerwachstum aufgetreten ist, dass sich nicht vorhersehen ließ. Dadurch ändert sich nicht die Situation, dass das Sprintziel nicht erreicht wurde, es ist aber doch ein Unterschied, ob das Team alles gegeben hat und es trotzdem nicht geklappt hat, oder ob die Verfehlung des gemeinsamen Ziels andere Gründe hatte. Womöglich teilt das Team dabei auch wichtige Informationen mit, die dem Product Owner und dem ScrumMaster die Möglichkeit bieten, das Team bei der Erreichung zukünftiger Zielsetzungen zu unterstützen. Damit es dazu kommen kann, muss dem Team aber die Möglichkeit gegeben werden, eine Selbsteinschätzung zu geben.

Die eigene Perspektive erklären

Das Feedback des Product Owners sollte klar und verständlich zum Ausdruck kommen. Das sollte allerdings jederzeit sachlich und konstruktiv erfolgen. Wurde nicht nach den vereinbarten Prioritäten gearbeitet, kann noch einmal herausgestellt werden, warum sie so festgelegt wurden. Wurde einem Stakeholder gegenüber in Abstimmung mit dem Team eine Zusage gemacht, die nun nicht eingehalten werden kann, sollte das auch noch einmal betont werden. Die Konsequenzen des schlechten Sprintverlaufs sollten dargestellt werden. Da der Product Owner die wirtschaftliche Verantwortung für das Projekt trägt, sollte er gerade auch die betriebswirtschaftliche Sicht mit einbringen und die Interessen der Stakeholder vertreten.

Das Ziel nicht aus den Augen verlieren

Ein schlechter Sprint tut weh. Er tut dem Product Owner weh, der die wirtschaftliche Verantwortung für das Projekt trägt. Er tut dem Team weh, das seine selbst gesteckten Ziele nicht erreicht hat. Und auch dem ScrumMaster tut er weh, da ihm eine Menge Arbeit bei der Aufarbeitung bevorsteht.
Aus dieser schmerzlichen Situation heraus sollte das Ziel des Product Owners nicht sein, dass das Team sich noch schlechter fühlt. I.d.R. können sich die Teams auch selbst gut einschätzen und sind selbst unzufrieden, wenn das Sprintziel nicht erreicht wurde. Dennoch sollte er klar darstellen, wie die Erwartungshaltung war und wie das gelieferte Ergebnis sich dazu verhält. Es kann auch anhand eines Release-Burndown-Chart ermittelt werden, wie die Auswirkungen auf den Releasetermin (wenn der Umfang fixiert, das Datum variabel) oder den Releaseumfang (wenn der Umfang variabel, das Datum fixiert ist).

Gemeinsam nach Lösungen suchen

In der Retrospektive besteht noch einmal ausführlich die Möglichkeit, den zurückliegenden Sprint aufzuarbeiten und Verbesserungsmaßnahmen zu erarbeiten. Persönlich habe ich gute Erfahrungen damit gemacht, als Product Owner bei den Retrospektiven des Teams dabei zu sein. Das machen wir allerdings nur, wenn das Team dem zustimmt. Denn für einen offenen Umgang mit Kritik ist eine situative Ermöglichung der Kritik erforderlich. Die Teammitglieder müssen das Gefühl haben, dass sie Fehler offen ansprechen dürfen. Das ist meist eine Frage des Vertrauens.

Fazit

Gerade ein schlechter Sprint zeigt, ob das Team wirklich ein Team ist. Der Product Owner sollte seine Erwartungen und die Erwartungen des Stakeholder klar vertreten. Vertrauen ist die Basis für ein erfolgreiches Team.

 

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: psd

Konflikte gehören dazu: Teambildungsprozesse in der Softwareentwicklung

Es ist unheimlich spannend, Softwareentwicklungsteams bei den ersten Sprints eines neuen Scrum-Projekts zu beobachten. Es ist eine intensive Zusammenarbeit gefordert, um als Team erfolgreich zu sein.
Und wenn ich sage, dass der Prozess spannend ist, bedeutet das auf keinen Fall, dass es nur schöne Seiten hat. Die enge Zusammenarbeit, optimalerweise in einem gemeinsamen Teamraum, führt durchaus zu Konflikten. Diese Konflikte werden häufig noch als etwas Schlechtes angesehen. Dabei sind sie extrem wichtig. Als Team Konflikte zu haben bedeutet auch, dass offen über Meinungsverschiedenheiten gesprochen wird. Dies ist besser als eine Situation, in der sie unter den Teppich gekehrt und nicht aufgelöst werden. Dennoch müssen sich Teams einspielen, was die Austragung und Überwindung von Konflikten anbelangt. Dabei ist es hilfreich, wenn die Teammitglieder grundsätzliche Kenntnis über Teambildungsprozesse haben. Ein häufig referenziertes Modell des Teambildungsprozesses geht auf Bruce Tuckman zurück. Dieses stelle ich in einem aktuellen Artikel vor.

Zum Artikel im //SEIBERT/MEDIA Blog

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Produktmanagement Lesetipps: Pair Programming, Teamstimmung sichtbar machen, Remote User Tests, Scrum Glossar

Eine Auswahl von aktuellen interessanten Artikeln über agile Entwicklungsmethoden, User Testing und Scrum:

Dir hat dieser Beitrag gefallen? Dann hinterlasse doch einen Kommentar. Wenn du über das Produktmanagement und die Vermarktung von Internetanwendungen auf dem Laufenden gehalten werden möchtest, kannst du auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Card, Conversation, Confirmation: Die drei C’s einer User Story

Was gibt es bei der Erstellung von User Stories zu beachten? Drei C’s können dabei helfen: Card, Conversation, Confirmation. Die drei C’s gehen auf Ron Jeffries zurück, der sie schon 2001 in einem Blogpost beschrieb: Essential XP: Card, Conversation, Confirmation.
Noch heute gelten sie neben den INVEST-Kriterien als wichtige Grundregel bei der Erstellung von User Stories.

Card
User Stories sollen kurz und prägnant sein. Sie sollen in erster Linie an den Kundenwunsch erinnern und die wichtigsten Punkte, die mit dem Team vereinbart wurden, festhalten. Viele agile Software-Entwicklungsteams verwalten Stories und Tasks offline, z.B. in Form eines Taskboards. Die Kundenwünsche werden dann auf Karteikarten festgehalten. Es sollte damit nicht mehr Platz als der auf der Karte verfügbare benötigt werden, um dem Team klarzumachen, was mit der Umsetzung der Story erreicht werden soll. Reicht der Platz nicht aus, ist die Story in der Regel zu groß oder wird zu umfangreich dokumentiert. Über die Card hinaus werden Informationen über den Wunsch in Form der Konversation mit dem Team abgestimmt.

Conversation
Jede Story wird zwischen dem Kunden und dem Team mindestens einmal besprochen. Der Austausch über die Story wird als sehr wichtig erachtet. Es reicht nicht, auf einer Karte die Anforderungen festzuhalten und dem Team “durch einen Türschlitz” zuzuschieben. Stories werden in der Regel sogar mehrmals besprochen, z.B. während einem Anforderungsworkshop, in einer Schätzklausur und während der Sprint-Planung. Die mündlichen Absprachen werden manchmal begleitet durch zusätzliche Dokumente, wie etwa Vorlagen in einem Projektwiki oder Mockups.

Confirmation
Um einen Nachweis zu haben, ob die Stories in der gewünschten Form implementiert wurden, werden für jede Story Akzeptanzkriterien festgehalten. Der Kunde hält dafür vor Beginn der Umsetzung einer Story die zentralen Kriterien fest, nach denen die Abnahme der Story später erfolgen soll. Durch die Implementierung von Akzeptanztests kann die Erfüllung der Akzeptanzkriterien sichergestellt werden.

Mit den drei C hat uns Ron Jeffries eine gute Merkhilfe für die Grundregeln einer User Story an die Hand gegeben.

Weitere gute Lektüre zu User Stories:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: Von jakuza

Arbeiten im Scrumteam: Der visuelle Teamraum

Für Software-Entwicklungsteams, die für einige Zeit zusammen an einem Projekt arbeiten, ist die Einrichtung eines Teamraums eine sinnvolle Maßnahme.

Dies fördert auf unbeschreibliche Weise die Kommunikation zwischen den Projektteilnehmern und trägt damit zum Erfolg bei. Zudem ermöglicht es, einige für den Projekterfolg wichtigen Dinge deutlich sichtbar aufzuhängen.
Darüber, welche Informationen das sinnvollerweise sein sollten, ist im Blog von //SEIBERT/MEDIA ein Artikel von mir erschienen.

Zum Artikel im //SEIBERT/MEDIA Blog

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

User Stories schreiben ist wie Fahrrad fahren


Schon einmal versucht, jemandem zu erklären, wie man Fahrrad fährt? Macht nicht wirklich Sinn, oder? Man muss einfach üben, üben, hinfallen, weiter üben.

So ähnlich ist das auch mit dem Schreiben von User Stories. Diese Form der Anforderungsbeschreibung lässt sich natürlich grundlegend auch rein verbal erklären. Eine User Story besteht aus einem Namen, einem beschreibenden Satz und einer Reihe von Akzeptanzkriterien. Aber gute Stories schreiben lernt man nicht durch eine Erklärung. Das ist genau so ein Balanceakt wie Fahrrad fahren. Die Stories sollen weder zu ungenau, noch zu detailliert, weder zu groß, noch zu klein sein. Übung im Schreiben von User Stories an sich und der Austausch mit dem Team ist dabei unerlässlich. Das Team wird in der Regel sehr deutlich kommunizieren, welcher Detaillierungsgrad einer Story ausreichend ist und insbesondere, wenn er es einmal nicht ist. Ein Anforderungsworkshop mit dem gesamten Team zum Start des Projektes kann helfen, sich aufeinander einzuspielen.

Im Laufe des Projekts entwickelt sich eine gemeinsame Sprache zwischen den Beteiligten, die zu einer Vereinfachung der Zusammenarbeit führt und es damit gerade auch jenen leichter macht, die in dem Projekt einen großen Teil der Stories schreiben.

Aber am Anfang steht: der Anfang. Wie beim Fahrrad fahren. Der Mut wird belohnt.

Weitere Informationen zu User Stories:

Foto: Von Bruce McAdam

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Informationsarchitekten, Designer und Scrum

Bei der Verwendung von Scrum in der Softwareentwicklung werden die genauen Spezifikationen für die Umsetzung von Anforderungen recht kurzfristig innerhalb eines Sprints durchgeführt. Der Product Owner definiert, welches Problem gelöst werden soll, das Team erarbeitet häufig erst “Just-in-Time”, wie die Lösung ausschaut. Genau dieses “Just-in-Time”-Arbeiten stellt Informationsarchitekten und Designer vor eine große Herausforderung.
Inken Petersen und Patrick Roelofs haben für die IA-Konferenz 2009 in Hamburg eine Präsentation genau zu diesem Thema erstellt und bieten 8 Tipps, die bei einer erfolgreichen Integration der Informationsarchitekten in Scrum-Teams helfen sollen.

A List apart empfiehlt dazu:

“Best practice” suggests that designers should research iteration n+2, design iteration n+1, support iteration n and review iteration n-1.

Aber auch hierbei sollte darauf geachtet werden, dass eine enge Kommunikation mit den Entwicklern stattfindet und nicht “im stillen Kämmerlein” gearbeitet wird.

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 1.134 Followern an

%d Bloggern gefällt das: