In der Vergangenheit habe ich oft über die Vorteile von Scrum aus Sicht des Teams geschrieben. Aber das ist sozusagen nur die halbe Wahrheit. Ein anderer, wichtiger, Aspekt wird nämlich oftmals übersehen:
Auch für das Management hat Scrum einige handfeste Vorteile!
Dies erscheint auf den ersten Blick schwer vorstellbar. Immerhin setzt Scrum auf sich selbst organisierende Teams. Und diese machen nur das, was sie wollen, ohne das man als Vorgesetzter etwas dagegen tun könnte…
Doch dieser, vermeintlich logische, Schluss ist viel zu kurz gedacht und damit falsch! Richtig ist vielmehr, daß auch bei agilem Vorgehen das Management ein exaktes Reporting existiert, und es über eine Vielzahl an Steuer- und Eingriffsmöglichkeiten verfügt.
Steuerung über Sprints
Die wichtigste Steuermöglichkeit sind die Sprints. Vor Beginn jedes Sprints vereinbaren Management (vertreten durch den Product Owner) und Team ein verbindliches Sprintziel, das es dann zu erreichen gilt. Das Management gibt hierbei die Reihenfolge vor, in der die einzelnen Anforderungen realisiert werden sollen. Das Team wählt sich dann so viele der am höchsten priorisierten Einträge aus, wie es in der folgenden Iteration umsetzen kann. Dann schliessen sie eine Art Vertrag: Das Team verpflichtet sich dazu, die Arbeit, die es sich vorgenommen hat, bis zum Ende des Sprints vollständig zu erledigen. Das Management verpflichtet sich dazu, alles in seiner Macht stehende zu tun, um dem Team den Rücken frei zu halten, damit es in Ruhe arbeiten kann.
Ist der Sprint dann gestartet, so erlauben die Burndown Charts einen tagesaktuellen Blick auf den Stand des Projekts. Hier ist auf einen Blick erkennbar, ob das Team noch im Zeitplan liegt, oder ob das Projekt aus dem Ruder zu laufen droht. Will das Management noch mehr erfahren, so ist es natürlich auch erlaubt, am täglichen Statusmeeting teilzunehmen. Es findet während des gesamten Sprints immer zur selben Zeit am selben Ort statt. Somit ist es mit relativ wenig Aufwand möglich, sich einen Eindruck über den aktuellen Stand der Dinge im Projekt zu verschaffen.
Dadurch eignet sich Scrum übrigens auch für den Einsatz in Umgebungen mit nur wenig Vertrauen zwischen Auftraggeber und Auftragnehmer: Das Team weiß immer genau, woran es ist (d.h. was der Kunde möchte), und der Kunde erhält immer zeitnah eine neue Produktversion, sodass er genau sehen kann, wofür er sein Geld ausgibt.
Oder, um es mit Alistair Cockburn zu sagen (als er mir vom Redesign seiner Webseite erzählt hat):
„That is my vacation money I’m giving to you. I want to know what you’re doing!“
Ein Sprintziel zu verfehlen ist für das Team übrigens keine Banalität, nach der man bald wieder zur Tagesordnung übergeht, sondern eine sehr schwerwiegende Verfehlung, die Konsequenzen nach sich zieht. Das kann z.B. auch eine Änderung in der Zusammensetzung des Projektteams sein.
Ressourcenmanagement
Womit wir bereits bei der zweiten wichtigen Eingriffsmöglichkeit sind: Die Auswahl der Teammitglieder. Die richtige Zusammensetzung eines Teams ist ein entscheidender Erfolgsfaktor. Scrum fordert multifunktionale Teams, d.h. alle Fähigkeiten, die benötigt werden, um das Projekt umzusetzen, müssen im Team vorhanden sein. Dieser Mix an benötigten Fähigkeiten ist jedoch nicht über die gesamte Projektlaufzeit konstant, sondern kann von Phase zu Phase durchaus sehr unterschiedlich sein.
So wird man am Anfang eher mehr mit der Architektur des Systems beschäftigt sein, wogegen zu Ende die Aufmerksamkeit eher auf dem Testen liegt. Dementsprechend wird man auch mal eher mehr Architekten und mal eher mehr Tester benötigen. Dazu kommt, daß bei Scrum Multitasking an sich verboten ist. Es gilt die Regel „Eine Person = ein Projekt“.
Nur in absoluten Ausnahmefällen kann davon abgewichen werden. Wenn man sich dann noch vor Augen führt, daß es im Normalfall nicht nur ein einziges Scrum-Projekt gibt, sondern mehrere, die sich noch dazu in verschiedenen Stadien befinden, wird klar, daß dies keine triviale Aufgabe ist.
Soweit Teil 1 des Artikels. Mehr in Kürze in Teil 2…
BFI
Wird geladen ...
