So vereinfacht FlePA das Projektmanagement
FlePA in der Praxis
FlePA: Das Software-Entwicklungsmodell besteht lediglich aus den beiden Prozessblöcken Planen und Arbeiten
- Jeden zweiten bis dritten (zweiwöchigen) Sprint musste man die Architektur des Systems anpassen.
- Es war kaum möglich, die Software zu erweitern, ohne dass woanders etwas nicht mehr funktionierte.
- Die automatischen Tests waren ebenfalls so gut wie nicht zu warten, geschweige denn zu erweitern. Sie wurden weitgehend ignoriert.
- Ohne tagelanges Refactoring war kein Sprint zu realisieren. Weder zum ersten (sehr aggressiven) Termin wurde geliefert, noch zum zweiten. Zwischen beiden Terminen lagen mehrere Monate. Nach über einem Jahr mussten sich die Verantwortlichen eingestehen, dass auch diese Methode nicht funktionierte.
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.
Neue Rollen und Funktionen
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» bezeichneten.
Fazit: Ziel statt Methode
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 fokussieren.
