Suche
Grundlegende Regeln für die Projektlaufzeit

Starr trifft auf agil: Agile Entwicklung als Dienstleistung

Reginald Rink

© Shutterstock / Rudenkois,  Toonbst, S&S Media

Auch die immer noch schwergewichtige Old Economy setzt heutzutage bei der Entwicklung mobiler Apps auf agile Vorgehensmodelle. Während der Projektverantwortliche auf Kundenseite durchaus agil denkt, ist der Einkauf häufig noch von der alten Schule und fordert unzeitgemäße Rahmenbedingungen. So sieht sich das Entwicklungsteam des ausführenden Dienstleisters trotz unzureichender Spezifikationen und unklarem Leistungsumfang teils mit einem festen Liefertermin konfrontiert. Um bei der Abnahme Überraschungen zu vermeiden, gilt es, während der Projektlaufzeit ein paar grundlegende Regeln zu beachten.

Die meisten Agenturen im Web- und Mobile-Bereich setzen für die Realisierung von Kundenprojekten auf agile Entwicklungsmethoden. Aber auch klassische Softwaredienstleister haben längst Scrum als effizientes und schnelles Vorgehensmodell für sich entdeckt. Die alltäglichen Probleme von Scrum in der Theorie und wie es im tatsächlichen Alltag gelebt wird, sind vielseitig diskutiert und überwiegend gelöst worden. Doch funktionieren die eigenen Lösungen nur, wenn man in seiner Umgebung bleibt, und greifen nicht mehr zwingend, wenn der agile Dienstleister im Rahmen eines Softwareprojekts mit dem schwergewichtigen Unternehmen der Old Economy zusammenarbeiten muss.

Schnell wird gegenseitig aufeinander geschimpft. So klagt der Kunde über nicht eingehaltene Liefertermine und überschrittene Budgets und die Entwickler auf Agenturseite rollen nur noch die Augen über unklare Spezifikationen und sich stetig ändernde Anforderungen. Wie so häufig liegt die Wahrheit meist irgendwo in der Mitte. Die Probleme haben in der Regel schon beim Vertragsabschluss den Lauf der Dinge genommen, als von falschen Annahmen ausgegangen wurde oder zu wenig über das richtige Vorgehens- oder Abrechnungsmodell für das umzusetzende Projekt nachgedacht und gesprochen wurde. So gilt es, sich vorab bereits die Rahmenbedingungen näher anzuschauen und zu klären.

Bestimmung der Spielregeln

Da sich Softwareprojekte auf viele Weisen angehen und lösen lassen, sollte man sich vorab über das Vorgehensmodell, also die Spielregeln, Gedanken machen. Nimmt man Monopoly als Beispiel, hält der Nutzer ein klares und ausführliches Regelwerk in den Händen. Doch wie bei allen Brettspielen, die bereits seit vielen Jahren am Markt sind, haben sich häufig sogenannte Hausregeln entwickelt. Spielt man das erste Mal mit neuen Teilnehmern, gilt es genau diese Abweichungen vom offiziellen Regelwerk vorab zu identifizieren und abzustimmen, um später unangenehme Überraschungen zu vermeiden.

Weiterhin ist im Umgang mit schwergewichtigen Konzernen hilfreich zu verstehen, woher das Unternehmen kommt und welche Prozesse es bislang eingesetzt hat – und vielleicht immer noch in den Köpfen der IT-Verantwortlichen stecken. Denn auch wenn das Wasserfallmodell in der Softwareentwicklung an Verbreitung und Bedeutung verloren hat und im Agenturgeschäft kaum vorstellbar wäre, bietet es dennoch einige Vorteile. Jedes Projekt- und vor allem Entwicklungsteam muss sich zunächst aufeinander einspielen. Gerade auf Dienstleisterseite werden Teams jedoch aufgrund unterschiedlicher Projektlaufzeiten und Teamkonstellationen häufig neu zusammengestellt. Das Wasserfallmodell ist in seiner Anwendung klar und einfach zu verstehen und dadurch schnell zu erlernen. Eine lange Eingewöhnungs- und Verständnisphase entfällt daher, und das Team ist zügig in der Lage, die möglichst volle Leistung zu bringen. Wenn der Kunde nun mit dieser Erwartungshaltung an den Dienstleister herantritt, mag er vielleicht Schwierigkeiten mit rein agilen Herangehensweisen wie Scrum haben.

