triplecore-logotriplecore
  Zurück zur Blog-Übersicht

Ziele und Commitments

Dieser Artikel ist Teil einer Serie. Weitere Artikel beschäftigen sich mit Agile Leadership, Engineering Teams, Wissensaustausch, OKRs.

Vorhängeschlösser an einer Brücke als Symbol für Commitments

Agile Arbeit als Tauschgeschäft

Mein Credo ist: Agiles Arbeiten ist ein Tauschgeschäft mit hohen Einsätzen.

Das Team gibt regelmäßig die Verpflichtung ab, bestimmte Ziele zu erreichen. Durch die agil-übliche Transparenz kann jeder permanent sehen, wie der Stand der Zielerreichung ist. Im Gegenzug bekommt das Team hohe Eigenverantwortung und kann seine Arbeit selbstständig organisieren.

Die Stakeholder geben Kontrolle ab (siehe dazu meinen  Artikel über Agile Leadership) und bekommen im Gegenzug die Möglichkeit, auf Veränderungen schnell reagieren zu können. Zusätzlich bekommen die Stakeholder aufgrund der Selbstverpflichtung der Teams verlässliche(re) Vorhersagen, wann Funktionalitäten fertig umgesetzt sind.

Wirtschaftliche Zusammenhänge

Das Gesamtverständnis des Produktes ist hilfreich für den Erfolg als Team. Dieses Gesamtverständnis lässt sich über Big Picture Event Stormings, regelmäßige Alignment Meetings und im Rahmen von Quartalsplanungen herstellen.

Zu einer guten Review gehört für mich, wenn immer wieder die Frage gestellt und beantwortet wird, in welche Richtung und in welchen Schritten sich das Gesamtprodukt weiterentwickelt. Es ist ein Zeichen eines selbstbewussten Teams, wenn aus dem Team diese an die Stakeholder gestellt wird. Gesunde agile Kultur zeichnet sich dadurch aus, dass auf Augenhöhe diskutiert wird - die Stakeholder nehmen Ideen aus dem Team auf, das Team akzeptiert wirtschaftliche Herausforderungen und integriert sie kreativ in die Entwicklungsarbeit.

Stakeholder, die Sales-Organisation und die Nutzer des Produktes liefern sehr wertvolle Beiträge zum Produktverständnis im Team. Ladet sie regelmäßig (aber bitte nicht immer) in Meetings mit dem Team ein. Ich habe nach solchen Veranstaltungen von den Engineers sehr oft das Feedback bekommen, dass das sehr hilfreich war.

Scrum Guide 2020 Der:die Product Owner:in ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.”

Scrum bleibt relativ abstrakt bei den wirtschaftlichen Zusammenhängen. Nichtsdestoweniger haben viele Produkte das Ziel, mit ihnen Umsatz zu machen. Alle Produkte, mit denen ich bisher zu tun hatte, haben Kosten verursacht: Personalkosten und Infrastruktur als Minimum.

Ich finde es immer sinnvoll, die wirtschaftlichen Zusammenhänge darzustellen, zum Beispiel:

  • Woher kommt der Umsatz? Wofür zahlen die Kunden?
  • Was sind die hauptsächlichen Kostentreiber?

Viele Teammitglieder haben ein wirtschaftliches Verständnis und setzen das kreativ in der Produktentwicklung und im Support ein. Das hilft dabei, künstliche Optimierungen zu vermeiden: Ein Entwicklungsaufwand von 5000€, um einen Container (Server) mit Kosten von 100€ pro Monat einsparen zu können, rechnet sich erst nach 50 Monaten. Wer weiß, wie die Produktarchitektur in gut vier Jahren aussieht?

Erwartet aber nicht, dass jeder kaufmännisch denkt. Engineers sind in ihrer Rolle, weil sie sich für Technik interessieren.

Roadmaps

Roadmaps helfen dabei, den Überblick nicht zu verlieren. Roadmaps enthalten – immerhin sind wir im agilen Prozess - keine Detailplanung, aber sie vermitteln eine Idee, was in 3, 6 oder, 12 Monaten auf das Team zukommt.

Roadmaps sollten vom Team entwickelt werden. Eine Roadmap, die von den Stakeholdern oder vom Product Owner vorgegeben wird, haben meine Teams immer viel weniger als Verpflichtung wahrgenommen als gemeinsam evaluierte und entwickelte Roadmaps. “Wir haben das doch beschlossen” wirkt viel mehr als “die da oben wollen, dass wir das tun”. Roadmaps bilden die erste Stufe des gemeinsamen Commitments, das in den Sprintzielen konkretisiert und vertieft wird.

Teilt die Roadmap in drei Bereiche auf: Features, Architektur, Technologische Schulden. Nehmt dazu die Quadranten aus der Grafik als Orientierung. Die horizontale Achse zeigt aus der Vergangenheit in die Zukunft, die vertikale Achse unterscheidet zwischen Geschäft und Technologie. Der vierte Quadrant, Support, muss nicht auf die Roadmap. Bugs lassen sich nicht planen.

