Job-Titel: Gift für die Unternehmenskultur?

Anknüpfend an meinen Artikel über gesunde Unternehmenskultur hat sich gestern eine interessante Diskussion über Titel und Rollen in modernen Unternehmen ergeben. Aufhänger war, dass Job-Titel auf Visitenkarten und im Email Footer zwar Eindruck schinden, aber grundsätzlich nichts über die Qualifikation des Gegenübers aussagen.

Natürlich ist es beeindruckend, wenn auf der eigenen Karte Team Lead, Senior Developer oder Principle Engineer steht – es sollte aber auch darauf geachtet werden, dass das Firmenlogo geprägt ist und in das Papier ein seichter Goldfaden eingewebt ist. Das ist gut für’s Ego und… gut für’s Ego 😉

Wie passen Titel in eine Welt, in der selbstorganisierte Teams im Vordergrund stehen und sich Hierarchie selbständig bilden und dynamisch neu ausrichten kann?

Ein typisches Beförderungs-Beispiel:

Björn und Thomas haben vor vier Jahren gleichzeitig als Entwickler bei einer Software-Firma begonnen. Im Laufe der Zeit hat sich herausgestellt, dass beide sehr gute Entwickler sind, die ihr Metier beherrschen.

Björn kann gut reden, mit Menschen umgehen und Ergebnisse in Reviews „verkaufen“. Thomas ist eher der ruhige Typ, liefert durchdachten, getesteten Code und lebt förmlich die Nerd-Kultur.

Irgendwann kommt der Tag, an dem darüber nachgedacht wird, die Teamstruktur zu erweitern und Karrierepfade für die beiden zu entwickeln, da sie ja schon „so lange mit dabei“ sind. So ein Quatsch. Elke an der Wurst-Theke unseres Vertrauens ist auch schon seit 12 Jahren dort und kein Senior Meat Manager.

Karriereplanung 1.0

Der Director of Human Ressources schnappt sich einen seiner HR Assistent Manager und beuftragt ihn mit der Planung:

  • Es wird ein Ranking aller Entwickler auf Basis der Betriebszugehörigkeit und den letzten beiden Performance Ratings erstellt.
  • Wie erwartet stehen Björn und Thomas ganz oben.
  • Er gruppiert alle Entwickler zu Einheiten und ist am Ende begeistert, dass er tolle Teams zusammengestellt hat.
  • Das Ergebnis wird in Powerpoint aufbereitet und dem Director of HR vorgestellt, der sich in den wenigsten Fällen die Mühe machen wird, den Vorschlag noch einmal zu überdenken.

Die Lösung des HR Assistent Managers hat beide zum Team Lead gemacht. Yeah!

  • Björn wird Team Lead Frontend Development
  • Thomas wird Team Lead Backend and Workflows

Im schlimmsten Fall, hat das Unternehmen jetzt nicht nur zwei gute Entwickler weniger, sondern auch zwei schlechte Führungskräfte mehr.

Die besten Ideen entstehen im Team

Wäre es besser gewesen, die Teams selbständig darüber entscheiden zu lassen, wie die Workload künftig aufgeteilt wird? Meine Antwort lautet: Ja!

Team-Erweiterungen, Reorganisation und Neuausrichtung funktionieren am besten, wenn alle Beteiligten einbezogen werden, konstruktive Vorschläge einbringen und sich selbst positionieren dürfen.

Wenn wir uns von der Titel-Denke lösen und unser Ego hinten anstellen, werden sich wie von Zauberhand ideale Teams bilden.

Zurück zum Beispiel:

Die Idee, Björn dem Team Frontend zuzuordnen ist dem Grunde nach sinnvoll, da er gut reden und dem Kunden „Sichtbares“ verkaufen kann. Björn würde unabhängig von seinem neuen Titel in einem selbstorganisierten Team mit hoher Wahrscheinlichkeit als Speaker ausgewählt werden.

Thomas blieibt wahrscheinlich Experte im Team Backend, der darauf achtet, dass die Software so läuft wie erwartet und bei Präsentationen eher in eine fachliche Rolle schlüpfen.

