Autorin: Anne Kramer
Zeichnen Sie noch gelegentlich GanttCharts? Dann sollten Sie darauf achten, dies nicht in Gegenwart von “Agilisten” zu sagen. Denn die glühenden Verfechter von Scrum & Co verteidigen ihre Überzeugungen teilweise mit religiösem Eifer.
Es hat schon fast etwas von Glaubenskrieg. Auf der einen Seite die alte “katholische” Kirche, die an bewährten Traditionen festhält, jedoch von vielen als nicht mehr zeitgemäß empfunden wird. Auf der anderen Seite die “Reformierten”, ohne zentrale Instanz wie den Papst (bzw. dem Projektmanager), die sich verstärkt auf die grundlegenden Werte berufen (Kundenzufriedenheit, lauffähige Software).
Dabei gibt es so viele, schöne Vorgehensmodelle jenseits von Wasserfall, V-Modell und Scrum. Wenn die Koordination in Sprints nicht wichtig oder nicht möglich ist, bietet sich z.B. Kanban an. Kanban setzt wie Scrum auf gute Praktiken wie die Eigenverantwortung des Teams, Visualisierung, kontinuierliche Verbesserung und schnelles Feedback. Ich persönlich bin ein großer Fan von Kanban. Hier möchte ich drei weitere Vorgehensmodelle vorstellen, deren Namen Ihnen vermutlich nicht geläufig sein werden, die Ihnen jedoch erschreckend bekannt vorkommen werden.
MURCS
MURCS ist heutzutage eines der am weitesten verbreiteten Vorgehensmodelle – nur dass es niemand so nennt. MURCS entspricht SCRUM, nur halt verkehrt herum. MURCS erkennt man an folgenden Praktiken:
- Vermeide es, während der Projektarbeit zu dokumentieren. Erstelle stattdessen eine
komplette Nachdokumentation am Ende des Projekts. - Benenne einen Product Owner (m/w/d), der möglichst wenig verfügbar ist.
- Ändere mindestens einmal innerhalb eines Sprints die Prioritäten.
- Ignoriere die Definition of Ready.
- Vernachlässige Architektur und Systemtest.
Fortgeschrittene Anwender von MURCS schaffen es sogar, den Inhalt vergangener Sprints zu ändern. Dies erfordert allerdings einige Übung. MURCS hat den Vorteil, ohne viele
Werkzeuge auszukommen. Es ist lediglich ein analoges oder digitales TaskBoard nötig, um die Analogie zu Scrum zu schaffen. Entwickler setzen zudem meist ein Konfigurationsmanagementsystem durch. Ansonsten benötigt MURCS weder Besprechungszimmer noch Dokumentenmanagement.
Meeting-Driven Development (MDD)
Meeting-Driven Development eignet sich besonders für Projekte im TaskForce-Modus. Die Grundidee besteht darin, den ganzen Tag von früh bis spät in Besprechungen zu verbringen. Die Hälfte der Besprechungen sollte darauf ausgerichtet sein, Beschlüsse zur zukünftigen Vorgehensweise zu fassen. Die andere Hälfte dient der Rechtfertigung, warum diese Beschlüsse nicht umgesetzt wurden (z.B., weil man den ganzen Tag in Besprechungen saß). Für MDD gelten folgende Praktiken:
- Benenne mindestens einen Task-ForceManager, einen Projektmanager und mehrere Teilprojekt-Manager, um eine hinreichende Anzahl an Besprechungsteilnehmern zu haben.
- Pflastere den Kalender dieser Kollegen lückenlos mit Besprechungen zu.
- Bringe in jede Besprechung den Laptop mit, um parallel E-Mails checken zu können und
im Chat-Programm online zu sein.
MDD erfordert vergleichsweise viele Werkzeuge. Zur minimalen Ausstattung gehören:
- ein Gruppenkalender, z.B. in Outlook oder Lotus Notes
- ein E-Mail-Programm, um zur Besprechung einzuladen und die Beschlüsse zu kommunizieren
- ein Chat-Programm, um während der Besprechung andere zu beschäftigen
- VOIP, um auch standortübergreifend Besprechungen durchführen zu können.
Bei guter digitaler Ausstattung lässt sich MDD auch ohne Besprechungszimmer einsetzen. Ansonsten eignen sich besonders Besprechungszimmer ohne Fenster.
Order & Obey Process Model (OOPM)
Das Order & Obey Process Model gilt als veraltet, ist jedoch noch überraschend häufig anzutreffen. Angelehnt an militärische Befehlsstrukturen werden Aufgaben als direkte Anweisungen verteilt. Zum Schutz der Mitarbeiter werden Detail-Informationen und längerfristige Pläne möglichst wenig offengelegt. Dies ermöglicht maximalen Einsatz der Mitarbeiter. Denn wo wäre Deutschland heute, wenn die amerikanischen Soldaten vorher gewusst hätten, was sie an der normannischen Küste erwartet? Folgende gute Praktiken gelten für das Order & Obey Process Model:
- Schaffe klare Hierarchien. Der Projektmanager ist dem Testmanager, der Testmanager dem Dienstleister und der Projektmanager beim Dienstleister dem Mitarbeiter des Dienstleisters vorgesetzt.
- Benenne pro Standort einen Ansprechpartner, den man bei Bedarf „erschießen“
kann. - Sorge dafür, dass immer eine Order ausgegeben wird. Wenn es nichts Sinnvolles zu tun gibt, ordne Unsinn an.
- Unterbinde eigenständiges Denken der Mitarbeiter.
Hinsichtlich der erforderlichen Werkzeuge ähneln sich OOPM und MDD. Da wenig diskutiert wird und keine Absprachen erforderlich sind, kommt OOPM gut ohne Besprechungszimmer aus.
Hybride Modelle
MDD lässt sich ideal mit Kanban verbinden. In der ersten, morgendlichen Besprechung werden die Aufgaben des Tages festgelegt, die sich das Teams dann selbst bestimmt im Verlauf des Tages ziehen kann. In der letzten Besprechung am Abend des gleichen Tages wird das Kanban-Board analysiert und diskutiert, warum die Zettel noch immer in der Spalte “In Work” stehen.
MDD und OOPM harmonieren weniger gut, da sie von der Grundidee zu verschieden sind. Während im Meeting-Driven Development alles in Besprechungen ausdiskutiert wird, sind solche Diskussionen im Order & Obey Process Model nicht vorgesehen. MURCS ist definitiv das flexibelste Vorgehensmodell und lässt sich mit so ziemlich allem kombinieren. Am bekanntesten ist das Angsthasenmodell, welches V-Modell und Scrum verbindet. Haben Sie Ähnlichkeiten erkannt? Das ist gut, denn Selbsterkenntnis ist der erste Schritt zur Besserung und jede Reise beginnt bekanntlich mit dem ersten Schritt.
