Die Einführung agiler Softwareentwicklung und von Scrum bei Heise, Teil 2

Inhaltsverzeichnis

In diesem Blogbeitrag aus dem "Themenblock Agile" stelle ich vor was aus unseren agilen Ambitionen geworden ist und in was für einem System wir heute arbeiten.

Im letzten Beitrag in unserem Blog erzählte ich von unserer agilen Transition. Der Einführung eines heise-Scrums in der Webentwicklung. In dieser Ausgabe sehen wir uns an, welche Rollen und Werkzeuge beim derzeitigen heise-Scrum im Einsatz sind.

Die Entwicklerteams

Die Webentwicklung ist in drei Teams aufgeteilt. Die Teams bestehen aus 5-6 Entwicklerinnen und Entwicklern, die sich innerhalb eines Workshops gefunden haben. Beim Bilden der Teams haben wir versucht, menschliche Vorlieben und fachliche Ausprägungen zu berücksichtigen. Es sollten harmonische Gruppen entstehen, die mit allen Aufgaben zurechtkommen.

Mehr Infos

Dieser Blogbeitrag ist Teil einer Serie

Hier sind die anderen Teile zu finden:

Teil 1 - Die agile Transition

Teil 3 - Die Events

Die Teams sind zunächst thematischen Schwerpunkten und damit auch beauftragenden Abteilungen im Verlag zugeordnet worden. Diese Zuteilung sollte nicht allzu strikt sein. Vielmehr sollte sie Kolleginnen und Kollegen aus anderen Abteilungen feste Ansprechpartner zur Verfügung stellen. Grundsätzlich war klar, dass die Teams auch in den Revieren der anderen Teams wildern werden. Schlichtweg weil die Auftragslage und Dringlichkeit naturgemäß extrem unterschiedlich ist. Bei Fragen der technischen Umsetzung haben die Entwicklerteams bei uns das letzte Wort.

Die Product Owner

Jedem unserer Teams wurde ein Product Owner (PO) zugewiesen, die eng mit dem jeweiligen Team zusammenarbeiten und im Grunde mit in die Teams gehören. Die POs sind bei uns wohl etwas näher an den Entwicklerteams als in der reinen Scrum-Lehre vorgesehen.

Disziplinarische Vorgesetzte ihres Teams sind die Product Owner nicht. Es gibt bei uns noch Teamleiter als direkte Vorgesetzte, die aber für arbeitstechnische Dinge wie Mitarbeitergespräche, Urlaubsanträge oder Elternzeit zuständig sind. Die Teamverteilung wurde so gewählt, dass niemandes PO aus Versehen auch sein Vorgesetzter ist.

Die Product Owner sorgen dafür, dass immer ausreichend, gut angereicherte Storys für die Teams zur Verfügung stehen. Sie sammeln Wünsche für kommende Entwicklungen und sind Ansprechpartner für sowohl die Teams, als auch die Stakeholder aus Produktmanagement, Chefredaktion und Fachabteilungen.

Bei größeren Unklarheiten kann der PO auch einen direkten Draht zwischen Stakeholdern und den Teams herstellen. Meist fungieren die POs als Übersetzer und Einordner. Sie stehen zwischen dem Football-Team und dem Schachclub, zwischen Nadelstreifen und Kapuzenpullovern, zwischen "The Wolf of Wall Street" und Star … ich glaube der Punkt ist klar geworden.

Der Agile Coach

Für den reibungslosen Ablauf und strukturierte Meetings sorgt bei uns eine Kollegin als Agile Coach. Im Grunde füllt sie die Rolle aus, die in der reinen Scrum-Lehre der Scrum Master inne hat. Anders als in Scrum hat bei uns nicht jedes Team einen Scrum Master.

Sie führt durch die typischen agilen Events (die weiter unten nochmal aufgeführt sind), vermittelt bei Meinungsverschiedenheiten, motiviert und versucht Hemmnisse aus dem Weg zu räumen. Die Events in unseren Teams sind zeitlich extra so gestaffelt, dass der Agile Coach an allen teilnehmen kann.

Agile-Program-Manager

Das zentrale Board (dazu später mehr) ist für drei Teams so umfangreich, dass uns schnell die Wände knapp wurden und komplett die Übersicht verloren ging. Gefühlt hunderte Aufgaben (repräsentiert durch Zettel und Tickets im Jira) warteten dort auf die Teams zur Abarbeitung. Wenn der Begriff "verzettelt" nicht schon älter wäre, ich hätte vermutet er kommt aus Scrum.

Dieser Umstand hat bei uns die Rolle der Agile-Program-Managerin geschaffen, die dort die Übersicht behält und sozusagen den Scrum of Scrums leitet. Mit den POs zusammen priorisiert und sortiert sie hereinkommende Storys.

Agile Werkzeuge

