Sprinten Sie schon, oder flüchten Sie noch?

Viele Entwickler wissen die Vorteile agiler Vorgehensweisen zu schätzen – doch es gibt auch eine große Zahl kritischer Stimmen. Die Stimmen derer, die von Schlagworten wie “agile”, “Scrum” oder “Sprints” rein gar nichts halten. Ich räume ein, dass agile Entwicklung nicht für jedes Projekt geeignet ist. Doch ich möchte in diesem Blog einem ganz anderen Phänomen auf den Grund gehen, welches die agile Entwicklung oftmals in schlechtem Licht dastehen lässt.

Die folgende Situation kommt Ihnen vielleicht vertraut vor:

Sie sind Teil eines Entwicklungsteams in einem großen Unternehmen, welches alles andere als agil vorgeht. Requirements Engineering ist stark prozessgetrieben und ausführlichst dokumentiert. Der Großteil ihrer Kollegen praktiziert die “guten, alten” Methoden schon seit vielen Jahren. Doch auch Ihr Unternehmen bleibt von aktuellen Trends nicht verschont. In unserem Fall lautet der Trend “Scrum”.

Scrum als Framework einzuführen, bedeutet in der Regel einen großen Umbruch. Strukturen müssen aufgelöst werden, die Releaseplanung wird auf links gekrempelt und ausufernde Spezifikationen werden auf das minimal notwendige zusammengeschrumpft.

Aber kommen wir zu unserem Beispiel zurück. Meist ist es ein Mitarbeiter, zum Beispiel der Prozessverantwortliche, der vorangeht, und dieser steht einem eingespielten, aber auch kaum zu Änderungen bereiten Team gegenüber. Sein Scrum-Wissen ist nicht allzu tief, und ihm fällt die undankbare Aufgabe zu, sein Team von den Vorzügen der neuen Methode zu überzeugen. Er lädt zu einem gemeinsamen „Scrum Kick Off Meeting“ ein.

Gemeinsam wird der Scrum Guide durchgelesen, Google liefert schnell eine Grafik, die den Prozess veranschaulicht.

Widmen wir uns zunächst den beteiligten Personen. Ein Scrum Master wird benötigt – da bietet sich der Prozessverantwortliche doch geradezu an! Schließlich ist er sowieso der einzige, der überhaupt ein kleines Verständnis dieser neumodischen Methode hat, und scheinbar irgendwelche Vorzüge sieht. Weiter geht’s mit dem Product Owner. Kurz wird der einzige heute anwesende Projektleiter begutachtet, und die Entscheidung fällt leicht: Der bisherige Projektleiter heißt ab sofort Product Owner. Und das Team? Selbstverständlich gab es bereits vor der Einführung von Scrum eine Abteilung, hier muss also Gott sei Dank nichts geändert werden. Puh, der erste Schritt wäre geschafft – alle Projektbeteiligten sind plötzlich „agil“ und haben wichtig klingende, neue Rollenbezeichnungen.

Widmen wir uns den Artefakten. Scrum verlangt ein sogenanntes Product Backlog. Dieses soll alle Anforderungen des zu entwickelnden Produkts enthalten. Die Kollegen stellen schnell fest, dass Anforderungen reichlich vorhanden sind. Die Gesamtheit aller DOORS-Module, beachtliche 10.000 Anforderungen stark, wird zum Product Backlog erklärt. Scheinbar fordert Scrum nun ein Sprint Backlog, welches all diejenigen Anforderungen enthält, die im nächsten Sprint umgesetzt werden sollen. Man einigt sich schnell darauf, dass ganz pragmatisch zuerst diejenigen Anforderungen umgesetzt werden, die zuerst erstellt wurden. First in, first out. Welches Artefakt fehlt noch? Ein Burn Down Chart? Braucht das Team nicht, Metriken hat es zur Genüge.

Halbzeit, fast geschafft. Alle Kollegen sind nun agil, alle von Scrum geforderten Artefakte liegen ebenfalls vor. Gar nicht so schwer, so eine Transition!

Die Meetingrunde möchte bald die Mittagspause einläuten, schauen wir uns also noch schnell die von Scrum geforderten Events an. Das Sprint Planning Meeting wird im Sinne der Agilität gestrichen – schließlich wurde erst vor wenigen Minuten die Einigung getroffen, einfach die zuerst erstellten Anforderungen auch zuerst zu entwickeln. Die Aufregung um das Konzept des „Sprintens“ verstehen die Kollegen nicht. „Wir haben doch alle vier Monate einen Software Release! Reicht das nicht?“ fragt ein skeptischer Softwareentwickler. Vorhandene Konzepte umzuwerfen erzeugt nur Aufwand, Unruhe und Stress. Der „Vier-Monats-Sprint“ wird beschlossen. Vorgesehen wäre nun das sogenannte Daily Meeting. Erleichtert stellen alle Kollegen fest, dass jeder von ihnen gern Kaffee trinkt – ein Austausch der Kollegen findet also doch am Kaffeevollautomaten sowieso statt! Und Retrospektiven? Hierfür bieten sich die jährlichen Mitarbeitergespräche geradezu an – hier kann jeder all seine Sorgen loswerden. Es fehlt nur noch ein einziges Event zur vollkommenen Agilität: das Sprint Review. Reviews werden sowieso „immer mal wieder“ durchgeführt. Das daran kaum jemand teilnimmt, stört niemanden. Die Kollegen werden unruhig, das Meeting wurde schließlich bereits um fünf Minuten überzogen.

Aber nun haben wir es geschafft! Alle Kollegen sind agil, alle Artefakte und Events sowieso schon vorhanden. Das Unternehmen arbeitet fortan agil – und es ist noch nicht einmal Mittag!

Zugegeben, diese Anekdote ist etwas überspitzt. Aber seien Sie ehrlich, erkennen Sie in meinen Schilderungen ihr eigenes Unternehmen nicht zumindest teilweise wieder?

Dieses oftmals praktizierte Vorgehen birgt eine große Gefahr. Wenn kaum jemand fundiertes Wissen besitzt, wie eine agile Transition durchgeführt werden sollte, und auch kaum Verständnis für Scrum als Methode an sich besteht, wird der Begriff „Agile Entwicklung“ verbrannt. Es wird genauso weitergearbeitet wie zuvor, die erhofften Erfolge stellen sich nicht ein. Die ganze Unruhe um Scrum und agile Entwicklung hat nur für Ärger gesorgt, und die Projektbeteiligten kommen schnell zu dem Schluss, dass sie vorher besser dran waren. Wird das Thema Jahre später erneut angesprochen, winken die Kollegen ab und erwidern nur „Kennen wir schon, hat nicht funktioniert.“

Ich hoffe, ich konnte Sie darauf sensibilisieren, wie wichtig eine, mit Bedacht und Wissen durchgeführte, agile Transition ist. Ja, sie wird Aufwand erzeugen und ja, es wird auch nicht alles von Anfang an rund laufen. Aber glauben Sie mir, in nicht allzu ferner Zukunft werden auch Sie profitieren!

Marcel Klein

Kontaktieren Sie Marcel Klein

Marcel Klein arbeitet bei der HOOD GmbH als Consultant und als Trainer im Bereich Requirements Engineering. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehöriger Werkzeuge (z.B. DOORS). Zu seinen Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, die Prozessverbesserung sowie die Erstellung von objektorientierten Modellen. Als Trainer hat er sich vor allem auf die gute Formulierung textueller Anforderungen und die nachhaltige Etablierung von Requirements Engineering in einem Unternehmen spezialisiert. Er veröffentlicht regelmäßig zu beiden Themen Artikel und Blogs.