Architektur entsteht nicht neben der Arbeit des Teams, sondern in ihr. Wer nicht weiß, wie das Team seine Arbeit plant und sichtbar macht, schreibt ADRs, die niemand umsetzt, weil sie in keinem Sprint und auf keinem Board vorkommen. Diese Lektion stellt die zwei verbreitetsten Vorgehen vor, Scrum und Kanban, und zeigt, wo die Architektur darin ihren Platz hat. Zum Schluss richten Sie für die Kladde ein Board mit WIP-Grenzen ein und messen eine Woche lang, wie lange Arbeit braucht.
Scrum
Scrum ist ein Rahmenwerk, kein Prozess mit Vorschriften für jede Situation. Seine verbindliche Beschreibung ist der Scrum Guide von Ken Schwaber und Jeff Sutherland, ein kurzes Dokument, das Sie unter scrumguides.org lesen sollten, bevor Sie in einem Scrum-Team arbeiten. Was hier steht, ist eine Zusammenfassung in eigenen Worten.
Drei Verantwortlichkeiten. Der Product Owner verantwortet, dass das Produkt den größtmöglichen Wert liefert, und ordnet dafür den Product Backlog. Die Developers bauen in jedem Sprint ein nutzbares Inkrement. Der Scrum Master sorgt dafür, dass Scrum verstanden und gelebt wird, und räumt Hindernisse aus dem Weg. Eine Rolle „Architekt“ kennt Scrum nicht: Architektinnen arbeiten als Developers mit, oder sie sind Stakeholder, die der Product Owner einbindet.
Fünf Ereignisse. Der Sprint ist ein fester Zeitraum von höchstens einem Monat, in dem alles andere stattfindet. Das Sprint Planning legt fest, warum der Sprint wertvoll ist (das Sprintziel), was geschafft werden kann und wie. Das Daily Scrum ist eine kurze tägliche Abstimmung der Developers auf das Sprintziel. Das Sprint Review zeigt das Ergebnis den Stakeholdern und passt den Product Backlog an. Die Sprint Retrospective fragt, wie das Team besser arbeiten kann.
Drei Artefakte, jedes mit einer Verpflichtung. Der Product Backlog ist die geordnete Liste dessen, was das Produkt braucht; seine Verpflichtung ist das Produktziel. Der Sprint Backlog ist der Plan für einen Sprint, mit dem Sprintziel als Verpflichtung. Das Inkrement ist der nutzbare Stand am Ende, und seine Verpflichtung ist die Definition of Done: Was sie nicht erfüllt, ist nicht fertig und wird nicht gezeigt.
Scrum passt, wenn ein Team auf ein Ziel hinarbeitet, das sich in Sprints sinnvoll zerlegen lässt, und wenn regelmäßige Rückmeldung der Stakeholder hilft.