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 magische Schätzmethode

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Neben dem von Sven kürzlich vorgestellten Team Estimation Game, möchte ich heute noch eine weitere Herangehensweise vorstellen, die mir zu Ohren gekommen ist und eine zügige initiale Schätzung des gesamten Product Backlogs möglich machen soll: Magic Estimation.

Gerade beim Start eines neuen Projektes ist es häufig wichtig, schnell zu einer Aussage über den Zeitaufwand für die zu entwickelnden Funktionalitäten zu kommen. Vor dem ersten Sprint sollten daher ausreichend Backlog Items für mindestens 1-3 Sprints im Backlog vorhanden und priorisiert sein, um diese vom Team schätzen zu lassen. 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

Wie stellt man sicher, keinen schlechten Code zu produzieren?

Eine Frage, die in Projekten immer wieder auftaucht. Warum? Weil beispielsweise das Management möchte, dass schneller entwickelt wird. Die Basis-Architektur der Software nicht mehr zeitgemäß ist oder die Dokumentation fehlt. Ken Schwaber macht immer wieder deutlich, dass die Software-Entwickler für die Qualität des Codes verantwortlich sind. In seinen Büchern, sowie auch in einer älteren Präsentation Canary in a Coal Mine, versucht er ein Bewußtsein dafür zu schaffen. Ziel ist es, Verständnis und Professionalität zu steigern, um schlechtem Code und aufwendige Wartungsarbeiten vorzubeugen. Solides Handwerk und Nachhaltigkeit, sieht er als die Schlüssel zum Erfolg. Wie schon berichtet, kommt die Entwicklung des Software Craftsmanship dieser Forderung nach. Der Titel, der kürzlich auf InfoQ erschienenden Präsentation From good to great Developer, unterstreicht nochmals die Aktualität des Themas. Weiterlesen