Hybride Modelle nutzen

Aus diesem Bedarf heraus haben sich hybride Modelle entwickelt, um die Vorzüge des Wasserfallmodells mit der Flexibilität agiler Softwareentwicklung zu verbinden. Es gibt zahlreiche Bezeichnungen wie Agiler Wasserfall, Wet agile oder Agile-Waterfall Hybrid. Letztere wurde von Erick Bergmann und Andy Hamilton von Schneider Electric auf der Agile 2013 vorgestellt und spiegelt die Anforderungen von Unternehmen wider, die in der Hardwareproduktentwicklung tätig sind.

Während Softwareagenturen im mobilen Bereich auf den ersten Blick vielleicht wenig Berührungspunkte zu Hardwareherstellern haben mögen, ist die Erwartungshaltung ihrer Endkunden oft die gleiche – nämlich die Produkte mittels Apps steuern zu können. Das vernetzte Haus, realisiert mittels Thermostaten, Reglern und Steuerungseinheiten, ist dafür ein gutes Beispiel. Unternehmen der Energiebranche oder die Hardwarehersteller selbst stehen dabei häufig vor dem Problem, nicht das nötige Know-how für die Entwicklung einer mobilen App zu besitzen. Dienstleister in diesem Bereich stehen damit vor dem Problem, die agile Entwicklung mit harten Releaseterminen für die Hardware zu vereinen. Eine verpasste Deadline eines smarten Thermostats mag für den Außenstehenden verschmerzbar klingen. Spätestens wenn aber das neue Fahrzeugmodell nicht ausgeliefert werden kann, weil die Navigationssoftware nicht fertig wurde, wird das Problem offensichtlich. Der von Bergmann und Hamilton skizzierte Hybrid ist zwar lediglich einen Kompromiss beider Welten, ermöglicht aber die Zusammenarbeit zwischen Hersteller und Dienstleister.

Die Entwicklung der Hardware auf Kundenseite sowie das Produktmanagement folgen dabei weiterhin dem Wasserfallmodell, die Realisierung der Software erfolgt agil. Hierbei ist aber eine enge Zusammenarbeit zwischen Produktmanagement und Entwicklung eine zwingende Voraussetzung. Die Entwicklung begleitet alle Phasen und unterstützt bereits bei der Definition von Anforderungen und Umfang durch regelmäßiges Feedback und bereitgestellte Softwarezwischenstände.

W-JAX 2018 Java-Dossier für Software-Architekten

Kostenlos: 40+ Seiten Java-Wissen von Experten

Sie finden Artikel zu Enterprise Java, Software-Architektur, Agilität, Java 11, Deep Learning und Docker von Experten wie Kai Tödter (Siemens), Arne Limburg (Open Knowledge), Manfred Steyer (SOFTWAREarchitekt.at) und vielen weiteren.

Eine große Herausforderung ist das Backlog-Management. Während im agilen Ansatz eine reine Priorisierung ausreicht und das Team das Backlog von oben nach unten abarbeitet, sind bei der Entwicklung mehrerer Projekte unterschiedliche Workstreams zeitgerecht zu bedienen. Das Backlog wandelt sich dadurch zu einer Softwarereleaseplanung mit fixen Terminen. Auch hier ist eine enge Abstimmung zwischen Produktmanager und Entwicklung nötig. Letztere muss die vorgegebenen Termine auf Machbarkeit prüfen und ein Commitment für einen bestimmten Liefertermin abgeben.

