Was bisher geschah

Seit vor bald 20 Jahren das Manifest für agile Softwareentwicklung veröffentlicht wurde, haben seine Prinzipien und Leitsätze die Softwarebranche erobert (siehe erster Artikel), neue Methoden, Arbeitsweisen und Rollen gingen damit einher. Bis diese jedoch auch in anderen Branchen populär wurden, dauerte es hingegen eine Weile. Fünf Jahre ist es erst her, dass Jeff Sutherland, Miterfinder einer der bekanntesten agilen Frameworks anmerkte, Agilität sei in der allgemeinen Geschäftspraxis noch relativ unbekannt.

Mit seinem ebenfalls 2014 erschienenen Buch „SCRUM. The art of doing twice the work in half the time“ wollte er seine Methode auch über die Softwarebranche hinaus bekannt machen. Der ehemalige Absolvent der Militärakademie West Point war Bomberpilot im Vietnamkrieg, bevor er ins Softwarefach wechselte. Er leitete ein Dutzend Firmen, in denen er mit agilen Methoden „branchenführende und hyper-produktive Ergebnisse“ zu erzielen vermochte, glaubt man dem Klappentext. Sutherland kann sich entspannt zurücklehnen, sein Plan ist mittlerweile aufgegangen.

Kleine Teams, die eigenverantwortlich in kurzen Zyklen funktionierende Software ausliefern, sind auch bei Daimler mittlerweile angesagt, mitsamt den neuen Job-Beschreibungen aus dem agilen Werkzeugkasten: „Unsere Mitarbeiter streifen die alte Rolle des internen Dienstleisters ab und reifen zu Product Ownern mit allen Verantwortlichkeiten und Freiräumen”, fasst die Leiterin des Daimler-Digitalbereichs Sabine Scheuner erfolgreiche Rollenwechsel zusammen. Der Name der agilen Strategie, auf die Daimler seit 2015 setzt: twice as fast. (siehe zweiter Artikel).

Volkswagen wird agil

Angesichts von so viel Agilität und Entrepreneurship in Stuttgart mag auch der Konkurrent aus Wolfsburg nicht zurückhalten: Beim Volkswagen-Konzern werden agile Methoden nicht nur in der Software-Abteilung, sondern auch in Forschung und Entwicklung eingesetzt. Unterstützung bekommt der niedersächsische Autobauer dabei vom kalifornischen Softwareunternehmen Pivotal Software, Inc.: Das in San Francisco ansässige US-Unternehmen hilft VW insbesondere dabei, die digitale Arbeitsumgebung der agilen Teams zu gewährleisten. Zur breiten Palette an Software und Cloud-Anwendungen gehört insbesondere der Pivotal Tracker, „eine kollaborative Projekt-Management-Plattform, die speziell für Software-Teams konzipiert ist und agile Methoden unterstützt“, so der Hersteller.

• Unter Pivot (französisch: Angelpunkt), versteht man in der Start-up-Szene eine radikale strategische Änderung des Geschäftsmodells.

3. Geschichten aus dem Backlog

Die Arbeit der Software-Entwicklerinnen und -Entwickler hat so gar nichts zu tun mit dem Bild der hinter verschlossenen Türen einsam vor sich hin tüftelnden Nerds, die, von Pizza und Cola genährt, irgendwann mit dem fertigen Ergebnis in der Hand und Ringen unter den Augen aus ihrer Büro-Höhle kommen. Demgegenüber sind oft Dutzende, Hunderte oder gar Tausende Mitarbeiterinnen und Mitarbeiter aus unterschiedlichsten Spezialisierungen an einem Softwareprojekt beteiligt. Die Software kann durchaus Millionen Zeilen lang sein – solche Projekte lassen ohne sich spezielle Software nicht mehr überblicken.

Dabei wird jeder kleine Schritt digital dokumentiert: Wer ist wann online? Wer hat wann welche Zeile Code geschrieben, welche Aufgaben gestartet, erledigt, zurückgewiesen? All dies und noch viel mehr müssen Softwareprodukte leisten, sogenannte Entwicklungsumgebungen (IDEs), Zusammenarbeit, Kommunikation und Dokumentation wird über diese abgewickelt. Darüber hinaus ist das Speichern des Codes mit einer Protokollfunktion essenziell, um Änderungen nachverfolgen zu können, simultane Arbeit vieler am gleichen Code zu gewährleisten, und die Speicherung und Überprüfung des Codes, das automatisierte Testen von Funktionen, sowie Versionierung zu ermöglichen, also das Speichern sämtlicher Änderungen und Versionen des Codes aus der Vergangenheit.

• die Entwicklungsumgebung (IDE, integrated development environment) ist eine Software, die Funktionen bereitstellt, die für die Programmierung nötig sind: Texteditor zum Schreiben des Codes, Compiler und/oder Interpreter zum Übersetzen des Codes in ausführbaren Programmcode sowie Tools zum Testen und zur Fehlersuche.

„Working software is the primary measure of progress.“ –
„Funktionierende Software ist das wichtigste Fortschrittsmaß.“
(7. Prinzip)

Zu den einzelnen Aufgaben ist jeweils eine Kurzbeschreibung notiert, sowie der Status der Bearbeitung (nicht bearbeitet, in Bearbeitung, fertig und akzeptiert). Wenn der oder die Verantwortliche seiner oder ihrer Meinung nach die Aufgabe beendet hat, markiert er oder sie als erledigt.

• Backlog: Eine nach Prioritäten geordnete Liste an Aufgaben, deren Erledigung ansteht.

• Als Epic wird eine umfangreiche User Story bezeichnet

• User Storys enthalten Anforderungen an die Funktionalität des Produkts aus der Sicht des Kunden oder Anwenders.

Der agile Workflow am Beispiel Scrum

Jede Aufgabe, Ticket oder Task ist dabei als „Geschichte“ formuliert, um die allgemeine Verständlichkeit und das anvisierte Ziel zu verdeutlichen. Die Kundenwünsche sollen dabei allgemeinverständlich beschrieben sein, so dass das gewünschte Ziel für alle Beteiligten unmittelbar ersichtlich ist. Ein Ticket, dessen Beschreibung z.B. lautet „Passwort-Eingabe falsch“, beschreibt zwar korrekt den Fehler, es mangelt aber an Kontext und Verständlichkeit. Deutlich besser wäre „Im Feld „Passwort“ ist Klartext zu sehen, ersetzen durch Sternchen“. Ideal ist eine solche Story, wenn sie persönlich formuliert ist, also die Nutzersicht deutlich wird: „Wenn ich als User auf der Startseite mein Passwort eingebe, erscheinen die eingegebenen Zeichen als Klartext. Stattdessen sollen aber Sternchen zu sehen sein.“

Der Backlog ist das Betätigungsfeld des Product Owners. Er schreibt die Storys und erstellt sie im Backlog. Dies kann in Zusammenarbeit mit anderen Teammitgliedern geschehen. Storys befinden sich zunächst im Status „unscheduled“ (ungeplant) und liegen in der Icebox „auf Eis“. Daraufhin werden sie vom Product Owner in priorisiert, d.h. in die Reihenfolge der Wichtigkeit sortiert – was ist „must“, was ist „nice-to-have“, was muss im nächsten Sprint passieren, was kann später passieren?

In einem nächsten Schritt müssen die Storys in ihrem Aufwand und ihrer Komplexität geschätzt werden. Das geschieht üblicherweise in einem Meeting, bei dem das gesamte Team diese Einschätzung liefert, die in „Story Points“ ausgedrückt wird. Faktoren sind dabei etwa die Komplexität der Story und der potenzielle Aufwand für deren Implementierung. Ist eine Story geschrieben, dem aktuellen Sprint zugeordnet und geschätzt („estimated“), dann steht ihrer Erledigung nichts mehr im Wege. Erst nach diesen drei Schritten können die Storys bearbeitet werden, ihr Eintrag im Backlog bekommt einen Start-Button. Ein Team-Mitglied sucht sich die Story aus und startet sie. Die zur Bearbeitung bereiten Aufgaben werden nicht zugewiesen vom „Chef“, den es ja nicht mehr gibt, sondern die Teams teilen diese einvernehmlich unter sich auf. Dasjenige Teammitglied, das sich der Aufgabe annimmt, ändert den Zustand auf „gestartet“. Sofern sie nicht vorab zugewiesen wurde, wird die Person, die auf „Start“ geklickt hat, Eigentümer der Story.

Wenn die Codierungs- und Testaktivitäten für die Story abgeschlossen sind, beendet der oder die Bearbeitende den Codierungsvorgang, die Story ist „finished“. In einem weiteren Schritt wird der fertige Code erst noch in geeigneten Testumgebungen bereitgestellt. Erst wenn diese durchlaufen sind, werden sie von einem Teammitglied oder einem automatisierten Bereitstellungsprozess als zugestellt markiert. Jetzt sind die grünen Schaltflächen „Akzeptieren“ und „Ablehnen“ sichtbar. Der Product Owner überprüft dann die Story und akzeptiert sie, sofern sie aus seiner Sicht alle Kriterien erfüllt. Die akzeptierte Story wird grün, bekommt den Status „done“ und ist damit erledigt. Der Product Owner kann sie auch ablehnen, mit einem Kommentar wieder als ungestartete Story zurücksetzen und somit wieder in den Workflow einspeisen.

Die Velocity tracken im Kumpelnest

„At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.“ –
„In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“
(12. Prinzip)

Das Team schätzt selbst den Umfang der Aufgaben ab und quantifiziert dies in sogenannten Story Points. Die Software berechnet nun aus der Anzahl erledigter Story Points pro Zeiteinheit den Leistungsdurchschnitt des gesamten Teams: die Velocity (Geschwindigkeit). Ziel ist auch hier weniger die Kontrolle von außen als die Selbstmotivation des Teams. Dabei organisiert das Team seine eigene panoptische Überwachung und bestimmt seinen Akkord gleich mit.

• Story Points: Einheit für Aufwandsschätzungen. Ein Story Point ist eine Metrik, die in der agilen Projektverwaltung und -entwicklung verwendet wird, um die Schwierigkeit der Implementierung einer bestimmten Story zu abzuschätzen.

• Velocity ist die Summe aller erledigten Aufgaben. Am Ende jeder Iteration addiert das Team Aufwandsschätzungen für User Storys, die während dieser Iteration abgeschlossen wurden. Diese Summe nennt man Geschwindigkeit.

Geschwindigkeit (Velocity) und Steuerung und Kontrolle (Control) als Ziele von Management und Arbeitsorganisation sind allerdings keine Neuerfindung. Bereits vor einhundert Jahren machten ebenfalls Methoden von Tracking und Control in der Arbeitswelt Furore – damals ging es aber noch ums Herumtragen von Roheisen-Stücken, nicht um das agile Abarbeiten von Tickets. Der Erfinder des berühmt-berüchtigten wissenschaftlichen Managements, der feinkörnigen Messung, Optimierung und Überwachung von Arbeitsschritten, revolutionierte mit seinen Methoden die industrielle Arbeitswelt und versprach seinen Auftraggebern, eine Verdoppelung der Arbeitsleistung mit Hilfe seiner Methoden.

Die Rede ist von Fredrick W. Taylor, der mit seinen Scientific-Management-Methoden vor rund 100 Jahren dem industriellen Kapitalismus bzw. in erster Linie den Arbeitern einen Geschwindigkeits-Boost ohnegleichen verpasste. Die Rollen waren damals ganz andere – Hilfsarbeiter, Vorarbeiter und Management. Die Unternehmensziele allerdings haben sich kaum geändert seit den glorreichen Zeiten von Bethlehem Steel und lassen sich auf die zeitlose Formel bringen: Velocity und Control.

In vierzehn Tagen geht es weiter mit der schillernden Persönlichkeit Taylors, der vor über einem Jahrhundert mit ähnlichen Geschwindigkeits-Superlativen Furore machte.

Quellen und Links

• Sutherland, Jeff, Scrum: the art of doing twice the work in half the time. New York: Crown Business, 2014
• Interview mit Sabine Scheuner, Leiterin Digitalbereich KonzernIT Daimler, automotiveIT, Ausgabe 5, 2019, S. 54 S. 56
• Gerd Scholz, Digitalisierung: VW geht strategische IT-Partnerschaft mit Pivotal ein. Automobilwoche, 23.03.2016
• Pivotal Software Inc.