Sofern beide mit der künftigen Trennung einverstanden sind. Dies ist ein entscheidender Punkt: Teams sind nur dann erfolgreich, wenn das Miteinander passt und die Mitglieder aufeinander abgestimmt sind. Individuelle Skills sind im Team bekannt und jeder kann dort zu Bestleistungen aufblühen, wo er der „Experte“ ist.

Wozu brauchen wir dann „disziplinarische“ Hierarchie?

Studien haben gezeigt, dass sich durch den Wegfall von Machthierarchien natürliche Hierarchien bilden, in denen sich jeder durch individuelle Merkmale wie fachliche Qualifikation oder Sozialkompetenz positioniert.

Viele Menschen verbinden ihre Zugehörigkeit in einer Machthierarchie mit dem Einkommen, was ein klarer Fehlschluss ist. Das Gehalt sollte völlig losgelöst von der Zugehörigkeit innerhalb des Unternehmens-Konstrukts betrachtet und von den individuellen Skills und dem Beitrag zur Wertschöpfung abhängig gemacht werden.

Auch wenn unsere Elke von der Wurst-Theke seit Jahren mit Herzblut die gleiche Tätigkeit ausführt, heißt es nicht, dass ihr Gehalt noch dem von vor 12 Jahren entspricht.

Bei Morning Star, einem der weltweiten Marktführer für Produkte aus Tomaten, hat jeder Angestellte einmal im Jahr die Möglichkeit, einem unabhängigen Entscheidungsgremium darzulegen, warum er oder sie eine Gehaltssteigerung verdient hat. Da dies zur Tradition des Unternehmens gehört, hat niemand das Gefühl, mit gebücktem Haupt einen Vorgesetzten anbetteln zu müssen, mehr Gehalt haben zu wollen.

Definierte Rollen und Prozesse

In einer Welt, die sich eigenständig organisiert, kann es schnell vorkommen, dass Beteiligte durch Freiheiten überfordert werden. Klingt komisch, ist aber so.

Dafür ist es essentiell, dass zumindest ein Rahmenmodell definiert wird, wie Entscheidungen getroffen werden sollen und welche Abstimmungswege und -schnittstellen erforderlich sind. Teamübergreifende Kommunikation, Transparenz und Wissens-Austausch ist das A&O, damit nicht nur Teilbereiche eines Unternehmens, sondern das gesamte Unternehmen „rund“ läuft.

Frameworks für die agile Skalierung wie z.B. Less oder das Spotify Modell bieten einen guten ersten Einblick, wie übergreifendes Wachstum, gemeinsame Wertschöpfung und eine funktionierende Organisation aussehen könnten, sind aber keine Stangenware, um auf jedes Unternehmen reproduziert zu werden.

Und was lernen wir daraus?

  • Trennt Euch vom Ego und lasst uns auf fancy Visitenkarten-Titel verzichten.
  • Motiviert Kolleginnen und Kollegen dazu, sich aktiv in die Unternehmensentwicklung einzubringen.
  • Entwickelt Vorschläge und Ideen, um aus dem Hamsterrad eine bessere Welt zu bauen.
  • Individuelle Skills und Expertenwissen sind wichtiger als die Position auf dem Organigramm.

Ich freue mich auf Eure Kommentare zum Thema und bin offen für ergänzende oder andere Sichtweisen 🙂

5 Punkte, um eine gesunde Unternehmenskultur zu erkennen

Wir haben am Freitagnachmittag in illustrer Runde diskutiert, wie man als Externer ein Gefühl für die gelebte Kultur in einem Unternehmen bekommen kann. Über die Kultur spiegelt sich vieles wider:

  • Wie funktionieren Prozesse und Entscheidungswege?
  • Werden Mitarbeitende als „Personalkapazitäten“ oder Individuen betrachtet?
  • Ist der Umgang miteinander formal-distanziert oder steht das Wir-Gefühl im Vordergrund?

1. Meetings

