Missverständnisse bei Scrum oder Devops

1. Missverständnis: „Mit Scrum kann man nur alle zwei Wochen eine neue Version liefern“

Bei Devops geht es um das häufige Liefern von neuen Versionen mit kleinen Verbesserungen. In entsprechenden Fallstudien werden oftmals mehrere Releases pro Tag erwähnt. Scrum kennt zwar keine minimale Zeit für den Planungs-Zyklus (Sprint), jedoch macht es in der Praxis nur selten Sinn, diese kürzer als eine Woche zu wählen. Eignet sich damit Scrum nicht für Continuous Delivery, also der kontinuierlichen Auslieferung neuer Funktionen? Wenn man den Scrum-Guide genau liest, stellt man fest, dass Scrum die Bereitstellung eines sogenannten Done Increments, also einer auslieferbaren Produktversion spätestens am Ende jedes Sprints fordert. Es gibt jedoch keine Regel, die verbietet, während des Sprints auch häufiger ein solches Done Increment bereitzustellen und auch auszuliefern, also gerne auch mehrfach am Tag.

2. Missverständnis: „Devops ist Automatisierung des Deployment-Prozesses“

Ein wichtiger Aspekt von Devops ist, daran zu arbeiten, den oben beschriebenen Devops-Zyklus so schnell und so häufig wie möglich durchlaufen zu können. Das ist nur möglich, wenn ein großer Teil der Abläufe wie zum Beispiel Build, Test, Release und Deployment automatisiert sind. Devops aber auf die Einführung entsprechender Tools zur Automatisierung zu begrenzen, würde bedeuten, den größten Teil des Verbesserungspotenzials außen vor zu lassen. Devops beginnt zunächst mit einem Mindset, mit der systemischen Betrachtung des gesamten Erstellungs- und Betriebsprozesses für Softwareprodukte mit dem Ziel, für die Anwender ein möglichst positives Benutzererlebnis zu schaffen. Dafür müssen unterschiedlichste Perspektiven berücksichtigt werden und verschiedene Konzepte müssen ineinandergreifen. Aus dieser Gesamtbetrachtung entsteht dann an verschiedenen Stellen ein Automatisierungsbedarf, der wiederum Tools notwendig macht. Devops also mit Tools zu beginnen, wäre wie das Pferd vom Schwanz her aufzuzäumen.