Wenn ich aus dem Gesamtprojekt auf das Development-Level herunterblicke, schaut das Agile dort vielleicht ungewohnt aus. So oder so ähnlich, nur umgekehrt, ist es wohl, wenn ich aus der Entwicklung ins Projekt hinausschaue.
Projekt-Level und Development-Level. Für mich gibt es in einem Projekt verschiedene Flughöhen. Weiter oben ist das Gesamtprojekt, wo ich die verschiedenen Prozesse des Projektmanagements anwende und mich mit den Competing Constraints herumärgere. Ein Teilbereich meines Projektes – sagen wir mal Teilprojekt oder Phase – ist in manchen Projekten die Produktentwicklung. Auf diesem Level sieht die Welt natürlich ein wenig anders aus – hier sind womöglich Time & Resource „gelockt“ (also weniger bis nicht beweglich), was mich dazu zwingt, kreativere Methoden einzusetzen. So wie zB jene der agilen Entwicklung. Die hat dann fast schon etwas von einem funktionalen Prozess – und nicht mehr unbedingt die gleichen Eigenschaften wie die eines Projektes. Ich habe den Eindruck, dass manchmal diese beiden Betrachtungsebenen miteinander vermischt werden. Und dass manche Leute - je nachdem, aus welchen Arten von Projekten sie kommen - die eine oder eben die andere Ebene besser kennen. Das kann dazu führen, dass manch Projektleiter eine agile Entwicklungsmethode als unkontrolliert, chaotisch oder anarchisch erlebt. Oder umgekehrt der Verantwortliche für eine Entwicklung, wenn er aus der Entwicklung heraus das gesamte Projekt anschaut, den Eindruck bekommt, er schaut da ein autoritäres, langsames und starres Ungetüm an.
Constraints kennen. Auf dem Gesamtprojekt-Level habe ich die permanent herumstreitenden Einschränkungen von Scope, Time, Resource, Cost, Stakeholdern usw. blabla. Irgendwas ändert sich ständig – das war immer schon so (sagt zumindest Jim Snyder
LINK) und wird immer so bleiben. So ist ja die Natur eines Projekts. Im anderen Extrem kann es sein, dass man in Teilbereichen des Projektes – siehe oben, zB bei agiler Entwicklung – bestimmte Constraints fixiert hat. Und andere wiederum gar nicht beachtet, wie zB Stakeholder oder Risiken. Irgendwo dazwischen stellt sich – bei jedem Projekt – die Frage, welcher Bereich stärker eingeschränkt ist, als ein anderer. Was in wiederum anderen Bereichen zu erhöhten Risiken führen wird. Wenn ich einen hohen Qualitätsanspruch habe, werde ich im Laufe meines Projektes irgendwann das Budget erhöhen oder halt den Endzeitpunkt nach hinten schieben. Auf allen Levels ist es hilfreich, sich über die Constraints auszutauschen. Ganz oben am Projekt-level definiere ich in meinen Projekten zu Beginn immer, was von Scope/Time/Resource/Cost am stärksten eingeschränkt ist (oder vice versa: Wo die höchste Risikotoleranz besteht). Und für alle Teilbereiche stellt sich diese Frage ebenso. Für manche Phasen und Teilprojekte kann das Bild dann auf einmal ganz anders ausschauen.
Mindset vs. Methode. Besonders bei agiler Entwicklung werden Methoden eingesetzt, die ungewöhnlich sein können. Besonders schwierig kann es werden, wenn man sich auf der Entwicklungsebene für den Einsatz agiler Methoden entscheidet, aber das dazugehörige Mindset (bzw. die Kultur) im Unternehmen bzw. im Gesamtprojekt nicht vorhanden ist. Agile Entwicklung für sich allein braucht Dinge wie eine besondere Art der Führung, ein geschütztes Umfeld – oder ein anders als im Gesamtprojekt geartetes Verständnis für vorhandene Ressourcen (Zeit, Geld, Menschen) und deren Einsatz. Mindset entwickelt sich aber nicht von selbst, nicht von heute auf morgen – und entsteht auch nicht durch brachialen Einsatz einer bestimmten Methodik. Es ist auch nicht auf allen Projektebenen dasselbe. Projektmanagement und agile Entwicklung sind untrennbar miteinander verbunden, doch ist beides eben nicht dasselbe, sondern integriert. Der beste Weg, wirklich zu verstehen, wie diese Integration ausschaut und funktioniert, ist in meinen Augen die Kommunikation. Wenn sich alle Beteiligten auf allen Levels im Projekt austauschen und verstehen lernen, wie die Teil-Welt des anderen – rein aus ihrer Natur heraus – funktioniert, dann werden hoffentlich bald einmal Begriffe wie „klassisch“ und „agil“ nicht nur nicht mehr als Widerspruch verstanden werden – sondern überhaupt nicht mehr existieren. (Autor: Daniel Hendling, President PMI Austria Chapter)
