zurück zum Artikel

Scrum ist ein einfaches und universelles Vorgehensmodell, das Projekte und Teams spezifisch adaptieren und ausprägen. Die spezifischen Ausprägungen hängen unter anderem von den Rahmenbedingungen und der Art der Projekte ab.

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.

Projektarten und ihre Ausprägungen

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.

Unterscheidung nach Lebenszyklus

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.

Wartungsprojekte

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.

Integrationsprojekte

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.

Standardsoftware

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.

Organisations- & Verantwortlichkeitsstruktur I

Unterscheidung nach Organisations- und Verantwortlichkeitsstruktur

Werden Projekte nach Organisations- und Verantwortlichkeitsstruktur unterschieden, ergeben sich ganz andere Projektarten, mit anderen Risiken, Chancen und Herausforderungen.

Das betrifft vor allem den Product Owner und seine Stakeholder. Für den Product Owner und das Requirements Engineering sind die Unterschiede in der Aufteilung der Verantwortlichkeiten zwischen den Beteiligten besonders relevant, und sie führen in der Praxis zu unterschiedlichen Arbeitsweisen, weswegen der Unterscheidung besondere Aufmerksamkeit gewidmet sei.

Die in der Tabelle näher beschriebenen Projektarten "internes Projekt", "interne Linienaufgabe", "Gewerk", "Produktanbieter", "Koordinator" und "Kooperative" sind lediglich prototypische Ausprägungen. Tatsächlich gibt es beliebig viele Mischformen und Extreme. Beispielsweise sind Automobilhersteller sowohl Anbieter von Publikumsprodukten und gleichzeitig Koordinatoren einer Unmenge von Zulieferern. Sie bieten damit wahrscheinlich die größten Herausforderungen im Kontext des agilen Requirements Engineering.

"Unterscheidung nach Organisations- und Verantwortungsstruktur"

Internes Projekt

Alle Beteiligten arbeiten für das gleiche Unternehmen – entweder für die Linienorganisation oder für das Projekt. Die Projektmitglieder haben zeitlich befristet die Projektleitung als fachlichen Vorgesetzten. Das Team gehört in jedem Fall zur Projektorganisation, der Product Owner ebenfalls.

Bei dieser Projektart wird in den meisten Fällen die Software für den eigenen Bedarf des Unternehmens entwickelt, weiterentwickelt oder angepasst. Gegebenenfalls trifft es zu, dass sie zusätzlich für kooperierende Geschäftspartner programmiert wird. Die Software unterstützt gewöhnlich indirekt den eigentlichen Geschäftszweck des Unternehmens. Beispielsweise entwickeln die Programmierer einer Krankenversicherung in einem Projekt eine Software für die eigene Verwaltung. Zusätzlich erhalten sie Unterstützung durch externe Entwickler und Berater.

Gewöhnlich sind viele Beteiligte angestellte Mitarbeiter, die durch Externe Unterstützung erhalten (in Form von Arbeitnehmerüberlassung, auch "Body-Leasing" oder "Consulting" genannt), sobald interne Kräfte nicht ausreichend verfügbar sind. Im Extremfall können aber alle Beteiligten Externe sein – maßgeblich ist, dass die Projekt- und Gesamtverantwortung beim beauftragenden Unternehmen liegt. Auch hierfür sei ein Beispiel gebracht: Ein Mobilfunkunternehmen wird mehr oder weniger auf der grünen Wiese gegründet, fast ausschließlich durch externe Berater aufgebaut, die die Firma schließlich nach und nach durch angestellte Mitarbeiter ersetzt.

Einige Besonderheiten sind im Kontext des agilen Requirements Engineering besonders: Entwicklungsteam, Product Owner und Scrum Master arbeiten angestellt oder mit Dienstleistungsvertrag für ein Unternehmen, das gleichzeitig Auftraggeber und -nehmer ist. Dadurch vereinfachen sich viele Aspekte in der Zusammenarbeit. Beispielsweise sind die meisten Benutzer ebenfalls Mitarbeiter im gleichen Unternehmen. Allerdings sind die Anforderungen gebenden Organisationseinheiten (vor allem Fachabteilungen und Geschäftsstellen) oftmals verstreut und verfolgen möglicherweise unterschiedliche Interessen, Prioritäten und widersprüchliche Anforderungen.