Unter der etwas albtraumhaften Aussage "Bei Scrum sprechen die Wände" konnte ich mir anfangs nicht so richtig etwas vorstellen. Mittlerweile habe ich eine recht gute Vorstellung davon: Unsere einstmals kahlen Räume sehen mittlerweile aus wie ein Teenagerzimmer (Disclaimer: Eventuell hinkt der Vergleich, weil Teenagerzimmer nicht mehr so aussehen wie zu meiner Teenagerzeit).

Was ich sagen will: Alle Informationen, die wir dauerhaft im Hinterkopf behalten wollen, hängen bei uns gut lesbar an den Wänden.

Die Boards

Allen voran geht es um die typischen Kanban/Scrum-Boards, sowohl für die Teams als auch im gemeinsamen Raum der Webentwicklung für alle Teams. Dort ist auch das zentrale Backlog zu finden.
Die Team-Boards sind bei uns tatsächlich zum ersten Anlaufpunkt für Informationen geworden. Dabei folgen wir wohl mehr oder weniger dem weltweiten Standard mit je einer horizontalen Swimlane pro Story. Zusätzlich haben wir noch eine Swimlane für Tasks ohne Story (Bugs, Tagesgeschäft oder Nice-To-Have-Tasks).

Jede(r) Entwickler/in hat eine Spalte und zieht sich die gerade bearbeiteten Tasks dann in ihr/sein Feld in der jeweiligen Swimlane beziehungsweise in die “Done”-Spalte, wenn sie mit der Aufgabe fertig sind. Die einzelnen Task wandern also von links nach rechts während des Sprints.

Das schafft enorme Transparenz für POs und auch alle anderen Interessierten, hat aber auch einen gewissen Pflegeaufwand. Unser Agile Coach fragt deswegen im Daily gerne mal nach, wenn jemand keinen Task in seiner Spalte hat.

Am zentralen Board hängen keine Tasks sondern ausschließlich Storys. Sie sind farblich und nach Möglichkeit auch in horizontalen Swimlanes nach Themengebieten sortiert. Auch hier gibt es eine Bewegung von links nach rechts. Grob kann man sagen: Je weiter links, desto weniger ausgearbeitet ist die Story. Fertige Storys wandern in die “Ready”-Spalte und werden dann von dort in das Backlog gezogen und nach Priorität sortiert. Das Backlog bildet dann den Pool aus dem beim Sprintwechsel (oder in Ausnahmefällen während des Sprints) gezogen wird. Je besser das zentrale Board in Schuss ist (was variiert), desto besser kann man sich als Entwickler dort schlau machen über die anstehenden Aufgaben. Das kann definitiv Vorteile haben, weil man so Synergien nutzen oder bei entwickelten Modulen direkt berücksichtigen kann, dass es demnächst noch erweitert wird.

Für mich persönlich ist es wesentlich angenehmer, wenn ich nicht direkt "am Nebel des Krieges kämpfe", sondern mich vorbereiten kann auf das was kommt.

Die Storys

Gestartet sind wir mit ausklappbaren DIN A4-Seiten, die alle Informationen der Story enthielten. Das hatte den großen Vorteil, dass man sich die Informationen zur Story direkt an einem der Boards holen konnte. Der große Nachteil war: Wichtige, aktualisierte Informationen hätten bedeutet, dass man die Hardcopy an beiden Boards hätte aktualisieren müssen. Deswegen sind wir mittlerweile auch bei Storys auf Klebezettel umgestiegen, die immer einen Verweis auf ein Jira-Ticket haben. Die Folge: Nicht mehr alle Infos direkt am Board, dafür einen "Single Point of Truth".

Dazu kommt, dass man den Status der Storys jetzt auch mit Jira-Mitteln verfolgen kann und Gesamtaufwände auf diesem Wege an das Controlling des Verlags weitergeleitet werden können.
Zu den Boards kommen noch zahlreiche Poster an den Wänden die Informationen wie "Definition of Done", "Definition of Ready" oder Maßnahmen aus der Retrospektive festhalten.

Einige neue Werkzeuge im Arbeitsablauf sind nicht direkt mit Agile verbunden, aber das agile System hat bei uns einiges an Methoden hoffähig gemacht:

Jedes Team hat mittlerweile ein großes Display auf Rollen für Präsentationen und Mob-Programming. Wir haben die großen Teambüros mit Sitzsäcken ausgestattet und teilweise Wände durchbrochen (nein, nicht selbst) um Räume zusammenzulegen. Grundsätzlich haben Methoden zur Verbesserung des Wissenstransfers und der Codequalität zugenommen.

Mittlerweile sind Pair-Programming, Mob-Programming, TechTalks oder Code Reviews bei uns fester in den täglichen Ablauf eingebunden als vor der Umstellung. Vieles davon hing gar nicht unmittelbar mit der Agilität zusammen und kam mehr als Beifang, weil es sich in die agilen Abläufe einfach sehr gut integrieren lässt.

Soweit also zu den agilen Rollen und den Werkzeugen die bei uns im Einsatz sind. Im kommenden Blogbeitrag will ich dann näher auf die agilen Events in unserem System eingehen. (sfi)