Browse Author

Robert Wiechmann

Dipl.-Kaufm. Robert Wiechmann unterstützt mit Herzblut Organisationen bei ihrer agilen Transition. Neben der Unterstützung und dem Aufbau von Scrum und Kanban Teams in der Softwareentwicklung, lässt er auch alle weiteren Unternehmensbereiche nicht aus dem Auge. Er hat Freude daran, Teams jeglicher Fasson zu einer Einheit zusammenzuschweißen und sich dabei ständig weiterzuentwickeln. Die Basis seiner Arbeit baut auf Respekt, Vertrauen sowie Wertschätzung auf. Wichtig ist ihm das Zusammenspiel von Zielorientierung, Klarheit, Einfachheit, Selbstverantwortung, Kreativität und Spaß. Sein Mut, offen auch unbequeme Dinge anzusprechen, lässt die Arbeit mit ihm praxisorientiert und auf Augenhöhe sein. Seine Arbeit als Agiler Coach ist von Kreativität geprägt und scheut auch nicht die Beschreitung neuer Wege.

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