Ein agiles Projekt sollte daher bemüht sein, die Anforderungen gebenden Einheiten zusammenzubringen und mit ihnen ein gemeinsames Bild zu kreieren. Es sollte die Zusammenarbeit so gestalten, dass sich die potenziell widersprechenden Parteien anleiten lassen, ihre Widersprüche konstruktiv und miteinander zu erkennen und zu klären.

Soweit das nicht gelingt, ist das Projektteam gefährdet, permanent als Mittler und Stellvertreter auftreten zu müssen und zwischen den Parteien zerrieben oder gar ausgespielt zu werden. Eine nicht nur undankbare, sondern auch selten erfolgreiche Rolle. Ein dediziertes Stakeholder-Management sollte von Anfang an dazu gehören. Unabhängig davon braucht man in jedem Fall eine über allem stehende Eskalations- und Entscheidungsinstanz. Der Product Owner ist prädestiniert hierfür.

Typische Herausforderungen für ein internes Projekt sind:

• einflussreiche und sich widersprechende Interessenvertreter;
• verstreute Interessenvertreter;
• Stellvertreterkonflikte.

Interne Linienaufgabe

Eine interne Linienaufgabe unterscheidet sich vom internen Projekt im Wesentlichen dadurch, dass man die Software nicht in Form von Projekten, sondern durch eine dauerhafte Entwicklungsorganisation programmiert. Oftmals ist der Betrieb der Software auch der primäre Geschäftszweck.

Nicht selten gibt es auch Mischformen dergestalt, dass ausgewählte Teile als Projekt und die übrigen durch die Dauerorganisation entwickelt werden. Häufig ist auch eine Entwicklung in Form zahlreicher Klein-"Projekte" anzutreffen. Ein Internetportal entwickelt etwa die eigene Internetanwendung permanent weiter. Der Betrieb der Anwendung ist der unmittelbare Geschäftszweck. Die Weiterentwicklung orientiert sich an neuen Funktionen, die projektunabhängige Einheiten produzieren. Sofern nicht der Betrieb, sondern die Herstellung und der Vertrieb der Software primäre Geschäftszwecke sind, handelt es sich meistens um Produktanbieter.

Im Kontext des agilen Requirements Engineering sind wieder einige Besonderheiten zu beachten: Wie beim internen Projekt arbeiten Entwicklungsteam, Product Owner und Scrum Master als Angestellte oder mit Dienstleistungsvertrag für ein Unternehmen, das Auftraggeber und -nehmer ist. Sofern auch noch der Betrieb der Software mit dem Geschäftszweck des Unternehmens korrespondiert, ist die Zusammenarbeit der Beteiligten meistens einfacher als bei internen Projekten.

Im Unterschied zu ihnen befinden sich die Benutzer häufig außerhalb des Unternehmens, und es sind meistens deutlich mehr Anwender. Dafür haben einzelne weniger Macht und Einfluss und vertreten ihre Interessen gewöhnlich nicht direkt.

Typische Herausforderungen für den zweiten Projekttyp sind:

• Benutzer lassen sich nicht oder nur indirekt beteiligen;
• Benutzer mit geringem Einfluss.

Gewerk

Wie beim internen Projekt oder bei der internen Linienaufgabe wird eine Individualsoftware für den Eigenbedarf programmiert. Die Entwicklung ist jedoch ergebnisverantwortlich an Externe ausgelagert. Gewöhnlich schreibt man die Vorhaben aus und realisiert sie als Werkvertrag durch einen externen Auftragnehmer – oftmals zum Festpreis. Der Auftraggeber ist einerseits Zulieferer von Anforderungen und Entscheidungen des Auftragnehmers und zum anderen gegebenenfalls Koordinator der internen und externen Beteiligten.

Verantwortung und Kompetenzen (zum Beispiel Haftung, Gewährleistung, Zahlungsmodalitäten, Vorgehensweise) sind maßgeblich anders verteilt als bei Dienstleistungsaufträgen. Der Auftraggeber bestimmt die gewünschten Eigenschaften des herzustellenden Produkts, gewöhnlich aber kaum, wie sie herzustellen sind. Beispielsweise schreibt ein Seehafen auf Basis einer groben Anforderungsspezifikation die Entwicklung eines Hafenlogistiksystems öffentlich aus und beauftragt einen externen Auftragnehmer mit der schlüsselfertigen Herstellung (in Form eines inhaltsvarianten Festpreises).

