Kolumne

DevOps Stories: Sage mir, was du entscheidest, und ich sage dir … Über unterschiedliche Arten von Entwicklungsteams

Konstantin Diener

Lukas hat eine WhatsApp-Nachricht von seinem Cousin Robert bekommen. Robert arbeitet seit einiger Zeit bei einem IT-Dienstleister und hat sich vor ein paar Monaten mit Lukas auf einer Familienfeier über die Planung agiler Softwareentwicklungsvorhaben unterhalten. In seiner Nachricht hat er Lukas um einen Skype Call gebeten.

  • Lukas: „Hallo Robert, alles klar bei dir? Du hast geschrieben, dass du noch ein paar Fragen zur Entwicklung in agilen Teams hast und deswegen gerne mit mir sprechen möchtest.
  • Robert: „Ja, das stimmt. Wir hatten auf Silkes Hochzeit über viele Themen gesprochen, über die ich noch länger nachgedacht habe. Die Tipps, die du mir hinsichtlich der Entwicklungsplanung gegeben hast, waren sehr hilfreich. Einige andere Sachen aus unserem Gespräch bringe ich noch nicht mit der Arbeit in meinem Team zusammen und hätte da gerne auch ein paar Tipps von dir.“
  • Lukas: „Ah, ok, wenn ich dir helfen kann, werde ich es gerne tun.
  • Robert: „Du hast erzählt, dass Erik, euer Product Owner, dafür zuständig ist, Hypothesen über das Produkt und die Kunden zu erstellen und daraus zum einen passende User Stories abzuleiten. Außerdem priorisiert er diese Stories auch, korrekt?
  • Lukas: „Ja, das stimmt im Wesentlichen.
  • Robert: „Bei uns kommt mir der Produkt Owner immer eher wie ein Projektleiter im neuen Gewand vor, der die Anforderungen oder User Stories von den Stakeholdern bekommt. Die Stakeholder entscheiden auch im Wesentlichen über die Priorisierung der Stories. So setzen wir immer wieder Dinge um, die wir alle – inklusive des Product Owner – für unsinnig halten. Was mich auch oft an die Projektleiterrolle von früher erinnert, ist, dass die Stakeholder die Stories und die Priorisierung vorgeben. Wenn die Software aber nicht den gewünschten Erfolg hat, ist unser Product Owner bzw. wir als ganzes Team dafür verantwortlich.
  • Lukas: „Wir werden auch dafür verantwortlich gemacht, wenn das Produkt nicht den gewünschten Erfolg bringt, – bzw. Erik, unser Product Owner. Aber bei euch gibt es offenbar viel mehr Einmischung von außen. Es ist zwar lange her, dass ich in einem Projekt mit einem Projektleiter gearbeitet habe, ich sehe aber auch die Parallelen. Vielleicht hat es damit zu tun, dass wir MusicStore auf eigene Rechnung entwickeln und ihr im Wesentlichen im Auftrag von Geschäftskunden arbeitet.
  • Robert: „Ja, das könnte sein. Daran habe ich auch schon gedacht …
Abb. 1: Lukas beantwortet die Fragen seines Cousins per Skype

Abb. 1: Lukas beantwortet die Fragen seines Cousins per Skype

Delivery Teams sind reine Feature Factories

Der Scrum Guide sagt nur wenig über die Natur des Entwicklungsteams aus. Es soll unter anderem selbstorganisiert und cross-funktional sein, keine Subteams haben, und alle Teammitglieder sind gemeinsam für das Ergebnis verantwortlich.

Marty Cagan unterscheidet in einem Blogpost drei Arten von Entwicklungsteams. Eine verbreitete Form sind nach seiner Ansicht sogenannte Delivery Teams. Sie bestehen aus einem Product Owner und einer Reihe von Entwicklern. Das bedeutet, dass sie nicht wirklich cross-funktional und damit im Sinne des Scrum-Guides eigentlich noch nicht einmal richtige Entwicklungsteams sind. Die Rolle des Product Owner beschreibt er als Backlog-Administrator – schließlich muss diese Aufgabe irgendjemand übernehmen. Die Art der Arbeit in diesen Teams ist insgesamt darauf ausgerichtet, den Output zu maximieren. Eine Validierung von Hypothesen mit echten Kunden findet nicht statt. Für den Autor ist das nur eine neue Verpackung für ein Wasserfallvorgehen.

Aber ist das nicht etwas übertrieben? Vor allem, wenn der Autor auch die Teams im SAFe Framework dieser Kategorie zurechnet? Und dieser Ansatz trägt die Agilität sogar im Namen.

Softwareentwicklung beinhaltet immer die Koordination zwischen verschiedenen Tätigkeitsfeldern, wie z. B. fachlicher Analyse, Entwurf, UX- und Grafikdesign, Implementierung, Test und Dokumentation. Wenn das Delivery Team nur aus Entwicklern besteht, muss diese Koordination außerhalb des Teams stattfinden – meist in vor- oder nachgelagerten Schritten. Dabei handelt es sich um klare Eigenschaften eines Wasserfallvorgehens.