Die Vertreter des Wasserfallansatzes lösen sich somit bei dem agilen Wasserfallhybriden von fixen Erwartungen an das Endergebnis bereits zu Beginn der Projektphase, erhalten aber im Gegenzug dazu die Möglichkeit, auf nötige Anpassungen, die z. B. durch geänderte Marktsituationen oder Kundenfeedback entstanden sind, reagieren zu können. Die Entwicklung gibt auf ihrer Seite Freiheiten auf, arbeitet gegen einen festen Terminplan und akzeptiert Kostenprognosen sowie Risikobewertungen des Projekts. Der hybride Ansatz wird bestimmt nicht die erste Wahl sein, kann aber im Zusammenhang mit Hardwareentwicklung oder schwergewichtigen IT-Abteilungen eine funktionierende Alternative zum rein agilen Scrum oder Kanban sein.

Wann ist Zahltag?

Haben sich Kunde und Dienstleister auf die Vorgehensart bei der Umsetzung des Softwareprojekts geeinigt, steht man schon vor der nächsten Baustelle. Denn ebenso entscheidend wie die Wahl des Vorgehensmodells für den Projekterfolg ist, kann für den Dienstleister die Wahl des Abrechnungsmodells für den finanziellen Erfolg sein.

Wenn der Projektumfang zu Beginn des Projekts vollständig spezifiziert vorliegt, birgt ein Festpreismodell relativ geringe Risiken für den Dienstleister. Eventuelle Unbekannte werden mittels Risikopuffer ausgeglichen. Etwaige Änderungen werden über Change Requests abgerechnet. Soweit die Theorie. Problematisch wird es nämlich, wenn – wie so häufig – der Projektumfang anfänglich nicht vollständig spezifiziert ist und der Kunde dennoch nach Festpreis abrechnen möchte. Oft ist dieser Wunsch durch den Einkauf des Kunden motiviert, der nur ein bestimmtes Budget seiner Produktabteilung zur Verfügung stellt und dennoch vertraglich klar geregelt haben möchte, was er für sein Geld erhält.

Denn natürlich erwartet ein Kunde, der heutzutage eine schwammigere Spezifikation bereitstellt, vom Dienstleister aufgrund seines agilen Vorgehens, auf Anpassungen im Projektumfang z. B. durch eine geänderte Marktsituation flexibel reagieren zu können. Da der agile Ansatz Änderungen begrüßt, bleibt dem Auftragnehmer nichts anderes übrig, als jede Anforderungsänderung detailliert zu protokollieren und zu versuchen, diese als Change Request in Rechnung zu stellen. Die Beweispflicht liegt dabei in der Praxis oft beim Dienstleister, während der Kunde versucht, Änderungen ohne Zusatzkosten unterzuschieben. Nicht aus Boshaftigkeit, sondern schlichtweg wegen einer anderen Vorstellung hinter einem eingangs zu grob beschriebenen Feature.

Somit scheint das für den Dienstleister auf den ersten Blick beste Modell, die Abrechnung auf Basis von Time and Material (T&M) zu sein. Hierbei wird dem Kunden jede geleistete Stunde und eingesetztes Material in Rechnung gestellt. Dieses Modell verlangt auf Kundenseite ein enormes Vertrauen, da die tatsächlich entstehenden Projektkosten zu Beginn höchstens als grobe Aufwandsschätzung vorliegen, aber vom Dienstleister nicht verbindlich eingehalten werden müssen. Auch wenn die realen Aufwände niedriger als eingangs kalkuliert ausfallen können, überwiegt auf Kundenseite meist die Angst von explodierenden Kosten.

Ein oft unterschätztes Risiko auf Dienstleisterseite sind mögliche Leerlaufzeiten. Sollte das Projekt z. B. durch Verzögerungen oder fehlende Beistellungen des Kunden pausieren müssen, können diese Unterbrechungen häufig nicht in Rechnung gestellt werden und verursachen somit Kosten, da das Team kurzfristig nicht anderweitig eingesetzt werden kann.

