Die Otto GmbH & Co. KG hat Ende letzten Jahres den Relaunch ihres von Grund auf eigen- und neuentwickelten Webshops abgeschlossen. Das Projekt mit dem Namen LHOTSE hat sich dabei innovativer Methoden und Techniken bedient. Ich war an der Umsetzung beteiligt und möchte euch in diesem Blogpost von ein paar der Faktoren erzählen, die zum erfolgreichen Abschluss beigetragen haben.

Agile Softwareentwicklung

Jetzt denken vielleicht einige von euch “ja klar, jetzt will er uns Agile Softwareentwicklung als was Neues verkaufen”. Das Konzept ist alt und bekannt genug. Die Vorteile sind geläufig, und in unserer Firma haben wir bisher jedes Projekt mit Agilen Methoden umgesetzt, da sie für die von uns umgesetzten Projekte immer richtig waren.

Scrum bei LHOTSE

Anders sieht es bei großen Unternehmen aus. Im Projekt LHOTSE wurde das erste Mal im großen Stil Scrum bei Otto eingeführt. Dabei kam es - wenig verwunderlich - zu dem typischen Clash Of Cultures in den Scrum Teams, in denen Otto-Mitarbeiter, denen Scrum meist neu war, und Externe mit Scrum-Erfahrung gemischt wurden. Diesen Kulturschock gab es aber auch zwischen dem Projekt LHOTSE und den anderen Abteilungen des Unternehmens, die weiterhin nach bekannten Schemata und Organisationsstrukturen gearbeitet haben.

Trotz dieser Hindernisse wurden keine Kompromisse gemacht, um die Konflikte sowohl innerhalb des Projekts als auch zum übrigen Unternehmen wieder einzufangen. Stattdessen wurde an der agilen Methode Scrum festgehalten. Durch die Integration von Externen mit Scrum-Erfahrung wurde die Scrum-Kultur im Projekt dann auch schnell aufgenommen.

Anstatt sich auf dem Erreichten auszuruhen, begannen die Teams bald den Entwicklungsprozess ihren individuellen Bedürfnissen anzupassen. Die Teams nutzen dazu die regelmäßig stattfindenden Retrospektiven. So entstand eine vielfältige Landschaft von agilen Prozessen in der immer wieder neue Dinge ausprobiert und die gemachten Erfahrungen unter den Teams ausgetauscht werden.

Physikalische Boards

Vor der Mitarbeit in LHOTSE hatte ich in Projekten immer nur mit digitalen Scrum Boards gearbeitet. Ein großer Vorteil des digitalen Boards ist natürlich die Verfügbarkeit. Verteilte Teams teilen immer dieselbe Sicht auf das Board. Als Nachteil sehe ich die Handhabung in der täglichen Arbeit, speziell im Daily. Meist werden für das Daily große Monitore oder Fernseher genutzt, um eine gemeinsame Sicht auf das Board zu ermöglichen. In meiner Erfahrung funktioniert das aufgrund der Größe der Monitore und der Bedienung über Maus und Tastatur nur leidlich gut.

Ein physikalisches Board (in einem anderen Projekt)

Im Projekt LHOTSE benutzten wir physikalische Boards. Das habe ich schätzen und lieben gelernt. Die Eigenschaften eines digitalen Boards (z.B. Color Coding für Tasks, Lanes, Prioritäten, Zuständigkeiten) gehen nicht verloren. Die Übersicht wächst jedoch enorm, da das Board sehr groß sein kann, beim Team steht, und man jede Bewegung am Board schnell mitbekommt. Im Gegensatz zu manchen digitalen Tools kann man Prozessänderungen (z. B. Änderungen der Definition Of Done) schnell und passend am Board abbilden. In inoio-geführten Projekten habe ich seitdem erfolgreich physikalische Boards etabliert.

Agile Methoden

In der Entwicklung haben wir uns einiger Agiler Methoden bedient, unter anderem Test Driven Development, Behaviour Driven Development, Pair Programming, Continuous Delivery und DevOps. Christian Stamm hat dazu einen sehr guten Blog Post auf dem Otto Dev Blog geschrieben.

Modulare Systemarchitektur statt eines Monolithen

Um eine technische Kopplung zwischen den verschiedenen Teams zu vermeiden, haben wir eine modulare Systemarchitektur zu einem Grundprinzip des Projekts erkoren. Jedes Team hatte 2-3 inhaltliche Themen und hat diese in voneinander unabhängigen, über Schnittstellen voneinander entkoppelten Systemen entwickelt. Dadurch hatte jedes Team für jedes inhaltliche Thema große Freiheit in der Wahl der Technologien. Der Zusammenarbeit und der Effektivität hat dies nicht geschadet, sondern genützt. Wer noch mehr Details zu den zugrundeliegenden Prinzipien erfahren möchte, dem sei dieser Talk von Stefan Tilkov empfohlen.

Enabling

Zu jeder der wesentlich genutzen Technologien und Methoden im Projekt gab es gute externe Berater, die die Teams befähigt haben, das Maximale herauszuholen (z.B. waren Ingenieure von MongoDB und Varnish vor Ort). Nicht dass wir die Herausforderungen als gute Ingenieure nicht hätten selbst lösen können, aber durch den Zugriff auf dieses qualifizierte Wissen konnten wir uns auf das Wesentliche, die Business-Prozesse kümmern.

Open Source

Wir haben in der Entwicklung konsequent und bewusst zu großen Teilen auf Open-Source-Bibliotheken und -Technologien gesetzt. Zu den Vorteilen von Open-Source-basierten Lösungen zählen die flexiblen Kombinationsmöglichkeiten, die geringen Lizenzkosten, die Unabhängigkeit von jeweils einem kommerziellen Anbieter und die leichtere Erweiterbarkeit und Austauschbarkeit der einzelnen Open-Source-Komponenten.

Es wurde aber auch nicht vergessen, an die Community zurückzugeben. Auf github liegen einige Projekte, die im Umfeld von LHOTSE bei Otto entstanden sind. Der enhanced-wickettester beispielsweise wurde initial von mir entwickelt, dann im Team weiterentwickelt und von Otto der Community zur Verfügung gestellt.

Fazit

Mit dem Projekt LHOTSE hat Otto eine schwierige Aufgabe bewältigt und dabei vieles richtig gemacht. Wir haben bei dieser Aufgabe gerne unterstützt und sind - wie Otto - stolz auf das sehr gute Ergebnis.