Feature Teams sind zumindest echte Scrum-Teams

Die zweite Kategorie von Teams ist genauso wie Delivery Teams auf die Erzeugung von Output wie Features oder Projekte ausgerichtet. Diese Features bekommt das Team nicht ganz so detailliert vorgegeben wie ein Delivery Team, sondern in der Regel in Form einer Roadmap. Cagan bezeichnet sie als Feature Teams.

Im Unterschied zu den Delivery Teams sind sie sehr cross-funktional besetzt. Neben Softwareentwicklern gehören ihnen z. B. auch Businessexperten, Designer, Tester und Betriebsmitarbeiter (Ops) an – alle Experten, die für die Lieferung eines Shippable Product Increment notwendig sind. Dadurch sind diese Teams deutlich autonomer als Delivery Teams. Sie können ohne Abhängigkeiten von anderen arbeiten und aufwendige Übergaben entfallen. Durch die vielen verschiedenen Expertisen im Team wächst auch viel eher ein gemeinsames Verständnis für den Kunden des Produkts und das Team übernimmt eher Verantwortung für den Produktbetrieb und die Stabilität [1].

Aber nicht nur die Ergebnisse eines Feature Teams sind viel stabiler, sondern auch das Team selbst. Dadurch, dass Feature Teams in der Regel über einen langen Zeitraum zusammenbleiben, vereinfachen sich Planung und Forecast, und ein gemeinsamer Arbeitsmodus bildet sich heraus.
Zusammenfassend kann man sagen, dass sich ein Feature Team viel besser auf die Lieferung von Features konzentrieren kann, die einen hohen Wert für den Markt haben. Die Time to Market gegenüber Delivery Teams sinkt drastisch.

Auch Delivery Teams beschränken sich aber auf die Optimierung des Outputs. Welche Features bzw. Projekte umgesetzt werden, entscheiden Personen außerhalb des Teams. Diese Teams arbeiten sozusagen für die Businessstakeholder. In dieser Situation befinden sich die Teams in Roberts Firma. Die Kunden der Firma geben eine Produktentwicklung in Auftrag, entscheiden aber selbst, welche Features sie für richtig halten.

Java Whitepaper

Gratis-Dossier: Java 2020 – State of the Art

GraalVM, Spring Boot 2.2, Kubernetes, Domain-driven Design & Machine Learning sind einige der Themen, die Sie in unserem brandneuen Dossier 2020 wiederfinden werden!

Empowered Product Teams haben auch die Verantwortung für den Produkterfolg

Laut Cagan existieren für ein Produkt vier maßgebliche Risiken (Kasten „Die vier Produktrisiken“). Zwei dieser vier Risiken können in einem Feature Team in Angriff genommen werden: Die Entwickler stellen die Machbarkeit (Feasability) des Produkts sicher und die Designer kümmern sich um die Usability. Das Team kann also dafür sorgen, dass die Features richtig gebaut werden.

Die vier Produktrisiken

Marty Cagan führt in seinem Blogpost vier Produktrisiken auf:

  • Value Risk: Werden die Leute das Produkt kaufen bzw. benutzen?
  • Usability Risk: Können die Benutzer das Produkt verwenden?
  • Feasibility Risk: Erlauben es die Fähigkeiten des Teams und die verwendeten Technologien, das Produkt in annehmbarer Zeit zu bauen?
  • Business Viability Risk: Wird die Lösung in jeder Hinsicht für unser Business funktionieren?

In postindustriellen Märkten ist es zunehmend wichtig, die Bedürfnisse der Kunden iterativ zu ermitteln. Das heißt, nicht nur die Features richtig zu bauen, sondern auch die richtigen Features zu bauen. Wenn ein Team auch die Verantwortung für diese Entscheidung hat, bezeichnet Cagan es als Empowered Product Team. Anders als Delivery Teams und Feature Teams werden sie nicht am Output, sondern am Outcome gemessen. Hier steht nicht im Vordergrund, möglichst viele Features zu liefern, die die Businessstakeholder sich wünschen, sondern die Bedürfnisse der eigentlichen Kunden zu ermitteln und zu befriedigen („The purpose of a product team in this sense is to solve problems in ways our customers love, yet work for our business.“). Im Gegensatz zu den anderen beiden Formen von Teams arbeiten sie also für die Endkunden, nicht für die Businessstakeholder.

Robert war verwirrt von den Dingen, die Lukas ihm aus dem MusicStore-Team erzählt hat. Lukas’ Schilderungen passten nicht wirklich zu dem, was er in den Teams in seiner Firma erlebt. Das liegt daran, dass Lukas in einem Product Team arbeitet. Erik, der Product Owner, stellt Hypothesen darüber auf, was die Endkunden für Bedürfnisse haben. Zu diesen Hypothesen entwickelt das Team kleine Produktinkremente und verprobt sie.

Mit dieser Erkenntnis ist Robert mit seinem Product Owner daran gegangen, seine Kunden im ersten Schritt mehr hinsichtlich der Priorisierung zu beraten und sukzessive von Hypothesen und Experimenten zu überzeugen.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: