Agiles Projektmanagement oder Agiles Arbeiten bedeutet unter anderem in einer Organisation oder in einem Projekt „Feature-getriebene“ bzw. „Cross-Funktionale“ Teams zu fördern und Silo-Denken zu vermeiden – egal wo.
Cross-Funktionalität bedeutet in einem Team alle Fähigkeiten zu bündeln, die es braucht, um ein Feature in sich geschlossen zu entwickeln und fertigzustellen – und nicht auf mehrere Teams zu verteilen, wie es in der Praxis häufig der Fall ist. Die IT beispielsweise wird oft in sogenannten Komponenten-Teams organisiert, gesteuert und geführt.
Komponenten-Teams sind Teams, die für die Entwicklung eines Teils aus dem gesamten Produkt-Entwicklungszyklus zuständig sind, also für eine Komponente. Komponenten-Teams können in der Softwareentwicklung z.B. eingeteilt sein in ein Team zur Datenbank-Verwaltung, ein Team, das Caching-Mechanismen umsetzt und ein GUI-Team, das die visuelle Schnittstelle zum User baut. Vereinfacht gesagt: Bei Komponenten-Teams wird immer eine Trennung zwischen den Komponenten im Backend und dem Frontend vorgenommen. Aus Sicht der IT ist diese Trennung erst mal logisch. Schließlich gibt es Spezialisten, die genau für die Entwicklung einer Komponente ausgebildet sind und dazu auch eingestellt wurden.
Die Komponenten-Struktur zieht jedoch eine Reihe schwergewichtiger Nachteile nach sich, derer sich jede Organisation wohl bewusst sein sollte. Die jeweilige Projektstruktur sollte daraufhin hinterfragt und überdacht werden.
Konsequenzen der Organisation in Komponenten-TeamsEine der wesentlichsten Konsequenzen ist, dass die Teams weniger fähig sind „das Ganze“ zu sehen: Teams erfassen die Produktentwicklung von Anfang bis Ende nicht so gut, und sie fühlen sich über ihre Teamgrenzen hinweg auch nicht verantwortlich für den Erfolg oder Misserfolg der Produktentwicklung. Dadurch setzen si
e sich auch weniger in eigenem Engagement dafür ein, den Produktentwicklungszyklus zu messen, Engpässe zu erkennen und gemeinsam initiativ zu werden, um Verbesserungen vorzunehmen. Ein weiterer Negativ-Aspekt ist der über kurz oder lang eintretende Identifikationsverlust mit dem Endprodukt.
Die andere wesentliche Konsequenz ist, dass die Organisation in Komponenten-Teams starke Abhängigkeiten zwischen den Teams schafft, da die Komponenten sequentiell in der Entwicklung vorgehen müssen: Team C kann erst mit der Entwicklung beginnen, wenn das Resultat von Team B vorliegt. Und Team B kann erst loslegen, wenn Team A seine Entwicklung zur Verfügung gestellt hat. Diese Abhängigkeiten führen
Ein Feature ist also erst fertig, wenn alle Teams ihren Beitrag geleistet haben. D.h. ein Feature muss durch die gesamte Sequenz eines Produktenwicklungszyklus hindurch, um an den Kunden ausgeliefert werden zu können. Die Komponenten Teams arbeiten dabei häufig nicht so effektiv Hand in Hand, was zu erheblichen Verzögerungen in der Lieferung eines Features führt.
Weitere Beispiele für Komponenten-Teams sind zum Beispiel
Gerade wenn eine Organisation oder ein Projekt in einer komplexen Umgebung agiert, wird sie irgendwann träge. Zum Beispiel weil es viele und sich häufig ändernde Anforderungen vieler verschiedener Stakeholdern und Kunden gibt, noch keine Erfahrung mit bestimmten Technologien vorhanden ist oder das Projekt in einem skalierten Entwicklungsumfeld agiert mit mehreren parallelen Teams. Um die Fähigkeit für schnelle Entscheidungen, zuverlässigere Planung und Lieferung, Identifikation der Mitarbeiter mit dem Produkt und mehr Verantwortung der Mitarbeiter für den gesamten Produktentwicklungszyklus wieder herzustellen, ist eines der agilen Konzepte ein ultimativen Hebel: „Fördere Cross-Funktionalität wo es nur geht, d.h. die Sicht und die Verantwortung einer Projektorganisation auf das Ganze – Ende-zu-Ende“.
Mehr über Agile Konzepte und Arbeitsmethoden erfahren Sie in dem Seminar inklusive webbasiertem Training Agiles Projektmanagement.
Frankfurt School gGmbH
Adickesallee 32-34
60322 Frankfurt am Main
