„Für Scrum-Teams sind User Stories fertig, wenn vom Team nichts mehr daran getan werden muss. Was passiert aber, wenn Betrieb und Wartung dazugehören? Können wir dann je fertig sein?“
… ist die für den Product Owner (PO) spätestens im Sprint Review zentrale Frage, mit der er wissen will, ob er den Geschäftswert einer Story geliefert bekommt oder nicht. Weil die Frage (und auch die Antwort darauf ;-)), so wichtig ist, beschreibt Scrum die Definition of Done (DoD) als (Merk-)Liste von Fertigstellungskriterien. Dadurch hat das Scrum Team eine einheitliche Sicht auf die Bedeutung von „Done“.
Liefert „Done“ einen Mehrwert?
Einem PO ist dabei aber natürlich klar, dass der Geschäftswert nicht durch den Status „Done“ der Story, sondern letztendlich beim Kunden selbst realisiert wird. Lohnt es sich, den Aspekt der Auslieferung in den Entwicklungsprozess mit aufzunehmen? Welche Auswirkungen oder Vorteile hätte dies? Könnten wir das Deployment nicht einfach in der DoD verankern? Es gibt Personen, die hierfür plädieren (z.B. in der „supercharged DoD“, die vollumfängliche Definition of Done)…
In Scrum werden User Stories im Review vorgestellt, wenn das Team der Meinung ist, sie sind „done“. Das umgesetzte Feature ist hier „potenziell auslieferbar“. Der für den Kunden interessanteste Status ist aber natürlich „produktiv“. Es ist möglich, dass das tatsächliche Ausliefern im Review angestoßen wird, wenn der Auslieferungsprozess entsprechend automatisiert ist. Dies ist dann eine mögliche Umsetzung von Continuous Delivery (CD). Spätestens hier verlässt das Produktinkrement aber die Verantwortung vom Team, das Team braucht spätere Betriebsaufwände nicht in seiner Planung zu berücksichtigen.
Was kommt aber nach „Done“?
Ein anderer Ansatz belässt die Verantwortung auch zu späteren Zeitpunkten beim Team. Der Grundgedanke ist, dass die Experten für die Anwendung (das Team!) diese auch betreibt, wartet und damit vollumfänglich verantwortet („DevOps“).
Um eine unverzügliche Auslieferung zu ermöglichen, muss eben diese Verantwortung entsprechend verankert werden. Zum einen heißt das, dass das Team die Befugnisse bekommt, Betriebsaufgaben wahrzunehmen und zu organisieren. Zum anderen muss entsprechender Aufwand dann auch eingeplant werden. Dies sind Linientätigkeiten, deren Ablauf am einfachsten durch Kanban dargestellt und gesteuert werden kann. Kombiniert man das mit der Scrum-Entwicklung, lebt man DevOps durch Scrumban. Der Realisierungsanteil wird über das Sprint-Backlog transparent gemacht, Betrieb und Wartung der Anwendung über das Kanban-Board.
Entwicklung + Betrieb = Transparenz
Ein positiver Seiteneffekt ist, dass dem PO die Gesamtkosten für Entwicklung und Betrieb/Wartung transparent werden, von ihm eingeplant und gesteuert werden können. Konkurrieren Aufwände für fachliche Weiterentwicklung mit Wartungsaufwänden (z.B. für Automatisierung), kommen beide aus demselben Topf und müssen gegeneinander priorisiert werden, und zwar von derselben Person: dem PO. Mehr Transparenz geht kaum, haben wir hier also „fertig“?
So gut wie fertig… ein letzter Gedanke noch
Wenn ein Feature „fertig“ ist, warum bis zum Sprintende mit der Auslieferung warten? Den Kunden ein Feature eine Woche früher zur Verfügung zu stellen, kann einen deutlichen Unterschied ausmachen (wenn das Feature wichtig ist, und davon wird ausgegangen). Ausliefern im Sprint, ist das dann aber noch Scrum/Scrumban?
Bei Scrum/Scrumban will man am Sprintende eine Demo haben um etwas über das Produkt zu lernen, das kann ich auch mit bereits produktiven Features. Bei Kanban entsprechen diese Zeitpunkte den Kadenzen. Das ist für das umsetzende Team, bis auf die Namensgebung und etwaige Rollenbezeichnungen, dasselbe. Die Unterschiede liegen dann in Details und im Auge des Betrachters, oder ob ich eine grundsätzliche Präferenz habe und den Namen einfach behalten will.
Der wesentliche Punkt bleibt dabei aber:
Fertig ist ein Feature, wenn es dem Kunden einen Mehrwert liefert, denn Wertschöpfung entsteht ausschließlich beim Kunden.
Daraus ergibt sich für alle Beteiligten: Fertig haben wir, wenn der Kunde zufriedener ist.
