In unseren Projekten beobachten wir immer wieder mehr oder weniger ausgeprägte „Pseudo-Scrum“-Vorgehen. Das sieht dann oftmals so aus, dass der Product Owner denkt, der oder die Business Analysten schreiben die Tickets (von User Stories kann hier regelmäßig keine Rede mehr sein) und „refinen“ diese, und der Developer checkt den zugehörigen Code ein.
Der Anspruch in der agilen Softwareentwicklung hingegen umfasst ja mindestens, schnell und regelmäßig qualitativ hochwertige Softwareinkremente bereitzustellen. Unter Qualität verstehen wir dabei, dass das System läuft und die Anwendung auf jedem Stand der Implementierung korrekt funktioniert und jederzeit bruchlos geändert werden kann. Um diesem Anspruch gerecht zu werden und damit die kurzen Feedbackzyklen für die Stakeholder zu ermöglichen, ist jedoch auch ein Umdenken im Selbstverständnis der eigenen Rolle der Entwickler nötig: Nicht bloß „Entwickler“, die quasi im Blindflug Tasks (!) runter- (!) programmieren (!), sondern Software Engineers. Das bedeutet, Engineers sind keine Programmierer, keine Task-Delivery-People, nicht reine Erfüllungsgehilfen, die vorab „engineerte“ Requirements implementieren. Sondern vielmehr diejenigen, die als erste Anwender Produktvision und insbesondere die User Stories kontinuierlich kritisch würdigen und mitgestalten.
Damit diese Art der Softwareentwicklung erfolgreich ist, können wir aus unserer Erfahrung einige Empfehlungen aussprechen, von denen wir die ersten beiden bereits erwähnt haben:
Den Engineering-Aspekt der Softwareentwicklung wieder mehr in den Fokus rücken
Selbstverständlich soll ein System entstehen, das fachliche Probleme löst und Business Value schafft, das auf der Höhe der Zeit entwickelt worden ist und fit für die Zukunft bleibt. Eine erfolgreiche Implementierung bedeutet, jedwedes Anliegen eines Real-World-Problems in IT zu übersetzen. Dafür ist es aber essenziell, dass man als Engineer dasjenige Know-How der Anwendungsdomäne aufbaut oder immerhin im Wesentlichen versteht, das der Anforderung an ein Software-System zu Grunde liegt.
Dieses Anliegen sollte wirklich ernst und wichtig genommen werden. Von wem? Engineers first! Wer sich selbst „Programmierer“ nennt, wie steuert er sich selbst, und andere?
Mit hoher Frequenz Softwareinkremente abliefern
Anders ist es gar nicht möglich, auf sich wandelnde Anforderungen, neue Erkenntnisse oder eine sich ändernde Umwelt zu reagieren. Dafür eignet sich aus unserer Erfahrung am besten das „trunk based development“, das heißt, dass die Engineers gemeinsam an einem einzigen Zweig der Codebasis, dem sogenannten „trunk“ arbeiten und sich konsequent weigern, andere langlebige Entwicklungs- oder „Featurebranches“ zu erzeugen. Nur so lassen sich die „Merge Hölle“ und Lieferunfähigkeit nachhaltig verhindern. Daraus ergibt sich zwangsläufig die „Continuous Integration“ Praxis, also dass die Engineers regelmäßig ihre Codebasis mit dem „trunk“ integrieren. Dies funktioniert üblicherweise über Merge Requests, die jeweils von mindestens einem anderen Engineer geprüft werden („Code Reviews“). Kurzfristig kann diese Praxis insbesondere für unerfahrene Engineers anstrengend sein und erfordert daher eiserne Disziplin. Hier lässt sich jedoch Abhilfe schaffen nach dem bewährten Prinzip „automate everything!“. Durch ausgereifte CI/CD-Pipelines mit einem entsprechenden Build-Prozess lässt sich dieses Vorgehen erheblich vereinfachen und beschleunigen. Hohe Test-Abdeckung und eine sinnvollen Test-Pyramide (idealerweise TDD) zahlen ebenfalls auf dieses Ziel ein, da sie den Pipelines die nötige Aussagekraft verleihen und die Engineers entlasten. Ein Engineer liefert selbstverständlich keinen ungetesteten Code ab, was daher in jedem Fall auch Teil der Definition of Done sein sollte. Ein QA-Experte kann ergänzend und unterstützend im Team mitwirken, zum Beispiel beim Formulieren der User Stories oder bei den Code Reviews.
Das Backlog Refinement findet immer statt
Also auch, wenn beispielsweise der PO oder ein Teil des Teams verhindert sind. Die Umsetzung der Stories erfolgt immer durch die Engineers, daher sollten die Stories immer auch durch Engineers refined worden sein. So lassen sich frühzeitig Unklarheiten und Abhängigkeiten identifizieren, die dann rechtzeitig und insbesondere vor der Umsetzung aufgelöst werden können, gegebenenfalls durch eine dafür eigens vorgesehene Story. Regelmäßiges und sinnvolles Backlog Refinement erleichtert das Sprint Planning ungemein. Bei konsequentem Refinement ist das Planning oftmals in kurzer Zeit erledigt und alle Beteiligten wissen naturgemäß schon, was im kommenden Inkrement ansteht. Für technische Themen formulieren die Engineers selbst Stories, schätzen diese und priorisieren sie in Absprache mit dem PO auch selbst, weil sie selbst am besten wissen, was dort wie in welcher Reihenfolge zu tun ist. Der Ansatz, „lästige Technik“ nebenher zu machen, birgt große Risiken und geht oft schief.
Der Umgang mit dem Backlog erfordert Disziplin
Implementierungs-Vorgaben bei den Stories gilt es, unbedingt zu vermeiden. Stories ohne Akzeptanzkriterien dürfen nicht eingeplant werden, notfalls formulieren die Engineers diese selbst. Bearbeiter und Status von Stories und Tasks müssen aktuell gepflegt sein, insbesondere beim Arbeiten in verteilten Teams. Auch Verknüpfungen wie Abhängigkeiten, Features und Epics müssen für belastbare Planung korrekt gesetzt sein. Beim Schätzen von Stories werden Komplexität und Größenordnungen als Maßstäbe genutzt, insbesondere soll nicht über Aufwände und Dauer verhandelt werden. Eine im Planning oder im Refinement grob geschätzte Story im Backlog ist immer hilfreicher als eine gar nicht geschätzte Story. Es empfiehlt sich, eine möglichst explizite Roadmap zu erstellen, an der wichtige fachliche Ziele und Meilensteine mit ungefähren Zeitfenstern verbunden und Risiken explizit benannt werden. Naturgemäß wird die Roadmap unschärfer, je weiter sie in die Zukunft geht.
Defensiv planen
Schlechte Sprint-Ergebnisse sind fast immer die Konsequenz von schlechter Planung: ein Sprint sollte daher so geplant werden, dass der Scope auf jeden Fall am Ende abgeliefert wird. Es ist daher geschickter, defensiv zu planen, das heißt die wichtigsten Deliverables werden geplant und es wird nicht die volle Kapazität ausgeplant. Es empfiehlt sich hierbei, fachliche Ziele als Hilfe zu formulieren, an denen sich das Team orientieren kann.
Planning, Daily und Review finden immer statt
Diese Scrum-Events sind kein Selbstzweck, sondern Vehikel, um eine erfolgreiche wertorientierte Zusammenarbeit zu garantieren. Eine belastbare Planung im Sprint Planning ist eine notwendige Voraussetzung für einen erfolgreichen Sprint. Im Daily gilt das Motto „Zooming out rather than zooming in“, man versucht also ein Gesamtbild vom Team und vom Sprint zu bekommen, anstatt sich in Mikroprobleme zu vertiefen, die sich in aller Regel ohnehin nicht in 15 Minuten lösen lassen. Die Engineers (insbesondere aus anderen Teams) sind ebenfalls wichtige Stakeholder im Sprint Review.
Es liegt an jedem einzelnen Engineer, die hier angesprochenen Punkte voranzutreiben, soweit es ihm möglich ist. Im Umkehrschluss ist man jedoch kein fauler Software Engineer, wenn man das nicht kann. Hier gilt viel mehr das bekannte agile Prinzip „inspect and adapt“.
Dieser Beitrag ist in enger Zusammenarbeit mit meinem Kollegen Daniel Bürck entstanden.
