Scrum@Work

Einer unseren letzten Sprints lief sehr gut. Die Stories waren abgeschlossen und sogar das Storyburndurnchart sah so aus, wie es aussehen sollte (die Stories wurden während des Sprints gleichmäßig abgeschlossen und nicht erst alle gegen Ende am Labday).

Dennoch war die Stimmung im Review etwas gedrückt. Auf Nachfrage stellte sich heraus, dass irgendwie der Fokuswert die Runde gemacht hatte. Dieser Fokuswert war entgegen der Erwartungen des Teams nicht gestiegen und so war man enttäuscht über die eigene Leistung…. dabei lief doch alles so gut.

Ich hatte meine liebe Mühe dem Team zu erklären, dass der Fokuswert keine Aussage über die Leistung des Teams trifft, sondern nur ein Hilfsmittel ist und dass es nicht darum geht, möglichst viele Storypoints pro Personentag abzuarbeiten, sondern möglichst qualitativ hochwertig.

Zu dieser Qualität gehört auch, dass der Fokuswert eine gewisse Stabilität erreicht. Nur dann weiss ich, dass die Abschätzungen und die Arbeit zusammenpassen und nur dann kann ich einfach Informationen aus der Velocity für die Zukunft ableiten.

Nach all diesen Beiträgen bin ich inzwischend er Meinung, dass es wohl besser ist, nur die Velocity zu publizieren und im Planning und bei Reviews rein qualitativ (“denkt daran, 2 Leute sind im Urlaub”) darauf hinzuweisen, dass ein Sprint größer oder kleiner als die anderen Sprints sind.

Heiko Uncategorized

Auch wenn es jetzt etwas widersprüchlich klingen sollte: Ich bin kein großer Fan von Fokus. Ich brauche es, weil die Realität nicht ganz so einfach ist, wie ich Sie gerne hätte. Wer hat eigentlich das Konzept Urlaub erfunden?

Darum sollte das Hilfsmittel Fokus so einfach wie irgendmöglich errechnet werden. Auf keinen Fall sollte man in den Modus verfallen, jede Art von Ausfalltag im Vorraus vorherzusagen. Also z.B. die Nettoarbeitstage durch die Anzahl von Krankheitstagen oder Ähnlichem reduzieren. Oder man könnte die Ausfalltage ja auch noch mit einem Leistungsindex versehen, welches Teammitglied ausfällt.

DON’T DO THIS!

Das führt nur ins Mikromanagement und dazu ist der Wert eh viel zu ungenau. Fokus ist nur ein grober Vorschlagswert, um im Sprint Planning I ein Gefühl dafür zu bekommen, wie groß der nächste Sprint wohl wirklich ist.

Ich versuche derzeit meinen berechneten Fokus gar nicht mehr zu publizieren, sondern benutze Sätze wie: “Ok, der nächste Sprint ist netto 30% kleiner als der letzte. XY und YZ sind 2 Wochen, denkt daran.”

Und als letzter & wichtigster Rat:

FOKUS DARF NICHT VERÖFFENTLICHT WERDEN

Denn dann läuft man Gefahr, dass die Teams anhand Fokuswerte verglichen werden! Etwas schlimmeres kann einem nicht passieren. Warum?

Es gibt einen sehr simplen Weg für das Team, den Fokuswert zu maximieren (und sie werden es tun!):

a) In den Estimation Meetings wird zu hoch abgeschätzt
b) möglichst schnell Stories abschließen (=Qualität opfern)

Voilà, das Unheil nimmt seinen Lauf…

ehrlich gesagt… ich glaub ich schaff den Fokus wieder ab…

Heiko Uncategorized

Velocity ist die Anzahl der Storypoints, die ein Team in einem Sprint abarbeitet. Anhand dieser Velocity kann man theoretisch planen, was das Team in Zukunft wann abarbeiten wird. Wohlgemerkt: theoretisch.

Ohne weitere Mathematik funktioniert das in der Realität nicht so ganz, da die Sprints nur sehr schwierig auf eine identische Länge geplant werden können. Länge in Kalendertagen geht gerade noch, spätestens bei den verfügbaren Personentagen wird es dann schwierig. Insbesondere in der Urlaubszeit (also jetzt) fällt dies besonders stark auf.

Eine Möglichkeit dies zu umgehen, ist die Velocity in Bezug zu den verfügbaren Tagen eines Sprints zu setzen. Also

Fokus = Velocity/(NettoArbeitstage*Teamsize – Urlaubstage)

Mit dieser Zahl kann ich dann auch variable Sprintlängen planen. BTW, NettoArbeitstage gibt es auch als sehr hilfreiche Excel (Microsoft) Funktion.

Soviel zur Grundlage. Demnächst folgen noch diese Themen:

• Zuviel Fokus – wie man es übertreiben kann
• was man mit Fokus auf keinen Fall tun darf!
• Ein seltsamer Fokus Effekt

Heiko Uncategorized

Seth Godin
scheint meinen Blog zu lesen und hat einen sehr interessanten Beitrag zu meinem Eintrag zum Thema Nokia Test und Vision geschrieben:

When you’re done with your email queue, are you done?

Er schreibt, dass wir heute unsere Arbeit auf die Abarbeitung des Posteingangs reduzieren. Ist der Posteingang leer, dann ist man fertig (meist schafft man das heute gar nicht mehr). Er bemängelt, dass wir uns nicht mehr die Zeit nehmen, Eigenes zu initiieren und in die Welt zu tragen.

Das Gleiche sehe ich bei einem Productbacklog ohne Vision. Nur die Abarbeitung von Notwendigkeiten und Projektgegebenheiten oder Katastrophen darf nicht unsere Arbeitszeit ausfüllen.

Um den Beitrag mit den Worten (frei) von Seth abzuschließen:

Sich die Zeit zu nehmen, etwas Neues zu initiieren oder Creativ zu sein, ist wichtiger als jemals zu vor.

Heiko Uncategorized