Projektarten im agilen Kontext

Architektur/Methoden  –  Kommentare

Scrum ist ein einfaches und universelles Vorgehensmodell ("für alle das Gleiche"), das Projekte und Teams spezifisch adaptieren und ausprägen ("jeder macht etwas anderes daraus"). Die spezifischen Ausprägungen hängen unter anderem von den Rahmenbedingungen und der Art der Projekte ab.

Unterschiedliche Projektarten führen typischerweise zu spezifischen Herausforderungen für die Beteiligten. Je nachdem, ob man das Projekt beispielsweise intern oder extern entwickelt, es öffentlich ausgeschrieben wird oder nicht, der Preis feststeht oder nach tatsächlichem Aufwand abgerechnet wird, ob es ein kleines oder großes Projekt ist, ob es sich um eine Neu- oder Weiterentwicklung handelt, erfordern andere Sachverhalte die besondere Aufmerksamkeit.

Scrum verlangt eine andere Sichtweise auf die Frage nach der Projektart als nicht agile Vorgehensweisen. Seine wachsende Popularität führt derzeit zu Fragen in der Art "Wie mache ich eigentlich 'etwas Bestimmtes' in Scrum?". Mit 'etwas Bestimmtem' sind etwa das Arbeiten an zwei Standorten, Festpreis, das Einbinden nicht agiler Zulieferer, drei Teams und Architekturstandards gemeint.

Je nach Projektart hat die Frage aber oftmals eine andere Bedeutung, und auch die Antworten gestalten sich unterschiedlich. In Diskussionsforen ist häufig zu beobachten, dass (die ersten) Antworten oft an der Frage vorbeigehen, weil unausgesprochen eine andere Projektart unterstellt wurde.

Die Zusammenarbeit des Product Owner mit Domänen- und Anforderungsexperten birgt in einer internen Produktentwicklungsorganisation beispielsweise andere Chancen und Risiken als die in einer externen Projektorganisation mit wiederum vielen Zulieferbeziehungen zu Dritten.

Im Folgenden seien Projektarten vor allem im Hinblick auf die Bedeutung für Scrum-Projekte beziehungsweise für agiles Projektmanagement und agiles Requirements Engineering unterschieden.

Auch wenn es eine DIN-Definition des Begriffs "Projekt" gibt, spielt sie nach Gerhard Wohland "aber kaum eine Rolle. Jedes Unternehmen hat eine eigene Auffassung von dem, was ein Projekt ist. Oft gibt es sogar im gleichen Unternehmen mehrere Auffassungen. – Am häufigsten sind sogenannte temporär modifizierte Linienstrukturen, die als Projekt bezeichnet werden." Der Autor schließt sich Wohland an und versteht unter "'Projekt' eine temporär gebildete Sonderorganisation – in einer permanenten Organisation (Linie) als Umgebung". [1]

Ein zum allgemeinen Verständnis wichtiges Unterscheidungsmerkmal ist der Status im Lebenszyklus (Neuentwicklung, Erweiterung, Wartung et cetera). Die hieraus resultierenden Projektarten werden im Folgenden zunächst kurz dargestellt, um dann jedoch zu einem anderen wichtigen Unterscheidungsmerkmal zu wechseln, nämlich der Organisations- und Verantwortlichkeitsstruktur, die speziell für agile Projekte interessanter sein dürfte.

Die Unterscheidung nach Lebenszyklus führt zu folgenden Arten:

  • Neuentwicklung eines Produkts, das es so noch nicht gibt;
  • Erweiterung eines Produkts;
  • Wartung, also das Aufrechterhalten der Einsatz- und Leistungsfähigkeit sowie die Fehlerbehebung;
  • Sanierung oder Migration, den vollständigen oder teilweisen Ersatz eines Produkts durch ein neues mit besserer Architektur und besseren Techniken bei weitgehend identischen Funktionen;
  • Integration, die technische oder organisatorische Einbettung eines bestehenden Produkts in eine neue Umgebung;
  • Standardsoftware, der Kauf und die Einbettung in die eigene Umgebung eines Standardprodukts, wobei sowohl das Standardprodukt als auch die eigene Umgebung (vor allem Prozesse und Organisation) manchmal erheblich anzupassen sind.

Die Unterscheidungen haben Einfluss auf die Art, wie sich Anforderungen ermitteln und behandeln lassen beziehungsweise welcher Art die Anforderungen überwiegend sind, weniger jedoch auf die Verteilung der Verantwortlichkeiten.