Wie häufig finden Besprechungen statt und wie lange dauern sie? Gibt es ein vorab festgelegtes Ziel oder trifft man sich zum allgemeinen Austausch ohne Agenda? Wie gut sind die Teilnehmenden vorbereitet? Startet und endet das Meeting pünktlich?

Ich habe zurückblickend viel zu häufig an Meetings teilgenommen, zu denen ich keinen Beitrag leisten konnte oder die für mich so uninteressant waren, dass im Nachgang ein Blick auf das (gern auch stichtpunktartige) Ergebnis-Protokoll ausgereicht hätte.

Über die Einhaltung von Start- und Endzeiten erkennt man schnell, ob die Planung des Zeitfensters realistisch gewesen ist und ob Motivation und Zuverlässigkeit auf dem erforderlichen Mindestmaß sind. Wenn sich herausstellt, dass ein Großteil der Teilnehmenden unvorbereitet erschienen ist, hilft oft nur verschieben, da ein „offenes Brainstorming“ derjenigen, die sich selbst gern reden hören, nicht zielführend ist.

Meeting-Erfolgsfaktoren

  • Als Organisator sollte bei der Gestaltung der Einladung und der Bestimmung des Teilnehmerkreises darüber nachgedacht werden, wer unbedingt erforderlich ist und wer informativ im Nachgang eingebunden werden kann.
  • Brauchen wir eine Besprechung oder gibt es andere Wege, um ein Thema abzustimmen: Viele Themen lassen sich hervorragend über Instant Messaging (Slack, Teams, Mattermost, Rocketchat) diskutieren, ersparen eine Menge Zeit und dokumentieren automatisch die Herleitung einer Entscheidung.
  • Die goldene Regel: Kein Meeting ohne Agenda und ohne Vorbereitung. Auch wenn ein offener Austausch geplant ist, hilft eine für alle Teilnehmenden einsehbare Agenda, keine wichtigen Punkte zu vergessen.
  • Präzise Zeitplanung: Da Teilnehmende häufig Anschlußtermine haben, empfiehlt sich eine feste Endzeit (z.B. immer 15 Minuten vor der vollen Stunde). Das funktioniert natürlich nur dann, wenn alle Mitwirkenden ihre Kalender vernünftig pflegen und Zeiten für Orts- und Gebäudewechsel frühzeitig blocken.

2. Pronomen

Dominiert in Gesprächen das „Wir“ oder das „Ich“ ?

Auch wenn Blender und Pfeifen inzwischen darauf konditioniert sind, wann sie in der Wir-Form reden sollten, erkennt man recht schnell, ob echter Team-Spirit besteht. Wird auf Augenhöhe kommuniziert oder spielen sich immer wieder die gleichen Personen in den Vordergrund? Halten sich Krümel-Kollegen*innen zurück, wenn der vermeintliche Kuchen am sprechen ist oder bringen sie sich in Workshops und Diskussionen gleichebrechtigt ein?

3. Work/Life Balance

Zu welchen Zeiten arbeiten die Menschen im Unternehmen? Wirken sie im Allgemeinen eher gestresst oder gelassen? Wird die Leistungserbringung vor Ort erwartet oder gibt es Möglichkeiten, um ortsnabhängig zu arbeiten?

Viele Unternehmen legen großen Wert darauf, insbesondere im Recruiting-Prozess auf eine tolle Work/Life Balance hinzuweisen. Potentielle Bewerber*innen sollen zum Einstieg begeistert werden. Leider hört man im Alltag viel zu oft, dass eine Präsenzkultur besteht, bedingt sinnvolle „Kernarbeitszeiten“ definiert sind oder auch freie Tage gestrichen werden „mussten“. Ein Bekannter von mir verfügte über ein Überstundenkonto jenseits der 150 Stunden und wurde von seinem Arbeitgeber in den Zwangsurlaub geschickt. Das kann auf Dauer nicht gesund sein.

Gerade für „Wissensarbeiter“ sollte es möglich sein, zeit- und ortsunabhängig zu arbeiten. Jeder Mensch hat Zeiten und Orte, in/an denen er oder sie am produktivsten ist und niemand sollte wertvolle Urlaubstage, die der Erholung dienen sollten, „verbrennen“ müssen, weil der Nachwuchs krank geworden ist oder ein Handwerker kommen muss.

