Produktentwicklung - Wie wir Lego bei ELEMENT nutzen, um mehr darüber zu lernen, wie wir arbeiten

Insurance techblog_Lego technic

Eine der Fragen, die ich gerne in Bewerbungsgesprächen stelle, ist, was sie als das Beste an ihrem aktuellen Arbeitsprozess betrachten? Auf was sind sie stolz und würden mit ELEMENT teilen, wenn sie beitreten? Es gibt auch bei ELEMENT Insurance eine Reihe von Praktiken, die ich eines Tages mitnehmen würde. Die folgende Praxis ist die Verwendung von Legosteinen zur Visualisierung unseres Arbeitsablaufs und liefert eine zuverlässige und wertvolle Datenquelle darüber, wie wir als Team arbeiten.

Das Problem

Eine kleine Hintergrundgeschichte. Eines Tages auf der Heimfahrt begann ich darüber zu grübeln, wie mein Tag verlaufen war. Schnell und einfach erinnerte ich mich an all das langweilige sowie eilende Anfragen, die hereingekommen waren. Das frustrierte mich – und hat mich an meinem Job zweifeln lassen. Während der Retrospektive am nächsten Morgen ist mir aufgefallen, dass es nicht nur mir so ging. Einer der Entwickler sprach an, dass er das Gefühl habe, dass wir in diesem Sprint zu viel Zeit auf die Behebung von Bugs sowie auf kurzfristige Anfragen verwendet hätten. Ebenso war der Glauben, zu viel in Meetings eingebunden zu sein, im Team weit verbreitet. Diese Annahmen waren für uns Grund genug anzunehmen, wir hätten ein Produktivitätsproblem. Und um dieses zu beheben, benötigten wir mehr Daten darüber, wo wir stehen und wo wir hinmöchten. „Ich habe ein Gefühl“ ist leider nicht die beste Kategorie und ist relativ schwer zu messen. Daher mussten wir uns ein Modell überlegen, wie wir Daten über unseren Workstream sammeln und sichtbar machen konnten, um dann Probleme zu finden und effektiv zu beheben.

 

Einen Haken hat diese Sache jedoch. Zu messen, wie viel Zeit wir für verschiedene Aufgaben benötigen, roch ziemlich nach Micro-Management. Und dieser Geruch ist nicht derjenige, welcher gute Leute lockt. Um das zu vermeiden arbeiten wir bereits mit arbeiten wir mit No-Estimate Schätzungen, OKRs, themenbasierten Roadmaps und anderen fortschrittlichen Arbeitsweisen.

Das Modell

Unser Agile Coach war an dieser Überlegung beteiligt, hat recherchiert und dann Lego-Steinchen vorgeschlagen. Diese Idee basiert auf den Erfahrungen von Joe Wright sowie einem früheren Modell von Michael Hunger, vintage 2008.

 

Also, wie soll das ganze funktionieren? Jeder Lego-Stein repräsentiert eine Arbeitsstunde einer Person. Den Farb-Code, den wir benutzen, ist folgender:

  1. Grün für Geplantes
  2. Orange für ad-hoc Anforderungen
  3. Blau für Meetings
  4. Rot für Anforderungen, die aus Fehlern entstehen
  5. Schwarz für Wartungsarbeiten
  6. Grau für Administratives

 

Jetzt mehr in die Details.

 

Geplantes ist etwas, dass man wirklich plante, zu tun. Es passt zu unseren Zielen, wurde ausgearbeitet, geplant, ist in den Sprint gegangen (wir bei ELEMENT arbeiten mit Scrum) und wird somit bearbeitet. Perfekt.

 

Ad-hoc Anforderungen sind fast wie geplante Arbeit, ohne eben geplant zu sein. Diese fallen beispielsweise an, wenn jemand an dich herantritt und dich darum bittet, etwas so schnell wie möglich zu erledigen, nur dieses kleine Ding, und „es wird auch nicht lange dauern“. Nur dass es dann heißt, die eine Sache, an der man gerade arbeitet, zu verlassen, sich auf eine neue einstellen muss, dann die eigentliche Arbeit zu machen, zu testen und einzusetzen, und dann alles zurück in umgekehrter Reihenfolge. Meist stimmen diese Anforderungen jedoch mit unseren Zielen überein und ein Sinn der Arbeit ist erkennbar. Aber das Ganze kann störend und demotivierend sein.

 

Meetings. Selbsterklärend. Wir alle lieben sie.

 

Anforderungen, die aus Fehlern entstehen fallen bei zweierlei an:

  1. Wenn ein Team eine Sache nicht richtig gemacht hat. Also wenn Tests fehlschlagen, das Monitoring Dashboard rot wird, ein Bug in Jira gemeldet wird usw.
  2. Wenn das Team nicht die richtigen Dinge gemacht hat. In diesem Fall ist das Feature da, aber es ist nicht das, was gefordert oder erwartet wurde. Also muss es neu gemacht werden. Nebenbemerkung: das hat nichts mit Produktexperimenten zu tun, A/B Testing und normaler iterativer Produktentwicklung.

 

