Projekte, die agile Vorgehensweisen einsetzen, sind erfolgreicher. Anderseits gibt es einen noch ausgeprägteren Zusammenhang zwischen Teamqualität und Projekterfolg. Meine These lautet: Es kommt darauf an, dass sich während des Projektes ein echtes Team bildet. Wenn agile Methoden eingesetzt werden, gelingt dies ein wenig leichter. Diese These möchte ich im Folgenden erläutern.

Wie sieht der gemeinsame Kern agiler Vorgehensweisen aus?

• Es wird akzeptiert, dass zu Beginn nur ein Teil der Anforderungen definiert ist.
• Es besteht permanenter und enger Kontakt zu denen,
  die das Arbeitsergebnis geliefert bekommen.
• Es wird in wiederkehrenden Intervallen gearbeitet.
• Am Ende jeden Intervalls wird ein verwendbares Zwischenergebnis fertig gestellt.
• Jedes Arbeitsintervall wird ausgewertet.
  Es werden Konsequenzen für das nächste formuliert und auch gezogen.
• Die produktive Arbeit wird von einem Team geleistet, das selbstorganisiert arbeiten darf.

Aus der Formulierung der Merkmale wird schon deutlich, dass diese Arbeitsweise nicht nur für Software-Entwicklung sondern für viele verschiedene Projektarten möglich sein wird. Wie die Merkmale in der Praxis konkret umgesetzt werden (z.B. mittels Scrum) ist letztendlich egal. Genauer betrachtet lässt sich diese Arbeitsweise auch mit “klassischem Projektmanagement” zuzüglich ordentlichem Changemanagement, kooperativer Führung und transparenter Kommunikation verwirklichen. Agilität ist ohnehin eher als Geisteshaltung denn als Prozessbeschreibung zu verstehen.1

Nehmen wir an, dass in einem Projekt wie oben beschrieben gearbeitet wird. Das Team arbeitet und liefert nach einer gewissen Zeit ein (hoffentlich) verwertbares Zwischenergebnis ab. Sollte im ersten Intervall nichts Brauchbares fertig werden, muss eben nach den Gründen gesucht werden um dann im zweiten Anlauf erfolgreicher zu sein. Egal ob im ersten oder zweiten Anlauf, das Team hat sehr früh ein Erfolgserlebnis. Konkrete (Erfolgs)-Erlebnisse und Erfahrungen beschleunigen die teaminternen Klärungsprozesse wie Rollenklärung oder die üblichen Machtkämpfe erheblich. Ein simples Beispiel: Ein Kollege bezeichnet sich selbst als Spezialist für ein bestimmtes Thema. Stimmt das? Können sich Team und Projekt wirklich darauf verlassen? Nach der Lieferung des ersten Zwischenergebnisses hat sich das bestätigt (oder eben nicht). Die Bestätigung der Fähigkeiten, der Verlässlichkeit, das Erproben der Zusammenarbeit, das Wachsen des aufkeimenden Vertrauen – all dies erfolgt schneller wenn mit greifbaren Zwischenschritten gearbeitet wird.2 Im negativen Fall wird ebenfalls schneller klar, dass der Kollege vielleicht nur eine große Klappe hatte und er mit einer anderen Aufgabenstellung mehr für das Projekt tun kann. Wichtige Grundvoraussetzungen für eine erfolgreiche Teamentwicklung wie die Klärung der Fragen “Wer gehört dazu?” bzw. “Wie sieht die gemeinsame Aufgabe aus?” werden bei einer solchen Vorgehensweise quasi im Vorbeigehen erledigt.

Wer agil arbeitet, stellt gewissermaßen ganz nebenbei gute Rahmenbedingungen für eine konstruktive Teamentwicklung bereit.

Eine konstruktive Teamentwicklung innerhalb des Projektes ist m.E. DER Erfolgsfaktor für Projekte. Scrum stellt hierfür bessere Rahmenbedingungen als das Wasserfallmodell bereit. Dennoch gibt es keinen Königsweg. Auch in Wasserfall-Projekten lässt sich ein Teil des agilen Gedankenguts (siehe obige Merkmale) leben. Ein gutes Team schafft fast alles, eine zerstrittene Projektgruppe kann jedes Projekt scheitern lassen.

1. Insofern kann ich Stimmen, die Scrum als alten Wein in neuen Schläuchen bezeichnen durchaus verstehen. [↩]
2. Ein Meilenstein in einem Projektplan ist nicht zwingend ein greifbarer Zwischenschritt. Die Softwareentwicklung hat es hier relativ leicht. Hier entspricht dies einem lauffähigen Release. In anderen Projekten muss die Definition der Meilensteine genau bedacht werden. [↩]