Indikatoren & Erfolgsfaktoren

  • Definiert sich die Leistungserbringung ausschließlich über gebuchte Arbeitszeit oder über generierten Impact?
  • Besteht die Möglichkeit, zeit- und ortsunabhängig zu arbeiten?
  • Gibt es Initiativen außerhalb der üblichen Arbeitszeiten wie z.B. Sport-Teams und gemeinsame Unternehmungen?
  • Werden freie Zeiten für Ehrenämter angeboten oder sogar als Unternehmen ehrenamtlich etwas bewirkt?

Nachgedanke

Bei selbstorganisierten Teams, in denen alle darauf bedacht sind, ihre gesetzten Ziele gemeinsam zu erreichen, regeln sich Punkte wie Kernzeiten, Serviceverfügbarkeit und Vertretungsregelungen üblicherweise von selbst. Wenn die Kommunikation funktioniert und gegenseitiges Vertrauen & Transparenz den Alltag bestimmen, wird gern auch einmal spontan eingesprungen oder ein abgestimmter „Plan B“ entwickelt.

4. Konflikte

Wie wird in Konfliktsituationen miteinander umgegangen? Werden diese schnell und für alle Seiten verträglich gelöst? Oder werden selbst einfache „Buschfeuer“ über Vorgesetzte eskaliert?

Grundsätzlich ist es im ersten Schritt wichtig zu verstehen, was die eigentliche Ursache des Konflikts ist. Liegt die Entstehung in fachlich begründeten Differenzen oder wird etwas auf der persönlichen Ebene ausgefochten? Werden Konflikte untereinander und im Team gelöst? Oder schwelen sie lange vor sich hin, bis ein Flächenbrand entsteht?

Statt top-down für eine schnelle Lösung zu sorgen ist es die Aufgabe einer modernen Führungskraft, frühzeitig als Moderator und Facilitator einzuspringen und eine neutrale Lösung, durch die kein Beteiligter als „Verlierer“ hervorgeht, zu finden. Leider gleichen Gespräche zur Konfliktlösung heutzutage immer noch häufig einem Gerichtsprozess, in dem die Beklagten Argumente vorbringen, so dass eine Partei gewinnt und eine verliert – oder es müssen Kompromisse eingegangen werden, bei denen keiner ein gutes Bauchgefühl hat.

5. Wissensaustausch & Lernen

Jedem Unternehmen sollte daran gelegen sein, dass die Mitwirkenden auf allen Ebenen zum Lernen, Weiterbilden und Entwickeln angehalten werden. Auch wenn der Spruch „Man lernt nie aus“ schon etwas abgedroschen klingt – es ist so. Wir Menschen befinden uns in einem lebenslangen Lernprozess, der große Chancen mit sich bringt.

Lew Platt, der ehemalige CEO von HP hat es auf den Punkt gebracht:

If HP knew what HP knows, we would be three times as profitable.

Lew Platt, CEO Hewlett-Packard

Häufig wissen Unternehmen nicht, welche Skills sich im Unternehmen verbergen, da sich niemand die Mühe gemacht hat, dies herauszufinden. Die Förderung von aktivem Lernen kostet zwar Geld, ist aber für alle Beteiligten ein gutes Invest.

Erfolgsfaktoren

  • Gibt es eine Vielfalt an Aus- und Weiterbildungsangeboten?
  • Gibt es eine Bibliothek und aktuelle Zeitschriften, die allen zur Verfügung stehen?
  • Findet ein regelmäßiger Austausch von Wissen untereinander statt? (z.B. durch Open Spaces oder Brownbag Meetings)
  • Werden Initiativen wie „Working Out Loud“ oder „LernOS“ angeboten?
  • Die Killer-Frage, die kein Unternehmen der „alten Garde“ gerne hört: Trauen sich Mitarbeitende Bildungsurlaub in Anspruch zu nehmen?

Product Owner Skills & Voraussetzungen