Story Point Billing Model: erst schätzen, dann zahlen

Ein alternatives Abrechnungsmodell mit der Bezeichnung Story Point Billing Model hat Prabhakar Gumma von Tata Consultancy im Jahr 2013 der Scrum Alliance Community vorgestellt. Nach diesem Ansatz erhält jeder Story Point einen festen finanziellen Gegenwert, und der Kunde bezahlt am Ende jedes Sprints nur die Anzahl abgenommener Story Points.

Zur Berechnung des Gegenwerts eines Story Points erstellt das Team Beispielstorys, schätzt sie in Story Points und stellt die Berechnung dem Kunden transparent zur Verfügung. Die Annahme ist hierbei, dass dasselbe Team vergleichbare Storys aus dem umzusetzenden Projekt ähnlich schätzen wird. In einer Pilotphase von einigen Sprints werden die Kosten der eingesetzten Ressourcen auf die gelieferten Story Points umgerechnet und sich mit dem Kunden auf einen Preis pro Story Point geeinigt. Bis zur der Einigung schlägt Gumma die Abrechnung auf Basis von Time and Material vor. Der Kunde wird beim Story Point Billing Model in die Verantwortung genommen, klare Akzeptanzkriterien für seine User Stories zu definieren, und das Team muss sicherstellen, alle Abhängigkeiten rechtzeitig identifiziert zu haben.

Generell ist dies ein vielversprechender Ansatz, da nach der Festlegung des Preises pro Story Point gute und qualitativ hochwertige Arbeit belohnt wird. Problematisch ist allerdings zunächst die lange Startphase bei neuen Kunden, ehe von Time-and-Material- auf Story-Point-basierte Abrechnung umgestellt werden kann. Darüber hinaus können die Beispielstorys von Team A nicht für Team B verwendet werden. Rein theoretisch müssten neue Vergleichsstorys angelegt und geschätzt werden, sobald Teammitglieder ausscheiden oder durch neue ersetzt werden. Da nur vollständig abgenommene User Stories bezahlt werden, kann der Dienstleister für den laufenden Sprint geplante, aber z. B. wegen fehlender Bereitstellungen des Kunden blockierte Storys, nicht in Rechnung stellen, auch wenn unter Umständen bereits Aufwände in das betroffene Feature geflossen sind. Diese Methode setzt also auf beiden Seiten ein solides Grundvertrauen in den jeweiligen Partner voraus, kann aber bei bereits existierenden Geschäftsbeziehungen eine valide Alternative sein.

Inkrementell abrechnen

Bei der inkrementellen Abrechnung stellt der Dienstleister eine Teamkapazität pro Sprint bereit, und das Team sichert eine Anzahl Story Points zu, die als Sprintziel geliefert werden müssen. Wird die Zahl wegen fehlender oder unvollständiger User Stories verfehlt, gibt es entweder einen prozentuellen Strafabzug, der vor Projektbeginn individuell mit ausgehandelt wird, oder das Team arbeitet die Missstände im Folgesprint zusätzlich auf eigene Kosten nach.

Um die Rechnungsstellung nach jedem Inkrement für den Dienstleister nicht zu sehr zu verzögern, hat der Kunde nach dem Review-Meeting einen Sprint lang Zeit, seine eigene Qualitätssicherung das gelieferte Inkrement prüfen zu lassen. Fehler, die in diesem Zeitraum gefunden werden, müssen auf Kosten des Dienstleisters im Folgesprint oder in einer Stabilisierungsphase behoben werden. Fehler, die vom Kunden erst nach der Validierungsphase gemeldet werden, werden als Tasks ins Backlog aufgenommen, mit Story Points versehen und auf Kosten des Kunden in nachfolgenden Sprints behoben.

Lesen Sie auch: Agil im Gehirn: Darum funktioniert Agile Software-Entwicklung

