So wie es aussieht muss ich mich von einem langen Begleiter meiner Scrum Zeit Abschied nehmen:
Goodbye Task Burndown Chart
Wie kommt’s?
Das Task Burndown Chart kann seinen Zweck nur erfüllen, wenn man es schafft zu Beginn des Sprints alle Stories vollständig im Tasks mit einer Dauer von <8h zu zerlegen. Dies ist ein Vorgang der wahrscheinlich zu vielen Diskussionen zwischen Team und Scrum Master führen wird. Selbst wenn man das Team soweit hat, sich von ihren geliebten 5 Tage Tasks zu verabschieden, fällt es sehr schwer im Planning II ein vollständiges Bild der Aufgaben zu erzeugen (ausser man tut gerade Dinge, die man schonmal gemacht hat). Die Folge davon ist, dass Tasks während des Sprints hinzukommen. Diese Tasks führen aber zu einem “Burnup” Chart (und somit entsteht eine psychologische Hemmschwelle, Tasks hinzuzufügen).
Da es mir bedeutend wichtiger ist, dass das Taskboard eine belastbare Arbeitsgrundlage für das Team ist (im Gegensatz zu einem formvollendeten Burndownchart), will ich einen Versuch starten, auf das Task Burndown Char zu verzichten.
Die Aufgabe des “Fortschrittbalkens” übernimmt das Story Burndown Chart (das kann das aus meiner Sicht eh besser).
Heiko Uncategorized
Bildausfall zur Übertragung des Halbfinales… kann es etwas Schlimmeres für Fußballdeutschland geben?
Der Grund: alle Sender sind verpflichtet, die Bilder aus dem Pressezentrum in Wien zu übernehmen – und genau dort kam es zum Problem. Zum Glück hatte das ZDF eine Fallbacklösung und holte sich die Bilder vom Schweizer Fernsehen.
Die Scum Lehre daraus?
Vermeide Single Points of Failures – schaffe Alternativen. Arbeite nicht mit Einzelpersonen (die können krank werden), sondern mit Teams. Verteile das Wissen im Team. Experten sind gut – aber sie brauchen ein Backup. Sonst hängt das Wohl von Großprojekten an einzelnen Personen.
-> Lebt den Teamgedanken von Scrum!
Heiko Uncategorized
Boris war letzt bei uns in der Firma und irgendwie sind wir darauf gekommen, dass ich in meinem Team ideale Personentage nehme und nicht die Storypoints/Sizes. “Das muss ich Euch austreiben”, war sein Kommentar.
Im nächsten Estimation Meeting ergab sich die Situation, dass das Team an einer Schätzung nicht mehr so recht weiterkam. Ich erkannte meine Chance und fragte sie:
ich: “ihr habt doch vorhin Thema A abgeschätzt – das Thema B an dem ihr jetzt hängt ist doch sehr ähnlich. Versucht doch mal zu sagen, um welchen Faktor Thema B größer ist?”
Teammitglied fängt an laut nachzudenken: “hmm… also das ist ähnlich wie Thema A, ja – das stimmt. Aber ich denke da kommen noch 5 PTs hinzu. Das andere waren 10 PTs, oder? Also Faktor 1.5″
Danach stand für mich der Entschluss fest, dass ich ein Team, dessen Mitglieder es gewöhnt sind mit PTs zu schätzen und dies auch gut beherrschen, nicht auf Storypoints und Sizes drillen werde. Bei neuen Teams, werde ich aber auf Storypoints setzen – da ich den abstrakteren Mechanismus Storypoints für sinnvoller halte.
Heiko Uncategorized
Alle drei verweisen auf die psychische Belastung, und tatsächlich musste man während der 90 Minuten den Eindruck haben, dass diese Mannschaft sich so auf Kampf und Einsatz konzentrierte, dass kein Platz blieb im Kopf für überraschende Ideen. Für Intuition. Und Spielspaß.
Spiegel
Ok, in dem Spiegel-Artikel geht es natürlich nicht um die letzte Retro eines Scrum Teams. Aber der Artikel zeigt, woher echter Erfolg kommt: aus Spaß wird Intuition, aus Intuition folgen überraschende Ideen, aus überraschenden Ideen wird Erfolg.
Scrum muss Spaß machen!
Heiko Uncategorized
cause this is a blog response (don’t know if the other blog supports this) this post is in english (or at least something like english):
Joe Little posted some comments on the Nokia Test on the agile consortium blog. There is one thing I’d like to add:
Before going to priorization, your productbacklog must have a vision. A big story behind all the small stories in there. In my daily work I do see a lot of productbacklogs that try to channel the chaotic world out there into some sort of waiting queue. They are prioritized and therefore nokia test compatible. But at the long run, they will fail.
Leaving out a vision, just trying to mechanically sort backlog items will lead you nowhere. It will start with backlog items overflow (cause there is no overall theme of your backlog, everything will fit in there), the priorizations will be challenged due to this overflow and you are likely to prioritize by deadlines only very soon. After all, your team becomes demotivated cause they don’t know where to go – they get lost.
Someone (I forgot who) said: “If you don’t know where you want to go, you might never get there!”
Vision first.
Heiko Uncategorized
