Ende letzter Woche war ich auf der Konferenz „interPM„. Diese stand unter dem Leitthema „IT-Projektmanagement 2012+ im Spagat zwischen Industrialisierung und Agilität?“.

Was mir dort aufgefallen ist: Vielen Menschen, ich selbst eingeschlossen, ist gar nicht richtig klar, was „agiles“ Projektmanagement eigentlich kennzeichnet, und inwiefern es sich vom „klassischen“ Projektmanagement unterscheidet. Das wird noch verstärkt dadurch, daß es eigentlich auch keine vernünftige Definition für „klassisches“ Projektmanagement gibt.

Eine Abgrenzung ist daher schwierig. Nichtsdestotrotz möchte ich es trotzdem versuchen. Hier also meine ganz persönliche Meinung, was „Agilität“ im Kern eigentlich ausmacht:

1. Timebox statt Feature Box:
   Agile Projekte werden iterativ durchgeführt. Das Projektziel wird hier nicht mit einem grossen Schlag erreicht, sondern nach und nach durch viele kleine Zwischenversionen. Diese Zwischenversionen wiederum sind von fester Länge und daher ausschliesslich über ihre Zeitdauer festgelegt (=Timebox). Auf keinen Fall sind diese Iterationen anforderungsgetrieben („Wenn diese 5 Anforderungen umgesetzt sind, ist die Iteration fertig“)!
2. Kontinuierlicher Verbesserungsprozess:
   In das Projektmanagementmodell sind feste Zyklen der kontinuierlichen Verbesserung verankert. Die besseren agilen Methoden haben gleich 2 solcher Feedbackschleifen eingebaut: Eine über das Projektziel, und eine über das Projektvorgehen. Dank iterativer Durchführung (vorheriger Punkt) fügt sich dies oft sehr gut in das Projekt ein – man passt die Feedback-Zyklen einfach der Iterationslänge an.

Dagegen setzen sich die „Klassiker“ für mich genau in diesen Punkten ab. Beide diese Punkte sind hier nämlich optional:

• Timeboxing findet nicht statt. Stattdessen basieren Iterationen (bzw. „Leistungsstufen“) oft auf anforderungsgetriebenen Meilensteinen. Die Leistungsstufe ist also genau dann fertig, wenn alle damit verbundenen Anforderungen umgesetzt sind.
• Geschlossene Feedbackzyklen sind nicht fest in das Modell eingebaut. Wenn, dann werden sie nachträglich hinzugefügt (in der Realität leider immer noch nicht oft genug).

Wenn ich mir diese Punkte recht überlege, so wird mir übrigens klar, daß Kanban für mich auch eher einen Grenzfall darstellt:

• Iteratives Vorgehen ist hier rein optional. Es ist genausogut möglich, anforderungsgetrieben zu arbeiten. Bei Kanban überlegt man sich hier in der Regel ein „Minimum Marketable Feature Set“. Das sind genau so viele Anforderungen wie nötig, um das Produkt verkaufen zu können. Zwar ist dies i.d.R. weit weniger als bei konventioneller Meilensteinplanung, aber nichtsdestotrotz immer noch anforderungsgetrieben.
• Selbst auf den kontinuierlichen Verbesserungsprozess kann man verzichten, auch wenn es so natürlich nicht gedacht ist.

Daher ist Kanban für mich eigentlich von Haus aus keine agile Methode. Man kann es natürlich dementsprechend implementieren, notwendig ist dies jedoch nicht. Ist das nun schlimm? Selbstverständlich nicht!

Jede Methode ist mit ihren eigenen Vor- und Nachteilen verbunden und eignet sich mal mehr, mal weniger für ein konkretes Projekt.

Die Kunst ist, über einen entsprechend grossen Methodenbaukasten zu verfügen und sich für die Richtige zu entscheiden.

Es gilt zu vermeiden, was das folgende Sprichwort sehr schön ausdrückt:

„Für einen Menschen mit einem Hammer ist die ganze Welt voller Nägel“!

BFI