Projektmanagement ist heute entweder klassisch Wasserfall oder modern agil. Das klassische Vorgehen gehorcht der Logik eines Brückenbaus. Es ist wenig spektakulär, doch viele Projekte scheitern, sprengen das Budget, den Zeitplan oder alles zusammen. Das Project Management Institute nennt nicht weniger als 47 Prozesse, die ein Projekt ausmachen.

Die klassische Methode verliert dabei oft das eigentliche Projektergebnis aus den Augen und wendet sich unwichtigen Nebenschauplätzen zu. Als Reaktion darauf entstanden agile Vorgehen. Die Grundlage sind erstens ihre Werte, zweitens das Manifest und drittens zwölf Prinzipien. Da sich keine Software-Entwicklungsmethode aus Werten, einem Manifest oder Prinzipien basteln lässt, ist mit der Zeit eine Liste an Praktiken (zum Beispiel Pair Programming), Rollen (etwa Scrum Master) und einigen neuen Bezeichnungen (Story Points, Poker-Schätzen) entstanden. Sie haben allein das Ziel, die agilen Methoden besser zu verkaufen.

Der agile Entwickler kann die Praktiken nach Wunsch zusammenstellen. So entstehen Dutzende agiler Methoden. Sie verlagern den Projektschwerpunkt hin zur Kommunikation und rücken die Menschen in den Mittelpunkt. Das Projektergebnis als Ziel der Arbeit wird in den agilen Methoden jedoch nicht berücksichtigt – stattdessen zum Beispiel Meetings.

In der Praxis zeigt sich aber, dass das Schreiben von Software anders ist als der Brückenbau. Ein Grund ist, dass Software abstrakter ist als eine Brücke. Der Kunde kann sich die Brücke viel plastischer vorstellen als das Programm zur Ampelsteuerung vor der Brücke. Um die Brücke zu bauen, ist eine klassische Methode gut. Doch ist eine agile Methode gut genug, um die Ampel-Software damit zu erstellen?

Viele Jahre Praxiserfahrung führten zum Hervorbringen eines neues Vorgehens zur Software-Entwicklung. Mit Blick auf die Mängel sowohl der klassischen als auch der agilen Methoden sowie die Schwierigkeiten, die aus der Abstrak­tion der Software-Entwicklung entstehen, ist die FlePA-Methode entstanden. FlePA steht für «Flexibles Planen und Arbeiten». Der Schwerpunkt liegt nicht auf bestimmten Praktiken oder gar der Produktion von Dokumenten, sondern fokussiert das Projektergebnis. Nebenprodukte sollen Nebenprodukte bleiben, etwa die Dokumentation, und Nebenschauplätze nur Nebenschauplätze, etwa Meetings.

Die FlePA-Methode setzt sich mit den drei Gegenständen auseinander, die ein Projekt ausmachen:

Es ist das Ergebnis einer (Engineering-)Leistung. Dieses soll so genau wie möglich beschrieben vorliegen, nicht nur aus Sicht der Architektur und des Designs, auch im Hinblick auf Funktionalität und Qualitätsansprüche.

Das zu erstellende Produkt wird sowohl als ein Ganzes als auch in Teilen betrachtet und analysiert, Funktionen und Tests werden definiert, Kosten, Ressourcen und Zeiten geschätzt. Doch soll die Planung modifizierbar sein (klassisches Wunschdenken) oder auch ignoriert werden (agile Leichtfertigkeit).

Für das Team sollte ein Rahmen angewendet werden, der auf dem erweiterten «magischen Dreieck» des Projektmanagements basiert. Dieses Dreieck, bestehend aus den Parametern Funktionalität, Kosten und Zeit, wird durch das Kriterium Qualität zu einem Viereck des Projektmanagements erweitert. Die Interaktionen zwischen den Teammitgliedern werden durch diesen Rahmen definiert. Auch muss der Rahmen an die wirkliche Teamgrösse und das Können und Wissen der Mitglieder adaptiert werden.

Die Teammitglieder besetzen Rollen, etwa die des Projektleiters, und führen Funktionen aus. Dies kann beispielsweise die Schnittstelle zu anderen Teams sein. Es ist Unfug, wenn das ganze Team – am besten noch täglich – mit dem Kunden kommuniziert. Diese Aufgabe wird vom Kundenkommunikator übernommen. Der Funktion können eine oder mehrere Personen zugeordnet sein, wobei es gilt, die Gruppe so klein wie möglich und so gross wie nötig zu halten.