Gerade die Festpreis-Variante, wie sie etwa für öffentliche Auftraggeber und andere stark haushaltsplanende Organisationen wichtig ist, prädestiniert ein Vorgehen, das regelmäßig brauchbare Vorversionen liefert und die Anforderungen nach absteigendem Geschäftswert sortiert umsetzt. Die Einhaltung eines Kostenziels ist bei der agilen Vorgehensweise vergleichsweise einfach, und der geschäftliche Nutzen lässt sich gut optimieren. Ein Wasserfallvorgehen kann nichts Vergleichbares bieten, auch wenn der Irrglaube, Wasserfallprojekte eigneten sich gut für Festpreise, immer noch populär ist.

Typische Herausforderungen für Gewerkentwicklungen sind:

• Auftragnehmer und Auftraggeber sind getrennt, die Projektbeteiligten haben unterschiedliche, sich auch widersprechende Interessen;
• aufwendige Auftragsklärung vor Vertragsschluss;
• nur wenige Einfluss- und Eskalationsmöglichkeiten zwischen Auftraggeber und -nehmer und nur indirekte zwischen Projektbeteiligten unterschiedlicher Parteizugehörigkeit.

Organisations- & Verantwortlichkeitsstruktur II

Produktanbieter

Beim dieser Projektart ist der Verkauf der entwickelten Software der eigentliche Geschäftszweck, ansonsten sind die Eigenschaften ähnlich wie bei der internen Linienaufgabe oder gegebenenfalls beim internen Projekt. Beispielhaft sei ein Medizingerätehersteller genannt, der Beatmungsgeräte samt zugehöriger Software herstellt, die er an Krankenhäuser verkauft.

Sofern es sich um eine neue Produktart handelt, ist die frühe Lieferung funktional abgespeckter Artikeln wie iPhone und iPad. Nachahmer haben es dann schon schwieriger. Deren minimaler marktgängiger Funktionsumfang ist durch den Marktführer gesetzt, sofern sie nicht besondere eigene Innovationen zufügen können. Andererseits ist es ab der zweiten Produktversion prinzipiell wieder einfacher, inkrementell zu arbeiten.

Typische Herausforderungen für diese Projektart sind:

• Die Endkunden und Endbenutzer sind nur indirekt zu beteiligen;
• sie sind einflussarm;
• repräsentative Beta-Testsituationen sind zu schaffen;
• eine inkrementelle Lieferung und sinnvolle Teillösungen sind zu schaffen.

Koordinator

Die Gesamtverantwortung für ein Vorhaben verbleibt beim Auftraggeber. Er entwickelt aber nicht mit, sondern vergibt dafür Aufträge an externe Lieferanten. Die Eigenschaften sind ähnlich wie beim Gewerk, wobei der Auftragnehmer wichtige koordinierende und überwachende Aufgaben verantwortet, vor allem dass sich die Gewerke in einer (bestehenden oder durch andere Gewerke weiterentwickelten) Systemlandschaft integrieren und betreiben lassen.

Damit verbleibt ein signifikantes Risiko beim gesamtverantwortlichen Auftraggeber. Es kann ihm passieren, dass alle Zulieferer beanstandungsfrei liefern und trotzdem die Gesamtlösung nicht zum Laufen kommt, weil er Schnittstellen oder Rahmenbedingungen unzureichend koordiniert oder spezifiziert hat. Ein Beispielszenario für diesen Projekttyp wäre ein Versandhändler, der eine neue Bestellverwaltungssoftware vom externen Anbieter A herstellen lässt, die in einer Hard- und Softwareumgebung laufen soll, die der externe Anbieter B betreibt.

Das Versagen eines Einzellieferanten kann das Gesamtsystem gefährden. Einzelne Mängel haben das Potenzial, unkalkulierbar große Negativwirkungen zu zeigen, da Workarounds und andere Risikominimierungsmaßnahmen gegebenenfalls wiederum mit anderen Lieferanten zu verhandeln sind.

Typische Herausforderungen für Koordinator-Projekte sind:

