Es ist schwer, an Agilität in Projekten vorbei zu kommen. Sie mag nicht die Silver Bullet für alle Projektprobleme oder der Produktivitätsturbo auf Knopfdruck sein, als die sie vermarktet wurde, kann aber bei erfolgreicher Einführung gerade in der Produktentwicklung langfristig neue Perspektiven für die Projektzusammenarbeit eröffnen. Aus diesem Grund starten wir mit diesem Blogbeitrag eine kleine Serie, die sich mit der Einführung von Agilität im RE befasst.
Wir stellen Ihnen hier einen Ansatz vor, um agiles Requirements Engineering stufenweise in einer Transition vom wasserfallartigen Prozess bis hin zum vollkommen agilen Prozess einzuführen. Das Ziel ist dabei nicht unbedingt, den agilsten Prozess zu erreichen – werden Sie so agil, wie es für Ihre Zwecke sinnvoll ist.
Die Ausgangssituation und die vorherrschenden Rahmenbedingungen haben starken Einfluss darauf, welche Möglichkeiten Ihnen offenstehen, wenn Sie agiler werden wollen. Falls bisher ohne vorgegebenen Prozess gearbeitet wurde und Sie nicht an externe Vorgaben gebunden sind, steht es Ihnen frei, so agil einzusteigen wie Sie möchten. In den meisten Unternehmen existiert jedoch bereits ein (wasserfallartiger) Prozess. Bei Entwicklungstätigkeit im internationalen oder sicherheitskritischen Umfeld kommen oftmals zusätzlich Dokumentations- und Prozessvorschriften hinzu, die einen rein agilen Prozess vielleicht nicht vollkommen ungeeignet, aber zumindest unpassend erscheinen lassen. Doch auch in diesem Fall bestehen Möglichkeiten, den Prozess zumindest teilweise agiler zu gestalten.
Wo ein Ziel ist…
Zunächst sollten Sie sich darüber klar werden, was Sie mit der Einführung von Agilität genau erreichen möchten. Definieren Sie, wie Ihr Ziel in Bezug auf Agilität aussieht und woran Sie merken, dass es erreicht wurde (oder eben nicht). Eine konkrete Festlegung erlaubt es Ihnen auch, den Projektfortschritt z. B. mit geeigneten Metriken zu prüfen und bei Bedarf Anpassungen vorzunehmen.
Abhängig von Ihrem Ziel können Sie festlegen, welche Methode für Ihre Zwecke am passendsten ist. Die verschiedenen agilen Ansätze unterscheiden sich in Bezug auf die Detaillierung (vom Management-Framework bis zur einzelnen Technik), den Umfang der vorhandenen Dokumentation, verfügbare Schulungsangebote, Praxiserprobung und Problemstellungen, für die der agile Ansatz geeignete Lösungen bieten kann. In dieser Blogserie haben wir uns an Scrum orientiert, Informationen zu weiteren Ansätzen bietet unter anderem unsere Blogserie zur Dokumentation in agilen Ansätzen (siehe Quellenangaben).
Pilotprojekte stellen eine Möglichkeit dar, mit neuen Methoden, Prozessen oder Tools in einem vergleichsweise sicheren Umfeld zu experimentieren und Erfahrungen in Bezug auf ihr Potential und ihre Auswirkungen zu sammeln. Bei der Einführung von Agilität kann mit Pilotprojekten auch die Zusammenarbeit mit nicht-agilen Projekten und Abteilungen im Unternehmen getestet werden. Um hinreichend aussagekräftig zu sein, sollte Ihr Pilotprojekt für Agilität zum Tagesgeschäft gehören, aber nicht zu den kritischen Projekten zählen. Die Erfahrungen aus dem Pilotprojekt lassen sich nutzen, um bei Erfolg falls gewünscht das Vorgehen über weitere Projekte unternehmensweit auszurollen.
Sobald Sie also Ihre Ziele festgelegt haben, ist der erste Schritt Richtung Agilität bereits getan. Der zweite Teil der Blogserie befasst sich mit den Personalfragen bei einem Umstieg.
———————————————————-
Teil 2: Mehr Agilität wagen! – Teil 2: Personalfragen
Teil 3: Mehr Agilität wagen! – Teil 3: Wasserfall und Scrum kombinieren
Teil 4: Mehr Agilität wagen! – Teil 4: Die Agilen Zwischenstufen
Teil 5: Mehr Agilität wagen! – Teil 5 : Leichter geht’s nicht
———————————————————-
Quellen:
Blogserie „Dokumentieren in agilen Methoden“:
https://blog.sophist.de/index.php/2013/10/23/dokumentieren-in-agilen-methoden-teil-1-scrum/
https://blog.sophist.de/index.php/2013/11/13/dokumentieren-in-agilen-methoden-teil-4-crystal/