Signaturen von Burndowncharts

Kane Mar hat einen netten Beitrag über die Signaturen von Burndowncharts geschrieben.

Ich finde seine Meinung zur geraden Sprint Burndown Linie Interessant. Er nennt es den Fakey-Fakey, ich hab erlebt das dieser Burndown als das Ideal angesehen wurde.

Ziel bei dem Projekt in dem ich mit Scrum zu tun hatte, war es, möglichst dieser Linie nahe zu kommen. Als ich in das Projekt einstieg verliefen die Brundowns aber immer zunächst recht Waagerecht, bevor sie dann zum Ende des Sprints fielen. Der Grund dafür war recht trivial. Die einzelnen zu lösenden Teilprojekte waren relativ groß und jeweils ein Entwickler benötigte einen großen Teil seiner Zeit, um sein Projekt zu lösen. Wir haben dann beschlossen, keine Tasks zu machen die im Planning Poker auf mehr als 8 Stunden geschätzt wurden. Wenn dem so war, wurde der Task weiter aufgegliedert.

Dieses hatte dann zur Folge, dass sich unsere Planning Meetings sich exponential verlängert haben. Für die Planung eines zwei Wochen Sprints benötigten wir zwischen 8 und 14 Stunden. Allerdings war das Team mit 10 Mann auch recht  groß.  Das Team wurde daraufhin geteilt und die Sprints auf 1 Woche verkürzt.

Am Ende meines Einsatzes als Entwickler in der Firma kamen wir dem Fakey-Fakey von Kane sehr gut nahe und hatten damit das Ideale Burndown erreicht. Dies zum einen dadurch, dass wir die Anwedung, an der wir Programmiert haben, recht genau kannten und weil wir den Lernaufwand einzelner Mitglieder des Teams durch gutes abschätzen abfangen konnten.

Der Fakey-Fakey ist also nicht unbedingt ein Betrug.

Scrumology.com

Ich folge jetzt dem Blog von Kane Mar, der als Trainer für Agile Softwareentwicklung arbeitet. Ich selber habe Agile Softwareentwicklung bei einem Projekteinsatz in Berlin kennen gelernt und  finde es einen sehr schönen Ansatz.

Warum verwendet man SCRUM?

Scrum

  • steigert die Produktivität des Teams
  • erhöht die Übersicht über das Projekt
  • hilft, Störungen vom Team fern zu halten

Ich werde demnächst sicher mehr darüber schreiben.

 

Ekumo

Diese Woche endet für mich mein Projekt bei Ekumo in Berlin. Ich war jetzt 4 Monate und zwei Wochen hier im Projekteinsatz und habe dabei viel gelernt. Zum einen haben wir hier nach der SCRUM Methodik gearbeitet, zum anderen sind wir sehr tief in PHP eingestiegen. Ich will hier ein Kurzes Fazit über meine Arbeit geben.

Als ich in das Team von Ekumo kam, hatte ich noch nie mit SCRUM gearbeitet. Da ich aber bereits während des Studiums als Gruppenleiter und Tutor Erfahrungen mit der Moderation von Arbeitsgruppen gesammelt hatte, kamen mir viele der Ansätze vom Scrum bekannt vor. Da ist zum einen das Visualisieren der Gruppenarbeit, zum anderen das Moderieren der Team-Meetings.

An der Uni hatten wir bei einigen Arbeitsgruppen zum Visualisieren der Arbeitsergebnisse das Metaplanning verwendet, und so das Arbeitsergebnis als Tapete an der Wand hängen. Beim Scrum wurden die Tasks, auf die wir uns commitet hatten mit Postits an die Wand in „to be done“ gehängt, um dann über „in progress“  auf „done“ geklebt zu werden. Dadurch war das Team und die Product Owner stets über den Fortschritt der Gruppe im Bilde. Die zweite Visualisierung beim SCRUM ist der Burn-Down-Chart, der gibt einen Überblick darüber, wie viel der zu erledigenden Arbeit tatsächlich erledigt wurde.

Beim Dayli Scrum galt die Regel: Fasse dich kurz. Erzähle, was du gestern gemacht hast, was du heute machen wirst und was dich gestern an der Arbeit gehindert hat. Da das Meeting nur 10 – 15 Minuten dauern soll, kann man jede dieser Fragen nur mit einem kurzen Statement beantworten.

Ausführliche Statements hingegen sollten bei den Sprint Planungs-meetings und der Sprint Retrospektive abgegeben werden. Das ist der Platz um sich im Detail zu äußern.

Meine Erfahrungen mit SCRUM sind durchaus positiv.