Das inkrementelle Abrechnungsmodell setzt gegenseitiges Vertrauen sowohl beim Dienstleister als auch beim Kunden voraus und scheitert, sobald ein Partner versucht, einen Vorteil daraus zu ziehen. So könnte Ersterer bewusst mehr Aufwände schätzen, um sich Puffer zu erkaufen und der Kunde auf der anderen Seite das vom Team geplante Sprintziel jedes Mal als zu niedrig einstufen und sich auf keinen Dialog einlassen. Aber ist man an diesem Punkt angekommen, sollte man ohnehin die Partnerschaft überdenken und das Projekt gegebenenfalls vorzeitig abbrechen.

Bei erfolgreicher Anwendung erhält der Kunde vor Projektstart zwar lediglich ein indikatives Angebot auf Basis der bekannten Anforderungen, hat aber im Laufe des Projekts die Möglichkeit, Anpassungen vorzunehmen. Zusätzlich bekommt er auf Sprintbasis ein konkretes Preisschild für die gewünschten Features.

Schöne heile Welt

Sind sich schlussendlich beide Seiten über die Form der Beauftragung und des Vorgehensmodells einig, steht der erfolgreichen Umsetzung fast nichts mehr im Weg. Aber wenn auf dem Papier alles so gut aussah, warum kommt es dann immer wieder bei der Durchführung zu Überraschungen und Problemen? Selbst im klassischen Scrum-Team (Abb. 1) lauern die üblichen Gefahren: mangelnde Kommunikation, ein schwacher oder zu starker Product Owner auf Kundenseite oder ein Entwicklungsteam, das vermeintlich seine Storys nicht fertig bekommt.

Abb. 1: Ein klassisches Scrum-Team mit dem Kunden als Product OwnerGerade im Agenturumfeld ist eines der häufigsten Probleme die Existenz eines Schattenprojektmanagers. Dieser PM versteckt sich manchmal hinter der Rolle des Scrum Masters, manchmal hat er aber auch gar keine aktive Rolle im Team. Dennoch taucht er immer wieder auf und nimmt Einfluss auf das Team und seine Arbeit. Denn spätestens, wenn es um die Bestimmung des Projektstatus für das interne Reporting, das Stellen der nächsten Rechnung und potenzielles Up- oder Cross-Selling geht, tritt er aus seinem Schatten hervor. Neben einer klaren Trennung von PM und Scrum Master kann hier die konsequente Verwendung von Tools wie JIRA Abhilfe schaffen. So kann sich der PM alle benötigten Informationen ohne Störung des Teams selbstständig besorgen und dadurch etwaigen Druck auf Fertigstellungen vermeiden. Weiterhin sollten auch im Agenturumfeld die Entwicklungsteams möglichst stabil und konstant sein, um Kontextwechsel und Entwicklerräubereien für andere Projekte zu vermeiden. Denn man wird keine zufriedenstellende Effizienz erreichen können, wenn ein Entwickler jeden Tag wie ein Feuerwehrmann von Projekt zu Projekt springt.

Obacht vor dem Schein-PO

Es mag Situationen geben, in denen sich Kunde und Dienstleister einig sind, das Projekt nach einer agilen Methode wie Scrum zu entwickeln, der Kunde aber nicht in der Lage ist, den Product Owner zu stellen – sei es aus Zeitgründen oder fehlender Qualifizierung. Die ausführende Agentur hilft im Sinne des guten Dienstleisters gerne aus und stellt den PO (Abb. 2).

Abb. 2: Der Product Owner auf Agenturseite

So wird voller Elan gestartet, Sprints werden geplant, abgeschlossen und dem Kunden gezeigt. Doch dann kommt der Tag, an dem im schlechtesten Fall das Budget aufgebraucht, im Bestfall das Projekt entsprechend der Anforderung abgeliefert wird. Plötzlich verweigert der Kunde die Abnahme und hat zahlreiche Änderungen identifiziert, die seiner Meinung nach Teil der ursprünglichen Projektbeauftragung waren.