Kein Projekt kommt ohne ihn aus: Der Product Owner ist DIE entscheidende Schlüsselperson, die für Erfolg oder Misserfolg stehen kann. Als Schnittstelle zwischen Business und Entwicklungsteam dürfen allerdings nicht nur kommunikative Skills mitgebracht werden.

Er trägt die Produkt-Vision im Herzen. Er weiß, wie sich ein Produkt kurz-, mittel- und langfristig entwickeln soll. Er kennt die Personas seiner Stakeholder, weiß Kundenfeedback zu interpretieren und daraus seine Strategie zu entwickeln.

Aber was für Skills muss ein Product Owner mitbringen, damit nachhaltige Werte geschaffen werden? Hier meine persönliche Top 5.

Neugier

Product Owner sind wissenshungrig. Sie sind nicht nur Beobachter, sondern auch Zuhörer, Reisende, Innovatoren und Fragesteller. Ihre wichtigsten Schnittstellen? Stakeholder, Kunden und Entwickler.

Prozesse müssen präzise verstanden und abgebildet werden, bevor sie durch IT unterstützt, optimiert oder automatisiert werden können. Der PO ist im Idealfall sowohl in den Prozessen als auch in der Technologie zuhause.

Ich habe einige Fälle erlebt, in denen sich Prozess-Verantwortliche als Product Owner gesehen haben, da ausschließlich sie die „notwendige Fachkompetenz“ für ein Projekt mitbringen würden. Diese weit verbreitete Fehleinschätzung kann ein massives Scheitern von Projekten zu Folge haben, da Interessen in der Regel einseitig vertreten werden. Fehlendes technologisches Fachwissen und utopische Vorstellungen bei der Umsetzung kosten Zeit und Geld.

Warum ich den idealen PO auch als Reisenden sehe? Um einen Blick über den eigenen Tellerrand zu erhalten, ist ein brancheninterner und -übergreifender Austausch auf Konferenzen, Open Space Formaten oder in klassischen „Arbeitsgemeinschaften“ erforderlich. Schlüsselkunden haben ihren Sitz nicht immer im Haus nebenan und ein persönliches Gespräch ist oft besser als ein Telefonat.

Auch sollte der Product Owner einplanen, sich regelmäßig mit dem Service-Desk oder Kundenservice auszutauschen. Als Geheimtipp empfehle ich einmal pro Woche eine Stunde lang Kundenanfragen zu lesen, um Probleme und Wünsche
frühzeitig zu erkennen und langfristig bestmöglichen Value zu schaffen.

Vision

Die klare Definition der Vision ist das, worauf der Product Owner sein Handeln aufbauen kann. Die Vision hilft nicht nur ihm, richtige Entscheidungen zu treffen, sondern schafft auch Transparenz in Richtung Business (Stakeholder) und Technologie (Entwickler). Eine offene Kommunikation der Vision ist entscheidend, um zu verstehen, welches übergeordnete Ziel mit einem Produkt erreicht werden soll.

Gerade für Entwickler, die an „eher unscheinbaren“ Backlog-Items arbeiten, ist ein Verständnis der Vision wichtig, um den Sinn hinter den großen Ganzen zu erkennen und sich als Bestandteil des Gesamterfolgs zu betrachten.

Ein Bekannter von mir hat einen aus meiner Sicht ziemlich stumpfen Alltag im Access Management. Er ist tagtäglich damit beschäftigt, Firewall-Regeln einzurichten, zu bearbeiten und zu prüfen. Seine nahezu einzige Schnittstelle zur Außenwelt ist das Service Desk, über das er Aufträge erhält. Und das seit Jahren. Da er sich allerdings als Schlüsselposition in der IT-Security betrachtet und damit einen maßgeblichen Beitrag zur Unternehmenssicherheit beiträgt, ist er glücklich. Und zufriedene Teamplayer sind heutzutage essentiell wichtig, um produktiven Output zu liefern.

Kommunikation

