Browse Tag

Scrum

Meine Bücher aus 2009

Ich habe mir im letzten Jahr viele Bücher gekauft und meine Buchliste für das neue Jahr füllt sich zunehmend. Vielleicht ist ja für den einen oder anderen etwas dabei:

Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten 

Ich bin noch nicht ganz fertig mit dem Buch, jedoch total begeistert. Holger Koschek beschreibt anhand von Geschichten die Nutzung von Scrum. Im Buch werden die grundlegenden Elemente des Frameworks vermittelt. Das etwas andere Fachbuch.

Scrum mit User Stories 

Scrum mit User Stories ist für mich eines der besten Scrum Bücher des letzten Jahres. Die gut ausformulierten Beispiele und praktische Anleitungen sind sehr praxisnah und haben mir besonders gut gefallen. Beim Lesen hatte ich häufig „Aha“-Effekte und habe mir für meine eigene praktische Tätigkeit viele Notizen gemacht. Das Buch liest sich sehr flüssig und ist in sich schlüssig aufgebaut. Gerade die Abschnitte zu den User Stories, dem Schneiden der Stories und dem Planen mit Stories haben mein Interesse geweckt. Weiterlesen

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

Scrum Day 2009 in Düsseldorf – ein Rückblick

Der Scrum Day 2009 fand am Mittwoch in Düsseldorf, besser gesagt in Neuss statt, was mir der Taxifahrer unmissverständlich klarmachte. Es war ein Tag voller Höhen und Tiefen und das lag nicht nur am Flug von Hamburg nach Düsseldorf. Nachfolgend eine kurze Zusammenfassung meiner Eindrücke vom zweiten Tag des Scrum Days, der sich gegenüber dem ersten Workshoptag nur aus Vorträgen zusammensetzte. 

Den Anfang machte Joseph Pelrine mit seiner Keynote, in der er die Frage zu klären versuchte Warum funktioniert Scrum? In seinem Vortrag bezog er sich auf das Warum, da sich alle im Auditorium einig waren – Scrum funktioniert. Interessant und amüsant vorgetragen – trotz einiger Gläser Rotwein am Vortag…

Im Anschluss folgte ein Vortrag der XING AG mit dem Titel AmaXING Agile – keine Heilung ohne Jucken, indem über den Einsatz von agilen Methoden im Unternehmen berichtet wurde. Dabei wurde anhand praktischer Beispiele aufgezeigt, welche Probleme vor der Einführung von Scrum da waren, wie man mit Scrum diesen Problemen entgegentrat und welche Learnings im Laufe der Zeit gemacht wurden. Weiterlesen

Gastbeitrag: Die vierte Frage im Daily Scrum

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Im Rahmen des Daily Scrums werden von jedem Teammitglied in der Regel die folgenden drei Fragen beantwortet:

  • Was habe ich seit dem letzten Daily Scrum erreicht?
  • Was will ich bis zum nächsten Daily Scrum erreichen?
  • Was hindert mich im Moment daran, meine Arbeit zu machen?

Die ersten beiden Fragen sind sowohl für die Teamkollegen (Synchronisation) als auch für den ScrumMaster (Fortschritt? Tasks klein genug?) interessant, die dritte hauptsächlich für den ScrumMaster (“Impediment! Are you ready to die?”).

Insbesondere bei eingespielten Teams, die sowieso sehr eng zusammenarbeiten, können die Daily Scrums sehr zügig über die Bühne gehen. Oft passiert es dabei, dass Impediments nicht mehr explizit benannt werden, sondern irgendwo im Grundrauschen verschwinden. So entsteht der Eindruck, dass alles prima läuft. Am Ende des Sprints kann dann das böse Erwachen kommen: Weiterlesen

Gastbeitrag: Team Estimation Game

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Planning Poker ist in Scrum-Projekten in der Regel die Schätzmethode der Wahl. Es wurde 2002 von James Grenning erstmalig beschrieben und später durch Mike Cohn’s Buch Agile Estimating and Planning sehr populär. Die Regeln sind sehr einfach und das Schätzen kann nach wenigen einführenden Worten starten. Die größte Schwierigkeit bei der Einführung liegt meines Erachtens darin, dem Team den Sinn einer Schätzung von relativer Komplexität anstelle von Aufwand in Arbeitsstunden zu vermitteln.

Wenn diese erste Hürde genommen ist, steht man vor der nächsten Herausforderung: Gerade technisch sehr starke Teams neigen dazu, beim Schätzen bereits Lösungsansätze zu diskutieren. Als Argument dient oft “Für eine gute Schätzung müssen wir doch wissen, wie wir die Story umsetzen wollen”. Wenn man diese Diskussionen als Scrum Master nicht in den Griff bekommt, dauert die initiale Schätzung des Product Backlog viel länger als geplant (falls man überhaupt durchkommt und die weitere Schätzung nicht in die Estimation Meetings während der Sprints verschiebt).

Auf dem Scrum Gathering 2009 habe ich nun eine Methode kennengelernt, die sehr vielversprechend klingt und schnell gute Ergebnisse liefert: Das Team Estimation Game nach Steve Bockman. Die Regeln für das Spiel sind simpel:

Weiterlesen