Vier Quadranten: Neue Funktionen 60%, Architektur-Innovationen 20%, Support 10%, Technologische Schulden 10%

Signifikante Abweichungen können an der Entwicklungsphase liegen. Neue Produkte haben wenig technologische Schulden und brauchen noch keine Architekturinnovationen. Bei gereiften Produkten sind Abweichungen ein Achtungssignal. Ein hoher Support-Anteil deutet auf Probleme in der Qualität, Stabilität, Performance hin. Dazu gibt es bald einen separaten Artikel. Hohe technologische Schulden brauchen Aufmerksamkeit, sonst wird das Produkt unwartbar.

Epics

Epics sind hier nicht ausschließlich auf Ebene des Story Tellings durch den Product Owner gemeint. Ich hätte auch Themen oder Building Blocks oder ähnliches schreiben können. Gemeint sind inhaltlich zusammengehörige Sammlungen von Stories oder technischen Tasks.

Arbeitet als Team nicht an zu vielen Themen gleichzeitig. Meine Zielsetzung ist meist ein Feature-Epic in Umsetzung und ein größerer Architekturumbau. Im Optimalfall beschäftigen die sich mit den gleichen Bereichen im Code, das klappt leider nicht immer. Dazu kann man noch ein Epic in der Discovery-Phase haben, mit wenigen Stories als Proof-of-Concept oder alternativ die technische Evaluierung einer Architektur-Innovation.

Zu viele Themen parallel führen dazu, dass das Ziel nicht mehr klar ist. Außerdem besteht die Gefahr, dass Themen ewig weiter laufen und nie beendet werden. Die Teams mit denen ich arbeite sind immer hochzufrieden, wenn sie ein Epic oder ein Refactoring abschließen können - gönnt euren Teams auch dieses Erfolgserlebnis.

Sprintziele

Das Sprintziel ist eine gemeinsame Verpflichtung des Teams für den Sprint. Es muss ernst genommen werden. Achtet im Daily Scrum oder in euren regelmäßigen Standups darauf, ob die Verpflichtung eingehalten werden kann. Sprecht über Gegenmaßnahmen, falls das Ziel in Gefahr ist. Das Sprintziel ist eine Verpflichtung des Teams. Es darf nicht von Product Owner, Agile Coach, Engineering Manager, … vorgegeben werden.

Das Sprintziel drückt keine Tätigkeit, sondern ein Ergebnis aus. Besser: “Rechnungsfilter sind in der Buchhaltung produktiv.” statt “In der Buchhaltung werden Rechnungen filterbar, Transaktionen importier- und persistierbar gemacht und Kontoauszüge dargestellt.”

Das Sprintziel muss keinen perfekten Zustand beschreiben. Besser:  "Entscheidung über das Konzept zu den Maus-Interaktionen anhand eines ersten Prototyps getroffen” statt “Wir arbeiten an den Maus-Interaktionen.”

Das Sprintziel ist ein Ziel. Singular. Besser: “Umsatzsteuer für Schweizer:innen produktiv” statt  “Bei der Website geht es mit Login weiter. Schweizer:innen bekommen Umsatzsteuer. Accounts werden automatisch für die Suche importiert. Marie macht Weiterbildung. Die Vorhaben von der letzte Retro werden im Scrum- Prozess berücksichtigt.” Diese Regel halte ich gelegentlich selbst nicht ein. In größeren Teams werden häufig in einem Sprint mehrere Ziele erreicht. Dann sind es aber höchstens zwei Ziele.

Das Sprintziel muss nicht die größte Story enthalten. Es ist in Ordnung, wenn eine kleine Weiterentwicklung des Produktes als Ziel definiert wird und das aufwändige, sehr wichtige Refactoring im Sprintziel nicht erwähnt wird, wenn unsicher ist, ob es deployt werden kann.

Wenn ein Team an mehreren Produkten arbeitet, muss das Sprintziel nicht immer alle Produkte umfassen. Fragt euch gemeinsam: was ist am wichtigsten. Besser: “CoolTool 2.0.1 Release Finalization” statt “1. CoolTool 2.0.1 Release Finalization! 2. Have a common generalized implementation of a workflow step in the OtherTool for taking screenshots. 3. OldTool - Plate optimization validation”

Das Sprintziel am Ende des Sprints Schaut am Ende des Sprints auf das Sprintziel und redet darüber, ob es erreicht wurde. Bei Scrum ist das für mich ein Thema für das Review-Meeting. Bei größeren Abweichungen schlage ich das Sprintziel für 10 Minuten als Thema für die Retrospektive vor. Wichtige Sprintziele, wie “Migration auf Suchmaschine Version 8 abgeschlossen”, feiern wir außerhalb des üblichen Meeting-Kanons.
Hans-Christian Pahlig - 12.2.2023