Verbindliche und transparente Kommunikation gegenüber Team-Mitgliedern und Stakeholdern sind essentiell für erfolgreiche Projekte. Gerade dann, wenn mehrere oder viele Teams ein gemeinsames Ziel verfolgen, muss jeder seine Rolle verstehen und darf nicht auf Basis von Halbwissen, Annahmen oder Mutmaßungen handeln. Auch müssen die richtigen Tools zur Verfügung gestellt werden, um sicherzustellen, dass Informationen stets verfügbar sind und Fragen schnell und effizient geklärt werden können.

Der Product Owner muss nicht nur gute Kommunikations-Skills mitbringen sondern sich auch in unterschiedliche Team- und Persönlichkeitstypen hineinversetzen können. Er muss die Strategie und Vision des Business verstehen und diese in den Entwicklungsteams Wirklichkeit werden lassen. Wenn die Kommunikation nicht klar und transparent ist, gerät ein Projekt schnell in Schieflage.

Hingabe

Getreu dem Motto „Home is where your heart is“ muss ein Product Owner sich mit dem Vorhaben identifizieren und voll und ganz hinter ihm stehen. Der ideale PO versucht, bei jedem Meeting dabei zu sein und mit allen Team-Mitgliedern zusammenzuarbeiten. Er hat stets ein offenes Ohr für Fragen und ist bereit, seine Vision und sein Wissen zu teilen.

Filtern, Bewerten und auch mal Nein-Sagen

Natürlich darf der Product Owner kein chronischer Verweigerer sein und sich als Blockade zwischen Business und Development aufbauen. Trotzdem ist es wichtig, dass er nicht jede einzelne Idee umsetzen lässt. Er braucht auch den Mut „nein“ sagen zu können und Wünsche sehr weit unten im Backlog zu platzieren.

Der Versuch, jeden Wunsch erfüllen zu wollen, endet häufig darin, dass das
Team das Projektziel aus den Augen verliert, der Entwicklungsprozess zu langsam voranschreitet und Ergebnisse ausbleiben.

Wichtig ist, und das sollte selbstverständlich sein, das „Nein“ nett zu verpacken und beispielsweise auf ein späteres Release zu verweisen. Es passiert schnell, dass Ideengeber auf Feedback verzichten, weil sie davon ausgehen, dass Vorschläge „sowieso nicht“ berücksichtigt werden. Und das leitet einen langsamen, qualvollen Tod der Innovationskultur ein.

Agile Frameworks

Als das Agile Manifest im Jahr 2001 erstmalig veröffentlicht wurde, folgten mit Scrum, DSDM und Extreme Programming die ersten Frameworks auf Basis der agilen Werte.

Agiles Manifest


Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.

Der Fokus dieser Frameworks ermöglicht es auch heute noch, dass kleine Teams auf effizientem Weg mit geringem bürokratischen Aufwand hochwertige Ergebnisse liefern.

Agile Methoden haben inzwischen auch im Mittelstand, bei Konzernen und öffentlichen Körperschaften an Wichtigkeit gewonnen, so dass jüngere Frameworks gewachsen sind, die large-scale Implementationen mit sehr großen Teams ermöglichen.

Grundsätzlich muss man sich vor der Einführung eines Frameworks folgende Fragen stellen:

  • Wie groß ist die Entwicklungsorganisation?
  • Wie komplex ist das Produkt?
  • Wie groß ist die Gesamtorganisation?

Was bleibt von Scrum & Co. übrig?

Projekte werden soweit herunter gebrochen, dass Teams nach wie vor an kleinen, überschaubaren Projekten arbeiten. In der nächsten organisatorischen Stufe werden diese Projekte zu Programs zusammengefasst. Alle Teams arbeiten miteinander an einem Program. Die Herausforderung ist, dass die Teams so locker organisiert werden, dass sie genug Freiheit für eine kreative Entfaltung und die Schaffung von Innovation haben, aber trotzdem so strukturiert arbeiten, dass sie übergreifende Erwartungen und Anforderungen erfüllen.

Komplex ist außerdem die Koordination, wann ein Projekt startet und abgeschlossen sein wird: Die Definition von Aufgaben, das Management des „Work in Progress“ und die Planung der nächsten Schritte erfordert viel Steuerung und Kommunikation.

