Ways of Working: So klappt selbstorganisiertes Arbeiten

In unserem Bestreben, ein T-förmiges, crossfunktionales und ausgewogenes Team zu werden, (ver)teilten wir Kompetenzen und Verantwortlichkeiten im Team.

Wo stehen wir?

In einem ersten Schritt mussten wir herausfinden, wer die Experten:innen und wo unsere blinden Flecken sind. In einem Workshop entwarfen wir eine Kompetenzmatrix für das Team und beantworteten die folgenden Fragen:

• Wo sind wir stark?
• Wo haben wir Engpassressourcen?
• Wer ist an welchem Thema interessiert? 

Die Kompetenzen haben wir in folgende Kategorien eingeteilt:

• Themen und Inhalte
  • Projekte
  • Domäne innerhalb eines Projektes
  • Stack
• Tools und Technologien
  • Software Architektur
  • DevOps
  • Back-End
  • Database
  • Front-End
  • Design
• Prozesse und Praktiken

Wie funktioniert sie?

Hinter jeder Farbe steht eine Zahl, die den Grad des Fachwissens angibt:

• 5 – Expert:in: Ich kann andere befähigen.
• 4 – Praktiker:in: Ich kann es machen.
• 3 – Lehrling: Ich möchte es lernen.
• 2 – Versteher: Ich habe davon gehört. / Ich verstehe, worum es geht.
• 1 – Unbeteiligte: Ich konzentriere mich im Moment nicht darauf.

Das System empfiehlt automatisch Themen, die Maßnahmen erfordern. Es rechnet wie folgt: 

Empfehlung = Wichtigkeit * Dringlichkeit

Mit der Dringlichkeit können wir Themen nach Relevanz ausschließen, inkludieren oder hervorheben. Da die Dringlichkeit der Multiplikator ist, beginnt die Nummerierung mit 0, sodass Themen auch komplett von der Empfehlung ausgeschlossen werden können. Der Faktor Wichtigkeit wird wie folgt definiert:

3 – sehr wichtig: 0 Expert:innen und 1 Praktiker:in
3 – sehr wichtig: 1 Expert:in und 0 Praktiker:innen
2 – wichtig: 0 Expert:innen und 2 Praktiker:innen
1 – weniger wichtig: 0 Expert:innen und 3 Praktiker:innen
1 – weniger wichtig: mindestens 2 Lehrlinge
0 – kein Handlungsbedarf: mindestens 2 Expert:innen
0 – kein Handlungsbedarf: mindestens 1 Expert:in und mindestens 2 Praktiker:innen

Je nach Ergebnis muss, sollte oder könnte das Thema im nächsten Zyklus angegangen werden. Das Gute an dieser Empfehlungslogik ist, dass bei einer längeren Urlaubsvertretung oder beim Ausstieg von Mitarbeiter:innen das Team den gesamten Vertretungs- oder Offboarding-Plan mit einem Klick abrufen kann. 
 

Wie geht’s weiter?

Als nächster Schritt definierten wir zwei Meeting-Formate, die die Verteilung der Kompetenzen fördern und den Prozess am Laufen halten.

Knowledge Bit(e)s sind unkomplizierte Meetings, die zwischen Mentor:in und Mentee sowieso geplant sind, aber mit einer Einladung innerhalb des Teams öffentlich gemacht werden. Somit kann jede:r entscheiden, ob das Meeting für einen selbst relevant ist und man teilnimmt. Es bedarf keiner besonderen Vorbereitung, on-the-spot Erklärungen im Code oder an Whiteboards reichen aus. Der erster Knowledge Bit(e) über unsere Chart-Bibliothek war für alle relevant: Front-End-Entwickler:innen wollten wissen, wie es funktioniert, Back-End-Entwickler:innen wieso wir welche Daten brauchen, Design- und Projekt-Manager:innen wo die Grenzen der Umsetzbarkeit liegen.

