Spätestens seit dem Agilen Manifest gehört es in der Softwareentwicklung zum guten Ton agil zu sein. Die Argumente sind charmant: Nur das tun, was wirklich notwendig ist, nur dann wenn es wirklich notwendig ist. Nicht mehr Dokumente als unbedingt nötig.

Andererseits hat die klassische Netzplantechink durchaus etwas für sich. Der Argumentation: Wenn A von B abhängt, kann ich erst mit A beginnen, wenn B abgeschlossen ist, leuchtet ein. Und so mancher Vertreter der Agilen Methoden verwechselt wohl agil mit chaotisch.

Leute die Worte wie Agil, Iterativ und Inkrementell nutzen, aber nicht erklären können machen die Sache auch nicht besser.

Ich habe jemanden gefunden, der nicht nur diese Unterscheidungen kennt, der weiß wie man in agil geführten Projekten plant und schätzt, sondern der darüber sogar Bücher geschrieben hat. Mike Cohen. Na gut, ich habe ihn nicht persönlich kennengelernt, aber ich habe zwei seiner Bücher gelesen: "Agile Estimating and Planning" und "User Stories Applied".

Beide Bücher kann ich empfehlen, obwohl ich nicht empfehlen würde beide Bücher hintereinander zu lesen, wie ich es getan habe. Dafür ist die Schnittmenge des Inhalts zu groß.

Genug der Werbung: Wie plant nun das agile Projektmanagement? In letzter Instanz nicht so viel anders, als das klassische Projektmanagement, wenn es richtig gemacht wird. Es wird das geplant was planbar ist, und was für eine erfolgreiche Weiterarbeit notwendig ist. Bei der klassischen Netzplantechnik ist es naheliegend alle Aktivitäten gleich detailliert zu planen, obwohl dies weder realistisch noch förderlich ist.

Mike Cohen empfiehlt getrennte Planungen für unterschiedlichen Planungshorizonte: Projekt, Release, Iteration, Tag. Dadurch wird auch gleich ein weiterer typischer Fehler von klassischem Projektmanagement vermieden: Bei Projektbeginn wird der Projektplan erstellt und dann allenfalls mit dem Projektfortschritt aktualisiert. Klar, dass der bald nichts mehr mit der Realität zu tun hat. Aber wenn der detaillierte Plan nur bis zum Feierabend reicht, dann kommt man nicht drum rum am nächsten Morgen einen neuen Plan zu machen. Das gleiche gilt für die Pläne auf Iteration und Release Ebene.

Damit wird das Möglich, was für mich ein ganz wichtiger Aspekt der agile Projektarbeit ausmacht: Embracing Change (Änderungen umarmen?) d.h. Änderungen der Ziele und Vorgaben werden nicht als Störung des Projektes betrachtet, sondern als integraler, willkommener Bestandteil des Projektgeschäftes.

Aber was passiert mit den heiß geliebten Gantt-Charts und der Netzplantechnik? Diese sind tatsächlich hinfällig. Als Ersatz für die Abhängigkeiten im Netzplan werden die Anforderungen (Stichwort: User Stories) so gewählt, dass sie möglichst unabhängig voneinander sind. An dieser Stelle wird die Sache meiner Meinung nach wirklich spannend. Warum meint die Softwarebranche ohne diese Abhängigkeiten zurecht zu kommen, obwohl andere Branchen seit Jahrzehnten darauf schwören? Weil bei (gut geschriebener) Software jeder Teil geändert werden kann, ohne dass dies nennenswerte Auswirkungen auf andere Teile hat, während dies bei klassischen produzierenden Gewerbe unmöglich ist.

Man stelle sich mal vor, bei einem fertigen Gebäude soll das Fundament ausgetauscht werden ... unmöglich, unbezahlbar. Bei einem Programm die Persistenzschicht austauschen? Kein wirkliches Problem, natürlich müssen beide Varianten der Persistenzschicht entwickelt und letztendlich bezahlt werden, aber bei dem Rest des Programm sollte sich recht wenig ändern. Während das klassische Gebäude wohl komplett ab und wieder neu gebaut werden müsste. Dadurch ist es möglich die Bestandteile in beinahe beliebiger Reihenfolge zu erstellen. Im Umkehrschluss bedeutet dies aber auch, Projektanteile die nicht so flexible disponiert werden können, müssen entsprechend langfristig geplant werden. Know How in diesem Bereich ist also nicht verloren.

In allen anderen Bereichen geht es meist um eine verschobene Gewichtung: Wenn Plan und Realität auseinander gehen, wird dies eher über Anpassung der Ziele, d.h. des Projektumfangs aufgefangen, als durch Veränderung des Arbeitsvolumens. Dabei trifft der Kunde die Entscheidung was genau gestrichen oder angepasst werden sollte, anstatt wie ich es oft erlebt habe Grabenkämpfe um die Ãœbernahmen der Kosten zu führen.

Löst das alle Probleme? Ganz sicher nicht. Letzten Endes geht es in Projekten um Geld und da wird es Konflikte geben. Aber ich bin überzeugt, fast alle Projekte könnten von einer kleinen oder größeren Prise 'Agile Estimating and Planning' profitieren, nicht nur Softwareentwicklungsprojekte. Und wenn unsere Kunden das Buch lesen würden, könnten wir sie eher davon überzeugen gemeinsam ein Projekt zu machen anstatt gegeneinander.