Agiles Projektmanagement oder kurz „agile“ ist in den letzten Jahren sehr populär geworden. Die Vorgehensweise setzt sich immer mehr gegen etablierte, konservative Projektmanagementmodelle wie das sehr prominente „Wasserfallmodell“ („V-Modell“ u.a.) durch.
Der sicherlich bekannteste Vertreter der agilen Projektmanagementmodelle ist „Scrum“, abgeleitet vom gleichnamigen Begriff aus der Welt des Rugbysports (zu deutsch etwa „Gemenge“). Weitere, etwas weniger bekannte, Vertreter sind „Kanban“, „extreme Programming“ u.v.m.
Prinzipien
Die agilen Projektmanagementmodelle bzw. Entwicklungsmodelle sind sich einander sehr ähnlich, denn sie beruhen alle auf den selben agilen Prinzipien. Diese lassen sich knapp durch höhere Flexibilität, mehr Transparenz und schnellere Bereitstellung von Ergebnissen im Entwicklungsprozess zusammenfassen. All dies wird ermöglicht durch bessere Kommunikation. Kommunikation ist der Dreh- und Angelpunkt hierbei. Etwa 50% der Arbeitszeit in Softwareentwicklungsprojekten wird aufgewendet für Kommunikation. Hier steckt das größte Risiko, aber auch das größte Potenzial!
Intuitiv lässt sich die Liste der agilen Prinzipien (siehe auch „agiles Manifest“) sehr gut nachvollziehen und kaum jemand, der einige Jahre Berufserfahrung mit Wasserfall und Co. gesammelt hat, würde diesen widersprechen wollen. Die Vorgaben sind in der Theorie klar formuliert. Doch lassen sich diese „modernen“ Vorgehensmodelle auch ohne weiteres in die Praxis umsetzen? Die Modelle gibt es nicht erst seit gestern, dennoch setzen sie sich in der Praxis mitunter nur sehr langsam durch und dafür gibt es dann auch gute Gründe. Also woran hakt es in der Praxis?
Zunächst sollten alle Teammitglieder und bestenfalls alle Stakeholder, verstanden haben, was agil bedeutet und wie das gewählte agile Modell nun umzusetzen ist. Glücklicherweise sind die Grundstrukturen der agilen Modelle schnell erklärt und festigen sich auch schnell, nach einigen Anwendungen. Dennoch sollte man sich von diesen „einfachen“, teilweise philosophisch klingenden Techniken und Ritualen nicht täuschen lassen: Es ist essentiell diese auch kontinuierlich anzuwenden um nicht in „alte“ Verhaltensmuster aus der Wasserfallzeit zurückzufallen.
Ein Trugschluss ist, dass in der agilen Welt nicht dokumentiert wird. Ein gewisses Maß an Dokumentation ist immer notwendig - wie viel genau, das lehrt die Erfahrung des Teams. Wenn nun die Dokumentation schleichend, von Zyklus zu Zyklus (siehe z.B. Sprints in Scrum) immer weiter zurückgefahren wird, findet man sich irgendwann vor Problemsituationen, in denen man sich die wohldefinierten Dokumente des Wasserfalls zurückwünschen könnte.
Unterstützend wirken bei der Dokumentation und Aufgabenverwaltung Tools wie Tasktracker/ Bugtracker und Wikis. Darüber hinaus gibt es eine Vielzahl an weiteren Tools, die jeden einzelnen Prozessschritt der Projektarbeit unterstützen kann. Die Gefahr liegt hierbei eher darin, sich nicht zu viele neue Tools (mit exotischen Namen) auf einmal vorzunehmen, denn auch die Einarbeitung in ein Tool erfordert die Zeit aller Teammitglieder. Bei aller Tool-Pflege soll am Ende ja schließlich noch Software entwickelt werden. =)
Team und Arbeitsumgebung
Eine der wichtigsten Forderungen von agile lautet „Enable the team!“. Es geht um Rollen & Fähigkeiten, Befugnisse und die Arbeitsumgebung. Das Team muss möglichst autonom handeln können. Dazu müssen alle nötigen Rollen im Team vertreten sein: Entwickler, Tester, Vertreter für die Anforderungen und weitere (in Scrum beispielsweise noch ein Scrum Master zur ständigen Optimierung des agilen Prozesses). Unabhängig von den Rollen sollte das Team alle Fähigkeiten inne haben, die es benötigt um ein Stück Software bis in die Produktion zu bringen. Bestenfalls werden die Fähigkeiten jeweils durch mehr als eine Person abgedeckt, um Belastungsspitzen und Ausfallzeiten zu kompensieren oder um einfach mal eine zweite „Fachkundige Meinung“ einholen zu können.
Das Team sollte auf möglichst wenige Rollen/Fähigkeiten bzw. daran hängende Prozesse von außerhalb angewiesen sein, denn jede Schnittstelle nach „außen“ ist im Zweifelsfall eine Schnittstelle zur nicht-agilen Welt, bei der man direkt mit starren Servicezeiten, Vorlaufzeiten, Dokumenten, Fristen, Unterschriften etc. zu kämpfen hat.
Zuletzt sollten die Rahmenbedingungen für die Kommunikation innerhalb des Teams möglichst gut ausgestaltet sein. Sicherlich können agile Teams auch über den Globus verteilt funktionieren. Aber zunächst unscheinbare Erschwernisse wie fehlende physische Nähe, unterschiedliche Zeitzonen, schlechte Telefonverbindungen und kulturelle Differenzen stellen sich doch meist als großer Nachteil heraus. Im Endeffekt wird die ein oder andere Frage nie gestellt, der ein oder andere Kommentar ignoriert, ein wohlgemeinter Tipp falsch verstanden oder eine Emotion unterdrückt. All das fällt in die Kategorie nonverbale Kommunikation. Laut Wissenschaft beträgt die Wirkung dieser Art von Kommunikation bei einem Gespräch 55% (38% Stimmlage, 7% Inhalt) und eben dieser Teil geht fatalerweise verloren.
Zuletzt ist eine Einbindung des Kunden essentiell. Zwar gibt es oft einen Vertreter des Auftraggebers bzw. für die Anforderungen im Team. Diese Personengruppe muss aber regelmäßig in die Projektarbeit eingebunden werden, da sie letztlich das (End-) Produkt nutzt bzw. abnimmt. Vor allem das Feedback der zukünftigen Nutzer ist unabdingbar. Ein klassisches Phänomen in der Softwareentwicklung ist, dass die Nutzer immer „eigene Wege finden“ wie sie ein Produkt nutzen. Dagegen hilft kein wochenlanger Designprozess sondern schlicht das regelmäßige Einholen von Nutzerfeedback. Die Software wird ja schließlich für die Nutzer entwickelt. Außerdem ist nur ein zufriedener Kunde ein Kunde, der wiederkommt.
Erfahrungsgemäß ist das Problem des fehlenden Kundenfeedbacks bei agilen Pilotprojekten meist auf die mangelnde Bereitschaft des Kunden zurückzuführen, sich regelmäßig mit dem Produkt auseinanderzusetzen. Dies erfordert nämlich während des gesamten Projektverlaufs einen oder mehrere Personen auf Kundenseite, die sich stetig mit der Produktentstehung beschäftigen. Es sollten die Optionen, sowie die Vor- und Nachteile diskutiert werden, um den späteren Nutzen für sich zu maximieren. Agil bedeutet nicht, dass man keine Entscheidungen mehr treffen muss - sie sind lediglich verteilt über die Zeit und nicht gehäuft zu Beginn, wie bei klassischen Vorgehensmodellen.
Schrittweise Einführung
Insgesamt setzen sich agile Modelle langsam aber stetig durch. Oftmals wird "agile" im Unternehmen noch als „agile in a box“ angewandt. Das bedeutet, man fängt eben mal damit an einzelne Pilotprojekte umzustellen. Da die gesamte Umwelt des Projekts aber noch nach dem Wasserfall funktioniert, entstehen ständig Reibungen an den Schnittstellen des Projekts nach außen, z.B. bei Releases. Ein motiviertes Team kann innerhalb seines Projekts noch so vorbildlich agil handeln - wenn das übergeordnete Releasemanagement diesen Wandel nicht mit begleitet, sondern strikte Releasetermine vorgibt, wird Agilität unterdrückt. In gleicher Weise gilt das für Budgets, Staffing und Zeitplanungen.
Ein ganzes Unternehmen auf einen Schlag auf agil umzustellen mag unmöglich sein, aber jede neue Bewegung braucht ihre Zeit um Fahrt aufzunehmen. Mancher Manager könnte zum fatalen Trugschluss gelangen, dass „agil bei uns eben nicht funktioniert“. Hier müssen Kompromisse gefunden werden, denn „agile“ selbst kann eben auch nur schrittweise eingeführt werden.