Der Knowledge Day dient der Aktualisierung der Kompetenzmatrix und der Zielsetzung für jedes Teammitglied. Innerhalb eines Zykluses lernen oder lehren wir. Basierend auf der Liste der Lernenden und Lehrenden wird eine personalisierte Fokustabelle erstellt und jedes Mitglied nimmt seine Lern- oder Lehraufgabe selbst in die Hand. Sollte jemand die Matrix zwischenzeitlich aktualisiert haben, erkennt das System die Änderung automatisch und kennzeichnet die Stelle. 

Anwendungsüberwachung #doitright

Hast du dich mal gefragt, wer sich um die Berichte unserer Überwachungstools kümmert, wie z. B. die Fehler von Sentry, die Betriebs- bzw. Ausfallzeiten oder die Leistungsüberwachung? Wir haben viele Tools, die uns helfen, die Qualität unserer Software und unseres Wartungssupports zu gewährleisten. Weil wir in der Vergangenheit mit Informationen überflutet wurden, musste sich etwas ändern!

Regeln für die Meldungen

Die Melderegeln zwischen Slack und Sentry wurden so geändert, dass die Priorität eines Fehlers deutlich wird: Nur schwerwiegende Fehler werden im Instant-Messenger (Slack) gemeldet. Am Front-End ist ein Fehler schwerwiegend, wenn ein Problem mehr als 3 Benutzer:innen betrifft. Am Back-End wird ein neuer Fehler sofort, aber höchstens ein Mal am Tag, gemeldet. Diese Meldungen müssen noch am selben Tag bearbeitet werden. Alle Fehler, die es nicht ins Slack schaffen, werden nur in Sentry gemeldet und müssen bis zum Ende der Woche bearbeitet werden.

Bereitschaftsdienst à la Fusonic 

Unsere Definition von Bereitschaftsdienst unterscheidet sich sehr von anderen: Wir schlafen nicht neben unserem Telefon und sind ständig erreichbar. Unser Bereitschaftsdienst bedeutet, dass die Person, die für die Anwendungsüberwachung zuständig ist, die schwerwiegenden Probleme während der Arbeitszeiten sofort analysiert, delegiert oder behebt. Die restlichen Fehler werden spätestens am Ende der Woche bearbeitet. Die jeweiligen Personen sind verantwortlich für unseren Notfallplan, ergänzen und aktualisieren ihn. Um die Kompetenzen zu verteilen und jeden im Team zu befähigen, ein Problem zu lösen, setzen wir auf Pair-Programming.

Rotierende Verantwortlichkeiten #teamup

Sharing is caring: Um Know-how zu teilen, teilen wir auch Verantwortung. Um Kompetenzen zu verteilen und Empathie zu fördern, übernimmt jede und jede einige Rollen im Team. 

Die Moderator:in moderiert Meetings, in dem sie das technische Equipment vorbereitet, das Meeting beginnt, abschließt und den Fokus in Diskussionen lenkt.
Bonus: um eine Berichterstattung an einer einzigen Person zu vermeiden, gibt jeder das Wort an eine andere Person weiter – als würden wir einen imaginären Ball weitergeben. Somit richtet sich der Fokus auf die ganze Gruppe und die Aufmerksamkeit bleibt erhalten.

Wer Bereitschaftsdienst hat, ist für die Anwendungsüberwachung jeweils am Front-End und am Back-End verantwortlich. Der Bereitschaftsdienst beginnt um 9:00, wobei die Rollen alle 2 Wochen rotieren. Für die Zuordnung nutzen wir die Tellspin, die für uns die Planung und Erinnerung im Slack übernimmt. Erinnerungen sind wie folgt eingestellt:

¹ private Erinnerung, um die Issues zu schließen
² um evtl. die Schicht zu übergeben, falls man nächste Woche nicht verfügbar ist

Wir haben noch weitere Ideen, die wir noch testen, bevor wir euch mehr darüber erzählen. Wie sind eure Teams organisiert? Nutzt ihr Tools und Methoden? Wenn ihr Lust auf einen Austausch habt, melde euch jederzeit via E-Mail bei mir. Ich freu mich auf eure Fragen, Gedanken und eigenen Erfahrungen.