Wartungsarbeiten betreffen technische Schulden, Refactoring und System-Updates.

 

Administrative Aufgaben sind alles andere: Recruiting, Onboarding, Offboarding, Organisatorisches, Geplantes Lernen, Compliance (wir sind schlussendlich ein Versicherungsunternehmen) und Wasauchimmer.

 

The Prozess

Und so machen wir es: Zweimal täglich, vor dem Mittagessen und nach jedem Arbeitstag, wählt jedes Team-Mitglied einen Lego-Stein in der Farbe entsprechend der erledigten Tätigkeiten. Unsere Erfahrung zeigt, dass das die optimale Frequenz ist. Wenn man es seltener macht, neigen Leute dazu, vergesslich zu werden und das zu erinnern, was den gefühlsmäßig größten Eindruck gemacht hat (z.B. Fehler, Meetings und Spontane Anforderungen).

Am Ende eines jeden Tages würde unser Team so etwas gebaut haben:

Am nächsten Tag, während wir bei unserem täglichen Stand-up den Vortag besprechen, zeigt jedes Team-Mitglied seine Lego-Steine und steckt diese auf das Sprint Board des Teams (wir machen Zwei-Wochen-Sprints) entsprechend der jeweiligen Kategorie.

Insurance techblog_Lego technic_pic1
Insurance techblog_Lego technic_pic2

Wir starten jede Retrospektive – in unserem Fall alle zwei Wochen – indem wir uns die Lego-Platte ansehen und besprechen, wie wir denken, die Zeit verbracht zu haben, und wie sie wirklich verwendet wurde. Danach werden die Daten für eine längerfristige Analyse digitalisiert – in einfachen Worten: in Excel eingetragen. Diese Analyse müssen wir jedoch noch vornehmen. Eine der Annahmen, die wir testen möchten, ist, ob es einen Zusammenhang zwischen den verschiedenen Kategorien gibt. Z.B. weniger Meetings oder Wartungsarbeiten ergeben einen größeren Fehlerbedarf.

 

Nach der Retro kommen die Lego-Steine bis zum nächsten Sprint zurück in die Kiste.

Die Ergebnisse

Wir haben vor etwa einem Jahr angefangen, den Workstream mit Lego-Steinen zu visualisieren. Und es hat nicht mehr als ein paar Sprints benötigt, bis wir wertvolle Einblicke in die Aufgabenverteilung in der Arbeit der Teams bekommen haben. Mittlerweile hat uns der Prozess folgendes gezeigt:

  1. Mehr als 60% der Arbeit sind geplant. Wir sind gut.
  2. Etwas 25% der Zeit wird in Meetings verbracht. Was aussieht, als sei es viel. Aber ist es das auch wirklich? Die Antwort auf diese Frage haben wir noch nicht gefunden. Wir konnten außerdem verschiedene Ansätze testen, wie wir die Zahl der Meetings begrenzen können, und die Legos haben uns eine Benchmark gegeben, um die Auswirkungen zu messen.
  3. Manche Team-Mitglieder haben öfter Meetings und lösen diese öfter aus. Jedoch geht die Zahl dann runter, wenn der Product Owner Urlaub macht. Da ich selbst ein Product Owner bin, nehme ich an und hoffe, dass das ein kurzzeitiger Effekt ist. Natürlich bin ich aber bereit, meine Zeit zur Prüfung dieser Idee zu opfern und auf eine lange Reise zu gehen. Natürlich aus rein wissenschaftlichem Interesse.
  4. Die Zahl der Ad-Hoc Anforderungen ist in unserem Fall nicht wirklich hoch – nur etwas mehr als 2%. Obwohl der gefühlte Effekt immer noch ziemlich bedeutend ist, haben wir nun belastbare, objektive Daten, auf die wir uns beziehen können, was die Team-Moral verbessert hat. Daten siegen!

 

Abgesehen von den direkten Lerneffekten, gibt das Bauen der Lego-Türmchen eine sinnvolle und leichte Möglichkeit, um die Verteilung unseres Workstreams über die Zeit hinweg zu messen. Außerdem hilft es, Standups zu erleichtern und liefert sichtbaren Input für unsere Retros und Planungen. Da es Spaß macht, ist es außerdem Teil unserer täglichen Routine geworden und ist ein Teil der Team-Kultur, welcher ohne Spannungen auskommt.

 

Autor: Anton Kovnir, Product Owner, ELEMENT Insurance


 

Werden Sie Teil des Unternehmens, das die Zukunft der Versicherung gestaltet. Wir suchen derzeit nach Talenten, um unser Tech-Team bei ELEMENT zu erweitern:

 

Sr. Full Stack Engineer (m/f/x)

Senior Product Owner (m/f/x)