Large-Scale Frameworks

SAFe („Scaled Agile Framework“)

Das Scaled Agile Framework gehört aufgrund seiner hohen Verbreitung zu den populärsten Methoden, große agile Teams zu steuern. Eines der größten Unternehmen in Deutschland, das SAFe einsetzt, ist die Volkswagen AG.

SAFe wurde in 2007 erstmalig von Dean Leffingwell in Buchform veröffentlicht und seitdem regelmäßig verbessert und aktualisiert. Die aktuelle Version 4.6 ist im Oktober 2018 erschienen. SAFe versteht sich als Sammlung von Strukturen, Methoden und optimierten Workflows. Zudem ist der Zertifizierungsprozess klar definiert und sehr ausgereift.

Ähnlich wie Scrum schreibt das Framework genau vor, wie SAFe einzusetzen ist. Dies beinhaltet:

  • Aufbauorganisation (Strukturen, Rollen, Abhängigkeiten)
  • Prozess mit definierten Zeitpunkten für die Artefakt-Generierung
  • Methoden
  • Praktiken

Aufgrund der Komplexität ist SAFe nur in großen Strukturen einsetzbar und bietet zudem die Möglichkeit, die Entwicklungs-Organisation an bestehende Konzernstrukturen anzubinden. Die einzelnen Projekt-Teams arbeiten auf Basis einer erweiterten, modifizierten Form von Scrum.

LeSS („Large Scale Scrum“)

LeSS ist, einfach ausgedrückt, eine erweiterte Form von Scrum, bei der eine zusätzliche Ebene die Entwicklungsteams miteinander vernetzt. Diese übergeordneten Teams bestehen aus bis zu zwei Mitgliedern der Entwicklungsteams, die an regelmäßigen, übergreifenden Meetings teilnehmen und die Schnittstelle zu anderen Teams darstellen.

Die zusätzlichen Abstimmungen beinhalten ein übergreifendes Sprint Planning und Daily Standup. Weiterhin gibt es eine „overall retrospective“, die in der Woche nach dem Sprint Review stattfindet und an der bedarfsabhängig Mitglieder der Entwicklungsteams teilnehmen.

Für alle Teams gilt eine Definition of Done. Sprint-Dauer, -Beginn und -Ende sind ebenfalls synchron. Teams haben allerdings die Möglichkeit, die Definition of Done intern strenger auszulegen und durch eigene Anforderungen zu erweitern. Ziel ist, dass nach jedem Sprint ein Produkt besteht, das potentiell bereitgestellt werden kann („shippable product“).

Trotz der Größe der entwickelnden Organisation gibt es nur einen Product Owner und ein Product Backlog. Der Product Owner wird allerdings durch die Teams, die direkt mit Kunden und anderen Stakeholdern zusammenarbeiten, bei der Pflege des Backlogs unterstützt.

Weiterhin ist vorgesehen, dass ein Scrum-Master fulltime für bis zu drei Teams tätig ist. Organisatorische/disziplinarische Manager sind optional. Ihr Fokus liegt aber weniger auf der Organisation des Tagesgeschäfts, sondern darauf, Werte innerhalb des Entwicklungszyklus zu definieren und zu schaffen.

Der Einsatz von LeSS bietet sich an, wenn zwei bis acht Teams gemeinsam an einem Produkt arbeiten. Für großere Implementierungen gibt es „LeSS Huge“, bei dem bis zu 1000 Entwickler koordiniert werden können.

DaD („Disciplined Agile Delivery“)

Während Scrum üblicherweise davon ausgeht, dass bereits eine vorhandene Entwicklungsorganisation besteht, beschäftigt sich das DaD Framework mit der Initiierung eines Entwicklungsprozesses, quasi einem „Sprint Zero“, den es in Scrum formal nicht gibt.

„Disciplined Agile Delivery“ fungiert als Orientierungs- und Entscheidungshilfe für die Einführung agiler Methoden:

  • Modellierung
  • Dokumentation
  • Governance