Je nach Grösse des Teams werden einige Rollen und zudem mehrere Funktionen definiert. So kann zum Beispiel ein Team von drei Mitarbeitern vier Rollen und zwölf Funktionen innehaben. Anforderungsmanager- und Projektleiterrollen können in diesem Fall von einer Person ausgeübt werden.

FlePA hat nur zwei Prozessblöcke: Planen und Arbeiten. Ein Projekt braucht Planung, handelt es sich doch um eine neue Entwicklung. Doch gerade weil das Ergebnis neu ist, muss diese Planung mögliche Änderungen mitberücksichtigen, die so gut wie sicher vorkommen werden – deswegen flexibles Planen. Was zu dieser Planung alles gehört, muss von Projekt zu Projekt einzeln festgestellt werden. Für ein Projekt kann das Design des GUI ausreichend sein, für ein anderes Projekt kann von der Architektur bis zur Wartung für zwanzig Jahre geplant werden müssen. Wenn sich etwas ändert, so sind diese Änderungen als Störgrössen in einem Regelkreis zu sehen.

Sie müssen durch eine Rückkopplung wieder einen Planungsprozess anstossen. Genauso ist auch die Arbeit als Teil eines Regelkreises zu betrachten. Beispiele für Störgrössen sind in diesem Fall Mitarbeiter, die das Team verlassen und anschliessend ersetzt werden müssen, oder etwa Arbeitsmittel, die ausfallen.

Ein Beispiel illustriert die Funktionsweise von FlePA. Dabei wird bewusst ein Projekt in Schieflage gewählt. Zur Vorgeschichte: Das erste Projekt wurde klassisch durchgeführt und scheiterte. Das Unternehmen musste tief in die Tasche greifen und konnte es sich nicht leisten, den zweiten Anlauf zu vermasseln. Es wurde entschieden, Scrum zu verwenden. Dafür wurden Berater beauftragt und es wurde ein aggressiver Zeitplan lanciert. Drei Scrum-Teams arbeiteten nun an dem System. Nach sechs Monaten wurden die Defizite offensichtlich:

Jedoch war die Firma gezwungen, das zweite Projekt ordentlich zu Ende zu führen – ein drittes kam nicht infrage. Was konnte sie tun? Die sicherste Lösung hiess FlePA: Die Scrum Master wurden nach Hause geschickt. Der Product Owner wurde zum Kundenkommunikator. Alle Meetings und anderen Scrum-Rituale wurden abgeschafft. Nach einer zweiwöchigen Bestandsaufnahme wurden die brauchbaren Teile der geschriebenen Software in Module zerteilt und die Verantwortung über die einzelnen Module jeweils unter den Entwicklern aufgeteilt.

Die Probleme, die bei anderen Software-Teilen auftraten, wurden verallgemeinert und zu neuen Stories aufgearbeitet. Rollen und Funktionen wurden definiert und unter den Teammitgliedern verteilt. Durch das Verantwortungsprinzip war jeder der Entwickler zuständig für sein Modul – und zwar in seiner Funktion als Modul-Meister und nicht durch sogenannte Story Points angetrieben.

Nach Ende der initialen zwei Wochen wurden noch etwa elf Wochen benötigt, um dem Kunden eine halbwegs saubere Software zu präsentieren. Etwa sechs Monate später konnte man dem Auftraggeber die erste Version eines funktionsfähigen Systems liefern. Die Entwicklungszeit wurde so kurz, weil die Teams schon lange zusammengearbeitet hatten und grosse Teile der Software bereits geschrieben waren – wenngleich in einer Form, die die Mitarbeiter selbst als «Spaghetti-Code» bezeich­neten.

Natürlich hatte man zuvor unter Scrum auch Sprints gehabt, die dazu dienten, Ordnung in das Chaos zu bringen. Sie hatten allerdings das Ziel, die Software zu verbessern (zu debuggen) und nicht, sie ganz neu zu schreiben. Somit blieb die Unsauberkeit des Systems grundsätzlich erhalten, was zum Scheitern führte.

FlePA – ohne die vielen Zwänge unflexibler Praktiken – konnte voll und ganz auf das zu erstellende System fokus­sieren.