Das Spektrum reicht vom Wasserfall bis hin zu agilem, iterativen Vorgehen. Der reine Wasserfall existiert bei genauer Betrachtung eigentlich gar nicht. Nur ein Idiot w\u00fcrde einen einmal gefassten Plan blind in einem Wurf umsetzen. Weitaus h\u00e4ufiger finden sich modifizierte Wasserfallmodelle. F\u00fcr den\u00a0Umgang mit Unsicherheit gibt es unterschiedliche L\u00f6sungsstrategien: Ein Changemanagement, das Change Requests an ein Projekt behandelt, oder eine iterative Ausarbeitung. Aber auch hier ist die Unterscheidung nicht sinnvoll, weil es auch in der vermeintlich klassischen Projektwelt erlaubt ist iterative Elemente einzusetzen und umgekehrt scheint mir das agile Vorgehen als Postulat genauso \u00fcberzogen, denn ich kann mir sehr wohl Vorhaben vorstellen, die f\u00fcr den gro\u00dfen Entwurf ein modifiziertes Wasserfallmodell w\u00e4hlen und erst in der Ausarbeitung agil werden, beispielsweise bei der Umgestaltung ganzer Unternehmensarchitekturen. Es gibt ergo keine harten Grenzen.<\/p>\n
Auf Seiten des gew\u00e4hlten F\u00fchrungsstils<\/strong> sieht es \u00e4hnlich aus:<\/p>\n Dem humanistischen Ideal des agilen Manifests, ein paritzipatives Modell, weitgehend selbstgesteuert, steht das autorit\u00e4re, taylorisitsche Denken gegen\u00fcber. Aber auch hier gebe ich zu Bedenken: Der gew\u00e4hlte F\u00fchrugnsstil muss sowohl zu den Beteiligten und der betroffenen Organisation passen, als auch dem konkreten Kontext gerecht werden. D.h. z.B. dass ein rein\u00a0agiles Vorgehen an bestimmte Voraussetzungen gebunden ist: Wenn eine Organisation noch nicht bereit ist f\u00fcr ein partizipatives Modell, so wird auch ein agiler Ansatz scheitern. Da hier kulturelle Prozesse betroffen sind, gibt es auch keine schnellen Ver\u00e4nderungen, sondern bestenfalls einen langwierigen, mit Anstrengungen verbundenen Prozess.<\/p>\n Einen zweiten kontextspezifischen Aspekt kann es aus sachlicher Notwendigkeit geben: Bei einem Notfall oder einem Rettungseinsatz, wird man schwerlich die Autortit\u00e4t des Einsatzleiters hinterfragen. Hier gibt es Notwendigkeiten in der zeitlich\/sachlichen Koordination, die eine Unterordnung erfordern. Dies ist aber kein blinder Gehorsam, sondern lediglich eine situationsspetzifische Unterodnung. Sobald die sachliche Notwendigkeit entf\u00e4llt besteht auch wieder die M\u00f6glichkeit zu Partizipation und autonomen Handeln.<\/p>\n Ein dritter und letzter wesentlicher Punkt bei der Wahl des F\u00fchrungsmodells stellt die erforderliche Expertise dar. Die Tayloristische Arbeitsteilung wird allzu schnell auf ihre arbeitspsychologischen Nachteile reduziert. Ein weiterer Aspekt (und auch ein Vorteil) liegt in der Spezialisierung (und Expertise). Die Annahme eines SCRUM-Teams, in dem jeder theoretisch jede Aufgabe \u00fcbernehmen kann, ist illusorisch. Nat\u00fcrlich gibt es komplexe Aufgaben die sinnvollerweise einem Experten zugeordnet werden. (Wer beispielsweise mal einen EDI-Experten in einem Unternehmen kennengelernt hat, wei\u00df wovon ich spreche…)<\/p>\n Der Versuch die existierenden Schulen\/Ans\u00e4tze<\/strong> in diesem Spektrum zu verankern ist zugegebenerma\u00dfen gewagt und im Detail zwangsl\u00e4ufig auch falsch.<\/p>\n Ich m\u00f6chte zwischen den verschiedenen Vertretern des „klassischen“ Projektmanagement (so fragw\u00fcrdig dieser Begriff auch immer ist) gar nicht differenzieren und Scrum ist auch nur ein Vertreter der agilen Welt. Mittlerweile gibt es auch bei\u00a0den „klassischen“ Vertretern \u00a0immer mehr das Aufrgreifen agiler Ans\u00e4tze und umgekehrt in der rein agilen Welt muss man sich auch den Realit\u00e4ten stellen: Wenn der Kunde sich nicht einbinden l\u00e4sst, dann muss auch der Product Owner neu interpretiert werden. Und wenn dann die Voraussetzungen nicht passen, dann sieht auch ein Scrum Master\u00a0genauso alt aus, wie ein im Stich gelassener klassischer PM.<\/p>\n De facto geht es halt doch nicht ohne eine kontextspezifische Betrachtung: Wichtiger als das Vorgehensmodell sind die konkreten Umst\u00e4nde. Welche Stakeholder sind eingebunden, nehmen welche Rolle war? Rollen lassen sich zum Teil nur definieren, zum Teil sind sie einfach nur gegeben. Ein gut eingebundener Kunde ist der Traum eines jeden Projetarbeiters – egal ob agil oder klassisch. In der Realit\u00e4t muss man den Kunden nehmen, den man hat. Das Leben ist kein Wunschkonzert.<\/p>\n![\"\"](\"https:\/\/lh3.googleusercontent.com\/-3tomAh0QtOc\/VBWWa8EPcLI\/AAAAAAAAByU\/URRJJowXd8c\/w1280-h720-no\/Spektrum.jpg=w784-h491-no\")
<\/p>\n