Hierbei besteht die Möglichkeit, die Organisationsstruktur nahezu individuell zu definieren. DaD bezeichnet sich als „Hybrid Agile“. Das bedeutet: Es werden verschiedene Modelle und Methoden aus unterschiedlichen Frameworks (SAFe, Scrum, Kanban, Lean) miteinander vereint.

Dabei gliedert sich das Vorgehen in drei Phasen:

Inception Phase
Vision des Projekts entwickeln, Risiken identifizieren, Arbeitsumfeld schaffen

Contruction Phase
Erstellung eines potentiell bereitstellbaren Produkts, Qualitätssicherung

Transition Phase
Bereitstellung der Lösung

Maßnahmen in allen Phasen
Sicherstellung der Projektvision, Risiken adressieren, Optimierung der Teamprozesss und Arbeitsumgebung/Infrastruktur

Der Lifecycle der Produktentwicklung basiert hauptsächlich auf Scrum, wird aber um die straffe Verfolgung einer definierten Strategie (Vision/Mission) erweitert. Für den Erfolg der Umsetzung sind nicht nur das Entwicklungsteam, sondern alle Personen innerhalb der Organisation verantwortlich.

Agile Scaling Cycle

Der „Agile Scaling Cycle“ ist weniger ein Framework sondern mehr ein Vorgehen zur Entwicklung einer agilen Organisation. Durch ihn soll sichergestellt werden, dass die Flexibilität, Produktivität und die Innovationskraft, die auf Team-Ebene besteht, auch bei einer wachsenden agilen Organisation und größeren Projekten sichergestellt werden kann.

Das zyklische Vorgehen in drei Schritten ermöglicht es, neue und bestehende Organisationsstrukturen zu entwickeln und nachhaltig zu verbessern:

Step 1: Abhängigkeiten reduzieren
Projekte werden soweit herunter gebrochen, dass möglichst wenig Abhängigkeiten bestehen. Wohl bemerkt: Wenig bedeutet nicht „keine“.

Step 2: Teams koordinieren
Die verbleibenden Abhängigkeiten (fachlich und technisch) werden im zweiten Schritt des Cycles bestmöglich koordiniert und gesteuert.

Step 3: Unternehmen entwickeln
Auf Basis der gewonnenen Erfahrungen wird die Organisation weiterentwickelt und verbessert.

Mit diesem iterativen Verfahren wird langfristig sichergestellt, dass eine optimale Organisation größtmöglichen Value liefern kann.

Spotify Culture

Der Vollständigkeit halber möchte ich abschließend noch die „Spotify Culture“ nennen. Der schwedische Musikdienst hat inzwischen weltbekannte agile Strukturen und Vorgehen entwickelt. Aufgrund des hohen Innovationswertes werde ich in einem gesonderten Artikel darauf eingehen.

Fazit

Die Wahl des individuell „richtigen“ Frameworks ist stark abhängig vom Vorhaben, vorhandenen Organisationsstrukturen und der derzeitigen Arbeitsweise von Teams. Auch Hybridmodelle sind denkbar. Wichtig ist, dass eine initiale Zündung zum agilen Wandel (egal ob bottom-up oder top-down) stattfinden muss.

Agilität ist der Grundstein einer zukunftssicheren Organisation, in der nachhaltig Werte geschaffen werden und die langfristig auf zufriedene, eigenverantwortlich-tätige Mitarbeiter mit dem richtigen Mindset bauen kann.

Neuer Trailer: Star Wars „Die Macht erwacht“

Wahnsinn, 10 Jahre nach der „Rückkehr der Sith“ ist es endlich wieder soweit: Der neue Star Wars Film „The Force Awakens“ („Die Macht erwacht“) kommt ins Kino und gestern ist der Vorverkauf gestartet. Glücklicherweise habe ich in der Mittagspause noch 8 Tickes in der Loge des Astor Grandcinema in Hannover ergattern können, so dass am 17. Dezember 2015 ein epischer Kino-Abend bevorsteht, auf den ich mich seit der Ankündigung vor über einem Jahr freue.

Weiterlesen