Bei InterFace haben wir ein Forum für den Austausch aller an Scrum interessierten Kollegen:
Die Scrum-Sprechstunde.
Hier diskutieren wir über verschiedene Themen im Umfeld von Scrum – wie beispielsweise die Skalierung von Scrum, Scrum im Management oder Scrum im Alltag der Berater – um nur einige zu nennen. Ganz oft geht es aber auch um die grundlegenden Fragen zum Verständnis von Scrum.
Ich werde hier in loser Folge ausgewählte Themen aus diesen Scrum-Sprechstunden zusammenfassen und zur weiteren Diskussion stellen.
Heute mache ich den Anfang mit dem Nokia-Test.
Ich habe schon öfters Dikussionen erlebt, in denen sinngemäß die Frage „Wir machen in unserem Projekt aber XYZ – Ist das denn noch Scrum?“ oder Aussagen wie „Ohne XYZ kann das gar kein echtes Scrum sein.“ gefallen sind.
Im Internet kann man dazu so einige Checklisten finden. Ich möchte hier kurz eine Liste von Fragen vorstellen, die Nokia verwendet, um seine Projekte auf die Anwesenheit von iterativen Verfahren und Scrum zu testen (Gefunden habe ich das ganze hier).
Damit Ihr da nicht selbst nachlesen müsst schreibe ich sie auch hier auf:
Der Test besteht aus zwei Teilen. Der erste Teil testet die „Iterativität“ des Vorgehens:
- Iterationen haben eine feste Länge von nicht mehr als vier Wochen.
- Die am Ende jeder Iteration ausgelieferte Software ist getestet und für den Kunden funktionsfähig.
- Die Iteration startet bevor die Spezifikation komplett ist.
Der zweite Teil testet, ob das Vorgehen Scrum entspricht (nach Nokia-Maßstäben):
- Du kennst den ProductOwner
- Es gibt ein nach Geschäftswert priorisiertes Product-Backlog
- Die Einträge des Product Backlog sind vom Team beschätzt
- Das Team erstellt Burndown Charts und kennt seine Entwicklungsgeschwindigkeit (Velocity)
- Es gibt keine Projektmanager (oder sonstjemanden), der die Arbeit des Teams stört.
Ein solcher Test eignet sich sicherlich gut, um CowboyAgile von Scrum zu unterscheiden. Allerdings wird es gerade in der Einführungsphase von Scrum häufig Abweichungen davon geben. Trotzdem ist es immer wieder hilfreich mit Hilfe solcher „externen“ Benchmarks die eigenen Vorgehensweisen (und vermeintlich nicht zu verändernden Rahmenbedingungen) zu hinterfragen.
Soweit zum ersten (zugegebenermaßen kleinen) Thema aus der Scrum-Sprechstunde. Das nächste Mal werde ich die verschiedenen Rollen in Scrum beleuchten.
AXM
Wird geladen ...