Wenn der Wartungsaufwand eher niedrig ist und kein Team konstant auslastet, stellen sich beispielsweise organisatorische Fragen. Normalerweise sollte ein Team nicht an mehreren Projekten gleichzeitig arbeiten sowie nur einen Product Backlog und einen Product Owner haben. Wartungsbedarf entsteht oftmals ad hoc. Ist der Aufwand außerdem gering, lohnt sich das Etablieren eines eigenen Teams und eines eigenen Product Backlog kaum.

Eine Lösung des Dilemmas wäre, die Wartungsaufgaben so vieler verschiedener Systeme in einem Wartungs-Product-Backlog zu bündeln, dass sich die iterationsweise Einsetzung eines Teams hierfür lohnt. Man muss noch nicht einmal ein permanentes iteratives Vorgehen (auf eine Iteration folgt gleich die nächste) erreichen, sondern es lassen sich einfach so viele Wartungsaufgaben in einem Product Backlog sammeln, bis sie das Einsetzen eines Teams und einer Iteration rechtfertigen.

Auch ist es nicht zwingend, ein festes Wartungsteam vorzuhalten. Denkbar wäre, in Iterationen wechselnd andere Teams einzusetzen oder neu zu bilden. Allerdings würde das den Bedarf nach einem Projektportfoliomanagement wecken.

Bei Integrationsprojekten stellt sich die Beurteilung des Geschäftswerts und damit die Priorisierung der Aufgaben meistens anders dar. Die geschäftlichen Funktionen sind schon vorhanden. Der damit korrespondierende geschäftliche Nutzen ist auf Produktseite bereits hergestellt, das Produkt läuft bloß noch nicht in der richtigen Umgebung.

Typische Situationen für Integrationsprojekte sind:

  • Die Entscheidung, keine neue Software zu entwickeln, sondern eine fertige Lösung oder ein Standardprodukt zu kaufen. Bei einer "Make or Buy"-Entscheidung fällt die Wahl demnach auf "Buy". Da kaum eine Software völlig unabhängig vom Rest der Welt eingesetzt wird, steht hierbei die Integration in die bestehende Organisation sowie die bisherigen Prozesse und Systeme im Vordergrund.
  • Durch die Fusion von Unternehmen oder Unternehmensteilen, die bislang unabhängig voneinander operiert haben, werden Systeme des einen in die Umgebung des anderen integriert. Auch das betrifft die Prozesse, die Organisation und die Technik.
  • Aufbau und Erschließen neuer technischer Plattformen und Medien. Beispielsweise sollen betriebsinterne Systeme im Internetbrowser lauffähig werden oder man will zur Einsparung von Lizenzkosten andere Datenbanken, Betriebssysteme oder Middleware einsetzen.

Integrationsprojekte wären stets gegen die Alternative Neuentwicklung abzuwägen. Sie haben typischerweise andere Interessenhalter als Neuentwicklungsprojekte. Die Bemessung des geschäftlichen Nutzens ist oftmals indirekter und dadurch intransparenter.

Grundsätzlich ist die Einführung einer Standardsoftware ein Integrationsprojekt, denn es wäre eine Ausnahme, wenn sie keine Auswirkung auf die bestehende Umgebung hätte. Manchmal ist es sinnvoller, die Standardsoftware zu verändern und an die eigenen Bedürfnisse anzupassen. Ein anderes Mal hingegen, die eigene Organisation und Prozesse an die Standardsoftware anzugleichen. In der Praxis ist es fast immer eine Mischung aus beidem.

Als agile Strategie empfiehlt sich, die Standardsoftware zunächst möglichst unverändert einzusetzen und Erfahrungen und Erkenntnisse darüber zu sammeln, wo überhaupt Anpassungsbedarf notwendig ist. Der erkannte Bedarf lässt sich danach priorisieren und umsetzen. Denkbar wäre, die Standardsoftware nur von einem kleinen, aber repräsentativen Teil der Organisation beziehungsweise Anwender nutzen zu lassen. Jedenfalls sollte das rein theoretische Antizipieren des Anpassungsbedarfs allenfalls eine Ergänzung, keinesfalls aber die primäre Basis für Umsetzungsentscheidungen bilden. Das würde agilen Prinzipien widersprechen und zu großen fragwürdigen Anforderungsbeständen führen. Empirisches Vorgehen sollte Priorität haben.