Dies tritt häufig dann auf, wenn der Verantwortliche auf Kundenseite für das umzusetzende Projekt die Rolle des Projektmanagers innehat, aber sich mit Scrum sowie der Rolle und Verantwortung des POs nicht ausreichend auseinandergesetzt hat. Obwohl er an allen Sprint Reviews teilgenommen hat und gewiss auch das ein oder andere Feedback gegeben hat, hat er die Reviews nicht als Teilabnahme verstanden und sein Feedback auch nicht als bewilligten Change Request, der sein Budget belastet. Der PO auf Agenturseite ist in seinen Augen lediglich der Projektmanager, der die Arbeit des Teams in Sprints organisiert. Es ist natürlich völlig legitim, wenn der Dienstleister den Kunden in Form eines POs unterstützt, wichtig ist hierbei aber spätestens im Projekt-Kick-off die Rolle mit all ihren Befugnissen und Pflichten sowie auch die Bedeutung der Sprint-Meetings detailliert zu erklären.

Viele Köche verderben den Brei

Der letzte Fall schildert ein Szenario aus dem Bereich Automotive, in dem gemeinsam mit dem Dienstleister ein Softwareprojekt agil realisiert werden soll (Abb. 3). Jeder PO auf Seite des Kunden verantwortet seinen eigenen Bereich, z. B. Features, UX oder Schnittstellen, alle sind sie aber gleichwertig dem Projekt zugewiesen. Das Entwicklungsteam erhält somit keine klare Priorisierung, und Abhängigkeiten zwischen User Stories werden vorab nicht sauber aufgelöst. Dennoch ist kein PO befugt, weil teils nur als externer Consultant vom Kunden eingestellt, seine erstellten und vom Team gelieferten Aufgaben abzunehmen. Eine separate QA auf Kundenseite überprüft die Ergebnisse. Sie gibt dann dem gesamtverantwortlichen Kunden-PM ein Daumen rauf oder Daumen runter.

Abb. 3: Multi-Pos: jeder redet mit, keiner entscheidet

Verständlicherweise dauert dieser Prozess oft über einen Sprint hinaus, sodass der eigentliche Vorteil der agilen Entwicklung, Feedback sofort im Folgesprint einarbeiten zu können, verlorengeht oder technische Schulden aufgebaut werden. Wenn sich diese Komplexität nicht durch einen allein verantwortlichen PO lösen lässt, empfiehlt sich ein regelmäßiges Meeting aller POs und PMs sowohl auf Kunden- als auch auf Agenturseite. Darin können Entscheidungen schneller getroffen, Feedback beschleunigt und Probleme direkt adressiert werden. Kommen dann auch noch mehrere Dienstleister ins Spiel, eventuell getrennt nach Backend- und Frontend-Entwicklung, wird die Runde umso wichtiger, besonders im Hinblick auf die gemeinsame Roadmap- und Releaseplanung für einzelne Komponenten.

Lesen Sie auch: DevOps – erfüllt es die Erwartungen? Oder folgt auf den Rausch der große Kater?

Hier gilt dann vor allem der Vorsatz, keine falsche Scheu zu haben und im direkten Dialog mit Kunden und Partnern die Vorgehensweise da anzupassen, wo es nötig ist. Entscheidend ist auch, in einem gemeinsamen Kick-off mit allen Beteiligten vorab alle Probleme offen anzusprechen und Fragen zu klären. Denn am Ende wollen alle Seiten das Gleiche: Ein erfolgreiches Softwareprojekt in Time und in Budget abschließen.

Geschrieben von
Reginald Rink
Reginald Rink
Reginald Rink verantwortet als Head of Product das Produktportfolio der RE’FLEKT GmbH und unterstützt aufgrund seiner langjährigen Erfahrung als Projektmanager, Product Owner und Scrum Master Unternehmen und Teams bei der Einführung agiler Prozesse.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: