19. Jan. 2017

Scrum: Unser Prozess war Schrott und das ist gut so!

Ich werde hier nicht die alten Marketingkamellen von agiler Software-Entwicklung herauskramen, die Ihr alle schon tausendmal irgendwo gehört oder gelesen habt. Zusammenfassungen, was agile Software-Entwicklung ist, findet Ihr unzählige bei Google.

Stattdessen sag ich Euch die Wahrheit über unseren agilen Prozess: Manchmal ist er Schrott und das ist gut so.

Warum sollte ich das der Welt mitteilen? Ganz einfach. Um etwas besser machen zu können, muss man erst mal einsehen, dass es schlecht ist.

Diese Idee ist der Antrieb für unseren Drang, uns stetig zu verbessern und neu zu erfinden. In den anderthalb Jahren, in denen ich als Scrum Master bei Aspera arbeite, gab es unzählige Veränderungen und zahlreiche Experimente auf unserer Kaizen-Reise (das ist agiles Marketingblabla für „stetige Verbesserung“).

Nicht „Warum?“ zu fragen ist Schrott. Wir haben das geändert.

Ich fange mal mit den Product Ownern an. Das sind die Leute, die die Anforderungen durchwühlen und aufräumen. Sie versuchen, so früh wie möglich, den Entwicklern alle nötigen Informationen über neue Features bereitzustellen.

Das machen sie, indem sie Vorlagen für User Stories (Change Request in Scrum-Sprech) entwickeln, die von Kunden und Consultants ausgefüllt werden. Dann analysieren sie diese Informationen, um nicht nur zu verstehen, „was“ die Anforderer wollen, sondern vor allem „warum“ sie es wollen. Das wiederum erleichtert es den Entwicklern später, den besten Weg zu finden um die angeforderten Änderungen umzusetzen. Dieses „Warum?“ nicht zu haben, ist Schrott. Wir haben das geändert.

Diese Vorgehensweise stellt sicher, dass die Entwickler, die bei uns Teil eines Scrum-Teams sind, nicht zu „code monkeys“ werden. (Scrum ist eine von vielen Möglichkeiten, Software agil zu entwickeln). Stattdessen haben die Entwickler selbst die Verantwortung, zu entscheiden, „wie“ etwas umgesetzt wird. Wir vertrauen darauf, dass die Leute, die die Anwendung am besten kennen, auch die besten Entscheidungen treffen. Technische Entscheidungen von jemand anderem als den Entwicklern treffen zu lassen ist Schrott. Wir haben das geändert.

Agile Scrum

Entwickler, die nicht testen, sind Schrott. Wir haben das geändert.

Unsere Entwickler machen Tests und QA selbst (Round-Robin). Es gibt keine explizite Testabteilung, die der Entwicklung nachgelagert ist. Testen gehört zu unserer Definition of Done, eine kleine Liste aus Qualitätsansprüchen und Tests, welche ein Feature durchlaufen und bestehen muss, bevor unsere Entwickler etwas releasen.

Statt dem mittleren Management sind es die Entwickler selbst, die die Definition of Done entwickelt haben. Sie ist allgemein genug, damit sie auf alles angewandt werden kann, was entwickelt wird, ohne im Gegenzug bedeutungslos zu werden. Dadurch, dass unsere Entwickler die Kriterien für ihre Qualitätskontrolle selbst definieren und dass sie alle dafür notwendigen Tests selbst durchführen, releasen sie ihren Code auch erst dann, wenn sie sicher sind, dass er ihren Kriterien entspricht. Die Entwickler übernehmen die Verantwortung, die Aspera ihnen anvertraut, was sie wiederum dazu bringt, den Job ernst zu nehmen. Entwickler, die nicht testen und von Managern auferlegte Qualitätsstandards umsetzen, sind Schrott. Wir haben das geändert.

Stakeholdern keinen Einblick zu geben, ist Schrott. Wir haben das geändert.

Nach jedem zweiwöchigen Sprint könnten wir neue Features releasen. (Ein Sprint ist eine Iteration, in der wir eine bestimmte Menge an Features entwickeln können.) Aber tatsächlich releasen wir nur alle 8 Wochen, um die Aufwände auf der Kundenseite gering zu halten. Das bedeutet auch, dass sich sowohl die Kunden als auch unsere Berater, die diese Kunden vertreten, alle zwei Wochen in unseren öffentlichen Sprint Review Meetings ansehen können, was gerade entwickelt wurde. Und wenn Sachen noch heißer sind, kann man sich an ausgesuchte Leute wenden, die unmittelbar Feedback zu Themen geben, die momentan in der Produktion sind. Den Stakeholdern keinen Einblick in die Produktionsabläufe und Zwischenstände zu präsentieren ist Schrott. Wir haben das geändert.

Arbeiten ohne Spaß ist Schrott. Wir haben das … geändert!

Alle zwei Wochen haben wir eine Retrospektive, um unseren Prozess zu betrachten. Das ist der Moment, wo wir alte Gewohnheiten fallen lassen und uns entscheiden, neue Dinge auszuprobieren, um mehr Produktivität und Spaß bei der Arbeit zu erreichen.

Ja. Spaß.

Gute Produkte werden nicht von depressiven oder ausgelaugten Entwicklern gebaut. Sie haben keine neuen Ideen und Verbesserungsvorschläge. Im schlimmsten Fall ist ihnen sogar das Produkt egal, an dem sie arbeiten.

Also sollen unsere Entwickler auch Spaß haben. Denn Arbeiten ohne Spaß ist Schrott.

Sie entscheiden auch selbst, in welchen Teams sie arbeiten. Im Moment haben wir vier Kernteams: Cyberdyne, Weyland, Umbrella und Tyrell. Die Namen haben sie sich selbst ausgesucht. Könnt ihr das gemeinsame Thema erraten? (Für einen Hinweis bitte hier klicken.)

Die Entwickler entscheiden auch selbst, wo sie sitzen, denn warum sollte irgendjemand anders das entscheiden? Wir setzen Videokonferenzen auf für Leute, die aufgrund ihrer familiären Situation von zu Hause an Meetings teilnehmen möchten, um das Teamgefühl intakt zu halten. Eine Arbeitsdrohne zu sein, die nur vordefinierte Arbeitspakete abliefert, ist Schrott.

Scrum ist: ein funktionierender Prozess. Das Gegenteil von Schrott.

Wir leben in einem Informationszeitalter und leisten Wissensarbeit. Jeden Tag bauen und verbessern wir die Technologie, die es global agierenden Unternehmen ermöglicht, ihre Softwarelizenzen zu optimieren, sich selbst vor Risiken zu schützen und dabei auch noch viel Geld zu sparen. Um das zu erreichen, braucht man einen funktionierenden Prozess. Scrum kann das leisten.

Scrum hilft uns, die richtigen Leute dazu zu bringen, über die richtigen Dinge zu reden, was die wichtigste Zutat ist, wenn man ein derartiges Produkt schaffen möchte.

Eine weitere wichtige Zutat sind die richtigen Kekse im richtigen Meeting. Die bringe ich mit.



Themen: SmartTrack