Browse Category

Scrum

Wer schreibt eigentlich die User Stories?

Der Einsatz von User Stories in der Agilen Softwareentwicklung wird immer populärer. Viele sehen das Verfassen von Benutzergeschichten als Aufgabe des Product Owners – aber wieso eigentlich?

Ich bin der Meinung, dass jeder User Stories erstellen kann. Mike Cohn plädiert sogar dafür, dass alle Projektzugehörigen mindestens eine User Story verfasst haben sollten. Ich verfolge diesen Ansatz auch in meinen Projekten und habe gute Erfahrungen damit machen können. Zwei Anwendungsfälle aus der Praxis möchte ich heute kurz vorstellen.

Im ersten Fall mussten wir bei Start eines Projektes zügig zu ersten User Stories gelangen. Da das Projekt sehr technisch ausgelegt war, waren die Entwickler aus dem Team prädestiniert für das Schreiben der initialen Stories. Also veranstaltete ich mit dem Team und Product Owner einen User Story Workshop. Dieser startete mit den Grundlagen. Daraufhin ging es schnell an das Eingemachte und wir definierten die User Rollen und bestimmten die Ziele.

Keep Reading

Teamarbeit – Konzept wechselnder Eigentümer

In der letzten Woche habe ich einen kurzen Beitrag über Programmierung in Paaren verfasst. Pairprogramming involviert jedoch häufig nur die beiden Entwickler, die sich gerade mit dem Backlog Item auseinandersetzen. Auf der Website Agile in Action bin ich auf eine interessante Methode aufmerksam geworden, weitere Entwickler in die Fertigstellung einer Story einzubeziehen: Rolling Ownership.

Rolling Ownership bedeutet, dass es der Prozess ermöglicht, möglichst viele Entwickler aus dem Team in die Entwicklung einer Story einzubeziehen. Wenn ein neues Backlog Item angefangen wird, erklärt sich jemand als Freiwilliger diese Story zu übernehmen und ein Zweiter, dass er mit demjenigen an der Story arbeiten möchte. Bis zur Mittagszeit arbeiten die beiden an der Story. Danach gibt der Eigentümer die Story an seinen morgendlichen Partner ab und kümmert sich um ein anderes Item. Der Partner erhält einen neuen Freiwilligen um an der Story weiterzuarbeiten. Dies wird für alle Stories – die in Bearbeitung hängen – gleich gemacht. Keep Reading

Das Daily Stand-up Meeting variieren

Eines der Meetings des Scrum Frameworks ist das tägliche 15-minütige Stand-up Meeting, welches dem Team dazu dient, den aktuellen Status auszutauschen. Das Meeting hat einen festgelegten Ablauf, wird jedoch erfahrungsgemäß in jedem Scrum Team anders abgehalten. Hier einige Informationen, persönliche Erkenntnisse und interessante Abwandlungen.

Der „Standard“

A good stand-up will feel self-managed. [Yason Yip] Das Meeting dient den Team Mitgliedern zum Informationsaustausch und ist bewusst kurz gewählt, um anschließend die Kommunikation untereinander oder in Einzelgesprächen anzuregen. Es läuft standardmäßig nach folgendem Grundschema ab:

  • auf 15 Minuten begrenzt (timeboxed)
  • alle Teilnehmer sind anwesend und stehen im (Halb)Kreis vor dem Scrum Board
  • jedes Team Mitglied ist nacheinander an der Reihe und informiert die anderen Teammitglieder über folgende drei Fragen:
    • Was habe ich seit dem letzten Stand-up erreicht?
    • Was will ich bis zum nächsten Stand-up erreichen?
    • Was hindert mich im Moment daran, meine Arbeit zu machen? (Impediments)
  • die Redezeit pro Teammitglied ist beschränkt und sollte sich auf die entsprechenden Karten fokussieren
  • der Scrum Master moderiert (wenn nötig) das Meeting und notiert sich ggf. die genannten Impediments
  • der Product Owner nimmt im besten Fall immer teil und steht für Fragen zur Verfügung
  • die passive Teilnahme am Meeting steht jedem Stakeholder offen
  • das Meeting findet am Vormittag immer zur selben Zeit statt

Den besten und ausführlichsten Beitrag, den ich über das Daily Stand-up gelesen habe, lautet It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings und ist von Jason Yip. Zudem empfehle ich diesen älteren Beitrag, der Tipps zum Daily Scrum enthält. Es sind nicht unbedingt die Tipps die interessant sind… sondern eher die entbrannte Diskussion.

Hier einige Vorschläge, das tägliche Meeting anzupassen.

Keep Reading

Einsatz von Tiger Teams in Pilotprojekten

Eine interessante Herangehensweise, um Scrum im Unternehmen zu etablieren, habe ich auf dem Scrum Day 2009 von Dr. Andrea Tomasini mitgenommen – der Einsatz von Tiger Teams.

In dem dort gezeigten Beispiel, wurde Scrum anhand eines für das Unternehmen strategisch wichtigen Pilotprojekts erfolgreich verbreitet. Wie man das richtige Pilotprojekt identifiziert, beschreibt Mike Cohn in einem kürzlich verfassten Artikel. Hat man das Pilotprojekt im Unternehmen ausfindig gemacht, geht es an die richtige Besetzung des Teams. Hierzu wählt man die besten Leute aus dem Unternehmen aus bzw. diejenigen, die über Erfahrungen mit agiler Softwareentwicklung verfügen. Die Sprunglatte für das erste Projekt setzt man so hoch an, dass man noch drüber springen kann oder mit anderen Worten, dass das Ziel gut erreichbar ist und genügend Business Value geliefert werden kann. Man erzielt somit den Effekt, dass einerseits das Team den Scrum Prozess verinnerlicht und anderseits, ein erfolgreiches Projekt hochgehalten werden kann. Dies dient anschließend dazu, Argumente für den Einsatz von Scrum zu finden. Das vorrangige Ziel des Tiger Teams wird nun deutlich – es soll Scrum an andere weitergeben.

Auf dem Scrum Day (hier mein Rückblick) brachte Tomasini dazu folgendes Beispiel an: Das Pilotprojekt wurde erfolgreich durchgeführt und gelauncht. Nun sollten auch alle anderen aus der Entwicklungsabteilung in fünf neue Teams aufgeteilt werden. Dazu wurden alle notwendigen Personen in einen Raum zusammengebracht, um sich unter der Bedingung – jedes Team soll zwei Personen aus dem Tiger Team aufnehmen – zusammenzustellen. Das Involvement und die Evolution der Teams wurden dabei quasi von Grund auf mitgeliefert.

Hat jemand ähnliche Erfahrungen gemacht bzw. dasselbe Vorgehen gewählt?

Graphic Resource: Background vector designed by Freepik