Wenn der interessierte Anwender ein Scrum-Buch in die Hand nimmt und sich über das Thema informiert, so wird er doch in den meisten Fällen zu der Erkenntnis kommen, dass es ja eine total einfache und sinnvolle Methodik ist. Dem Entwickler bietet sie viele Freiheiten, dem Auftraggeber eine Lösung, die ganz seinen Wünschen entspricht. Warum funktioniert es dann doch nicht immer mit Scrum?
Der Product Owner beschreibt in Umgangssprache, welche Features er haben möchte, die Entwickler können - ganz im Sinne ihrer Tätigkeitsbeschreibung - absolut selbstorganisiert die Umsetzung konzipieren und letztendlich erstellen. Dennoch kommen scheinbar nicht alle mit dieser Arbeitsweise gut klar. Warum ist das so, und warum ist es dann doch so schwer, das an sich einfache Regelwerk von Scrum praktisch umzusetzen und erfolgreich in einem Team zu implementieren?
Zwei Faktoren sind es, die der Implementierung der Methodik im Wege stehen und meiner Meinung nach stark zusammenhängen. Der eine Faktor ist die Bequemlichkeit, der andere die Intransparenz der Arbeit. Was aber kann an Scrum unbequem sein, so dass die Einführung passiv oder aktiv boykottiert wird?
Stellen wir uns eine „klassische“ Entwicklungsumgebung vor. Der Produktmanager möchte ein Leistungsmerkmal haben, ohne genau zu beschreiben, was wirklich gewünscht ist. Er hat nur eine ungefähre Idee in seinem Kopf und teilt diese mehr oder weniger genau mit. Der Entwickler nimmt diesen Wunsch dankbar an und beginnt nun mit der Implementierung. Er kann seiner Phantasie freien Lauf lassen und mal hier mal dort etwas programmieren, da ja nichts wirklich vorgegeben ist außer einer vagen Umschreibung. Aus seiner Bequemlichkeitszone heraus kann er sich die interessanten Aufgabenbereiche heraus picken und daran fast beliebig lange arbeiten. Denn, was nicht spezifiziert ist, kann auch nie wirklich fertig sein. Dem Produktmanager wird irgendwann eine Lösung präsentiert. Dieser, froh darüber, dass sich jemand (und nicht er selbst) Gedanken über sein Feature gemacht hat, nickt das Werk im schlimmsten Fall einfach nur ab und beide sind glücklich.
Das Ganze kann dann ewig so weiter gehen. Beide haben es bequem und arbeiten stark undurchsichtig: Der Entwickler, weil er ständig beschäftigt ist und irgendetwas macht; Der Produktmanager, weil man nicht genau weiß, wie das Gesamtkonzept ist. Kommt die Deadline näher, werden einfach einige Überstunden eingelegt und etwas produziert.
Mit Scrum bekommen beide oben beschriebenen Rollen einige Probleme: Der Produktmanager muss sich nun stärker mit dem zu produzierenden Paket befassen und ein Feature-Backlog erstellen. Mehr noch, er muss die groben Wünsche und Gedanken in feingranulare Stories zerlegen und sich auch Abnahmekriterien überlegen. Er muss, basierend auf den Backlog-Elementen, einen Releaseplan erstellen und in jeder Iteration Anpassungen vornehmen und umpriorisieren, um diesen auch einhalten zu können.
Der Entwickler wiederum bekommt nun mehre Backlog-Elemente in Form von mehreren Userstories vor die Nase gesetzt. Diese Anzahl dieser Elemente in der Iteration hängt jetzt von seiner Komplexitätsschätzung ab und er hat einen festen Termin für ihre Fertigstellung - nämlich das Sprintende. Zwar hat er alle Freiheiten bei der Konzeption und Umsetzung. Aber nur solange, wie damit die fest vorgegebenen Abnahmekriterien erfüllt werden - und das Sprintende ist stets greifbar nahe.
Beide Personen müssen nun also ihre undurchsichtige Zone der Bequemlichkeit verlassen und ordentliche Ergebnisse vorweisen. Beim Produktmanager (Product Owner) ist das ein entsprechend gefülltes und ausgearbeitetes Backlog. Er kann nicht mehr die letzten Feinheiten der Story dem Entwickler überlassen, weil dieser eine so vage definierte Userstory nicht schätzen kann und somit ablehnt. Der Entwickler schuldet wiederum ein Leistungsmerkmal, das genau den Akzeptanzkriterien entspricht und vom Product Owner auch penibel abgenommen wird. Wegen der begrenzten Sprintlänge, kann er nun nicht mehr noch hier und da etwas "schrauben" sondern muss den Zeitplan einhalten. Denn davon hängt der Releaseplan des Produkt Owners ab.
Die beiden aus dieser Zone zu bewegen, ist die undankbare Aufgabe des ScrumMasters, die lang und mühevoll sein kann und viel Überzeugungsarbeit notwendig macht. Freunde macht sich der ScrumMaster damit erst einmal nicht. Oft möchten die Leute ihre bequemen Zonen nicht oder nur sehr ungern verlassen und stellen sich daher bei der Implementierung von Scrum quer.
Zumindest kann man aber schon früh feststellen, dass auch hier Scrum erfolgreich ist, weil es diesen Missstand schonungslos aufzudecken vermag. Und genau das ist es, was die Arbeit des ScrumMasters so spannend macht. Diese Herausforderung nehmen wir nur zu gerne an!
Wie man die beiden Scrum-Team-Mitgleider wieder auf Kurs bringen kann, ist eine andere Geschichte.