Continuous Discovery in Scrum / Agile
Ich habe bereits darüber geschrieben, wie agile bzw. Scrum Produktteams Product Discovery und Product Delivery parallel laufen lassen. Außerdem habe ich darüber geschrieben, dass Teams in der Product Discovery manchmal gerne mit Timeboxing arbeiten.
In diesem Artikel möchte ich über den wachsenden Trend in Richtung Continuous Delivery und Continuous Discovery schreiben.
Die Idee von Continuous Delivery (dt. kontinuierliches Ausliefern) verbreitet sich immer mehr. Viele Teams haben in den letzten Jahren darüber geredet, aber mittlerweile gibt es auch Teams, die wirklich damit arbeiten.
Fast alle Produktteams arbeiten heutzutage mit kontinuierlichen Builds. Das Prinzip dahinter ist, dass es besser ist, auftretende Probleme eher früh als spät zu finden. Daher werden die Builds normalerweise initiiert, sobald Änderungen vorgenommen werden.
Einige Produktteams haben dieses Prinzip auf eine ganz neue Ebene gebracht. Sie haben gelernt, dass Integrationsprobleme zeitraubend sind und dass sie durch frühe und häufige Integration (anstatt einer einzigen Phase vor dem Testen) ihren Gesamtdurchsatz signifikant verbessern können, wenn sie die Zeit minimieren, in der sie isoliert arbeiten.
Ebenso ist es besser, kontinuierlich automatisierte Regressionstest-Suiten laufen zu lassen, um neu aufkommende Probleme so früh wie möglich zu erkennen (was die Anzahl der Fehlerquellen sowie die Zeit für die Fehlerbehebung wesentlich reduziert), anstatt alles in einer Phase am Ende eines Release-Zyklus (auch eines zweiwöchigen Zyklus) zu testen und alle Probleme auf einmal zu entdecken.
Die logische Konsequenz daraus ist, dass einige Teams nun regelmäßig etwas releasen (bekannt als Continuous Deployment). Das soll heißen, dass jede logische Veränderung (oder auch Gruppe von Veränderungen) direkt in kleinen „Mikro-Releases” geliefert wird. Das hat einige große Vorteile. Der erste Vorteil ist, dass dies die ultimative Strategie für inkrementelle Releases und somit der Hauptmechanismus für Gentle Deployment ist – gut für unsere Kunden und gut für uns. Der zweite Vorteil ist, dass die Suche und Behebung von Problemen in Produktion viel einfacher ist, als wenn man immer nur ein oder wenige Dinge gleichzeitig ändert.
Allerdings hat alles, was ich bisher beschrieben habe, mit Product Delivery zu tun. Aber was ist mit der Product Discovery?
Ich plädiere schon seit längerer Zeit für das gleiche Prinzip, wenn es um die Findung von Product Backlog Items geht. Statt einer mehrwöchigen „Product Discovery Phase”, in der man Product Backlog Items erstellt, validiert und dann zur Entwicklung weitergibt, möchte ich Teams zu einer kontinuierlichen Product Discovery auffordern, bei der wir permanent neue Product Backlog Items identifizieren, validieren und beschreiben. Manche Discovery-Arbeiten dauern nur ein paar Stunden, andere länger, aber es ist ein permanenter Ideenfindungs-, Validierungs- und Beschreibungsprozess.
In Dual-Track Scrum werden im Discovery Track kontinuierlich Product Backlog Items generiert und im Delivery Track werden diese Items kontinuierlich gebaut, getestet und deployt.
Mit Hinblick auf den Trend von Continuous Discovery und Continuous Delivery finden viele Teams den Scrum-Prozess ein wenig einschränkend und halten das Kanban-Modell in diesem Falle für besser geeignet.
Auch wenn nicht alle Teams notwendigerweise zu Kanban wechselten, habe ich doch viele gesehen, die Scrum genau aus diesem Grund in Richtung Kanban angepasst haben. Die häufigste Anpassung ist, statt nach jedem beispielsweise zweiwöchigen Sprint zu releasen, die Features und andere Änderungen direkt zu releasen, wenn sie fertig sind – oft sind das mehrere Mikro-Releases pro Woche. In diesem Fall nutzen die Teams das Timeboxing in Scrum als Möglichkeit, ihre Arbeit zu strukturieren und regelmäßige Retrospektiven zu fördern.
Grundsätzlich ist der Übergang zu Continuous Discovery und Continuous Delivery eine wirklich gute Sache und viele der besten Teams, die ich bisher kennengelernt habe, arbeiten damit; auch wenn hier, wie überall, unter Umständen Kompromisse eingegangen werden müssen.
Dieser Text stammt aus dem Blog von Marty Cagan und wurde von uns ins Deutsche übersetzt.