• Einzelverträge sind so zu gestalten, dass das Koordinationsrisiko minimiert wird;
• Rückstellungen und Puffer zur Behebung von Koordinationsfehlern müssen bereitgehalten werden;
• eine frühzeitige und regelmäßige Integration über Lieferantengrenzen hinweg.

Kooperative (Open Source)

An der Entwicklung einer Open-Source-Software sind gewöhnlich viele Personen oder Firmen beteiligt, die sich den Entwicklungsaufwand auf zumeist freiwilliger und jederzeit abbrechbarer Basis teilen und sich selbst kooperativ organisieren. Die Basis bilden lizenzrechtliche Vereinbarungen, technische Infrastruktur und die Verteilung von Rollen und Rechten. Eclipse ist ein Beispiel eines Open-Source-Projekts, das durch die Freigabe eines ursprünglich IBM gehörenden Produkts (Visual Age) entstand, das später in die rechtlich eigenständige Eclipse Foundation übergegangen ist.

Allerdings ist zu bedenken, dass normale, das heißt Nicht-Open-Source-Projekte manchmal einfach entscheiden, ihre Arbeitsergebnisse zu veröffentlichen, es aber ansonsten unverändert das gleiche Projekt ist. Deswegen ist der Begriff "Open Source" nicht immer das richtige Unterscheidungsmerkmal.

Besondere Eigenschaften kooperativer Projekte sind:

• Die Teilnehmer kennen sich oft nicht persönlich.
• In vielen Projekten gibt es eher weniger Schätzungen und Metriken.
• Es ist gewöhnlich transparent, wer etwas zu machen plant, aber weniger, wer tatsächlich wann wie intensiv an etwas arbeitet.
• Die Arbeit wird meistens nebenbei erledigt und kann auch mal ein paar Wochen liegen bleiben.

Viele erfolgreiche Open-Source-Projekte haben eine oder wenige Führungsfiguren, die dem Projekt eine klare Richtung geben, ansonsten fehlt oftmals die Erarbeitung oder Kommunikation einer Vision.

Typische Herausforderungen für kooperative Projekte sind:

• unstete und weniger zuverlässige Verfügbarkeit und Kapazitäten der Beteiligten;
• uneinheitliche Qualität der Arbeitsergebnisse, Ergebnisse werden öfter auch mal wieder verworfen beziehungsweise nicht akzeptiert;
• die Selbstverpflichtungen der Teilnehmer sind oft anders als in anderen Projektarten;
• die Kommunikation komplexer Sachverhalte ist aufwendiger und anfälliger.

Fazit

Fazit

Jedes Projekt ist anders und hat andere Herausforderungen. Scrum wiederum ist ein Rahmenwerk, dass nicht viele Rollen, Artefakte und Arbeitstreffen (Prozesselemente) beschreibt, diese aber weitgehend bedingungslos einfordert. Alle unternehmens- und projektspezifische Varianz spielt sich vor allem in dem Bereich ab, den Scrum (bewusst) ausspart.

Insofern ist Scrum einerseits streng, gibt andererseits aber auch viel Gestaltungsraum. Jedes Projekt wiederum ist individuell, trotzdem gibt es immer wieder Gemeinsamkeiten, die sich vor allen an der Art des Projektes festmachen lassen. Deswegen ist es bei der Diskussion über die konkrete Ausgestaltung von Scrum-Projekten nicht nur nützlich, sondern geradezu notwendig, die jeweilige Projektart zu benennen, um zielgerichteter und effizienter darüber zu diskutieren und kontextspezifisch Best Practices auszutauschen.

Dieser Artikel soll terminologisch und inhaltlich eine Basis hierfür bilden.

Bernd Oestereich
ist Inhaber der oose Innovative Informatik GmbH und Autor zahlreicher international verlegter Fachbücher.

Literatur

1. Gerhard Wohland; Denkwerkzeuge der Höchstleister; Murmann-Verlag, 2007
2. Bernd Oestereich; Agiles Requirements Engineering; dpunkt-Verlag, 2010 (in Vorbereitung)

(ane [1])

URL dieses Artikels:
https://www.heise.de/-1074852

Links in diesem Artikel:
[1] mailto:ane@heise.de

Copyright © 2010 Heise Medien