That’s how we roll:
Die Organisation der CSS
Keine mahagoni-getäfelten Chef-Büros, keine Befehle von oben, keine unklaren Verantwortlichkeiten: Jedes Team-Mitglied hat eine Rolle, die Entscheidungsfreiheit und Verantwortung bietet.
Was Sie in diesem Artikel lesen (tl;dr)
- In der Vergangenheit waren wir projektorientiert organisiert: Für jedes Projekt wurde ein Team neu zusammengestellt.
- Mit dieser sehr flexiblen Organisation gab es einige Probleme, die zur Entwicklung einer neuen Organisationsform führten.
- Wir haben jetzt fixe Entwicklungsteams, die mit Product Owner*innen zusammenarbeiten. Sogenannte "Communities of Practice" sorgen für den Wissensaustausch.
- Diese Organisationsform sorgt für eine einfache Ressourcen-Planung, konstantere Entwicklungsphasen und sich aus der Praxis ergebende Rollen mit klaren Kern-Aufgaben.
- Unsere Basis ist die Philosophie, dass jede*r Verantwortung im eigenen Bereich trägt und selbst entscheidet. Das Management muss die Unternehmenskultur und den Nährboden dafür schaffen, dass Teammitglieder selbst die Entscheidungen treffen können.
Wir sind ein Unternehmen, das individuelle Software für Kunden aus vielen Branchen umsetzt. Rund um diese sehr unterschiedlichen Projekte dreht sich bei uns alles: Die Planung, die Umsetzung und die Gewinnung neuer Aufträge. Und rund um diese Projekte hat sich auch unsere Organisation entwickelt, die auf Eigenverantwortung und Entscheidungsfreiheit setzt (siehe dazu auch das Gesetz nach Conway!).
„Jeder hat eine Rolle, daher gibt’s kein Theater.“
Wie wir zu unserer Organisationsform kamen
Die Struktur, die wir jetzt leben, gab es nicht von Anfang an. Drehen wir also die Zeit um ein paar Jahre zurück!
Damals war die Organisation unseres Teams rein projektorientiert: Zum Beispiel wurden unsere Softwareentwickler bei jedem Projekt zu einem neuen Team zusammengestellt, das nach dem Projekt wieder aufgelöst wurde. Projekt-Verantwortliche*r konnte jede Person werden, die das Interesse und die geeigneten Qualifikationen dafür hatte.
Die Projektorientierung, die nicht funktionierte
Das war zwar sehr flexibel, aber es gab mehrere große Probleme mit diesem Modell:
- Jeder einzelne Entwickler musste von allen Projektverantwortlichen „verplant“ werden. Das war aufwändig und hatte Konfliktpotential („Mein Projekt ist wichtiger!“, „Ich will diesen Entwickler im Projekt haben!“). Es gab auch niemanden, der den Überblick hatte und darauf schaute, dass jeder etwas zu tun hatte und niemand überlastet war.
- Die immer neu zusammengewürfelten Teams waren nicht ideal für größere Projekte, die über längere Zeit betreut wurden. Wenn ein Projekt abgeschlossen war, „zerstreute“ sich das Team. Wurde das Projekt weiterentwickelt oder gab es einen Fehler (aka: Bug) auszubessern, musste man sich einen Entwickler suchen, der sich damit auskannte und längst in einem anderen Team an einer ganz anderen Lösung arbeitete.
- Die Planung musste komplett umgeworfen werden, wenn Projekte später als geplant abgeschlossen wurden.
- Projekt versus „Kleinkram“: Die Planung von Aufgaben wie z.B. Schätzungen, Nacharbeit, Bug-Fixing und Wartung konkurrierte mit der Projekt-Arbeit.
- Die Planung von „Engpass-Ressourcen“ war schwierig: Manche Entwickler waren aufgrund deren speziellen Skillsets zwingend für ein oder mehrere Projekte notwendig. Sie mussten dann oft zwischen Projekten hin- und herspringen, was leicht zu einer Überlastung führte.
- Der Wissensaustausch bzw. das Teamlernen waren unkoordiniert.
- Hoher Kommunikationsaufwand war nötig, um einen Überblick über alle Projekte zu erhalten.
- Das Thema „Planung von Teilzeitmitarbeitern“ machte die Situation nicht einfacher.
Dazu kam, dass wir manche zusätzliche Rolle überhaupt noch nicht definiert hatten, die zum Erfolg eines Software-Unternehmens unserer Art beiträgt (z.B. Personalwesen, PR & Marketing, Backoffice).
Auf zu neuen Uf..äh, Rollen!
Um diese Probleme zu lösen, machten wir uns Gedanken über eine neue Organisationsform. Wir setzten uns zusammen und definierten gemeinsam folgende Ziele:
- Einfachere Ressourcen-Planung
- Konstantere Entwicklungsphasen (wenig bis kein Hin- und Herspringen zwischen Projekten, Einplanung von Zeit für unplanbare Arbeiten wie zum Beispiel Supportanfragen)
- Definierte Rollen mit klaren Aufgaben, die sich aus der Praxis ergeben
Die Basis für die Veränderung: Ein kollegial geführtes Unternehmen
Es gibt den bekannten Spruch: „Der Fisch fängt vom Kopf an zu stinken.“. Positiv ausgedrückt: Das Management spielt eine wichtige Rolle für das Funktionieren des Unternehmens und vor allem auch für Veränderungsprozesse.
Bei uns ist es NICHT die Aufgabe des Managements im Planungs- oder Projektalltag Entscheidungen zu treffen. Jedes Teammitglied trägt Verantwortung für seinen Bereich und entscheidet in diesem selbstständig. Also KEIN „Ich sag dir, WAS du tust UND WIE du es tust.“.
Wichtig dabei: Das Management muss die Unternehmenskultur und den Nährboden dafür schaffen, dass Teammitglieder selbst die Entscheidungen treffen können, die im Arbeitsalltag wichtig sind.
Die Inhaber des Unternehmens haben die Aufgabe, diejenigen Werte festzulegen, auf deren Basis sich die Unternehmenskultur entwickeln kann. Bei uns führten diese Werte zu einem „kollegial geführtes Unternehmen“. In diesem werden nicht nur bessere sondern auch schnelle Entscheidungen getroffen – und zwar genau da, wo sie benötigt werden: im Arbeitsalltag in den Teams und nicht im Management. Dies hilft letztendlich auch dem Projektfortschritt und damit unseren Kunden!
Auf dem Weg zur neuen Struktur: Fixe Teams und fix verbundene Product Owner
Wir entwickelten unser neues Modells nach und nach und stellten Schritt für Schritt unsere Organisation um.
Aus den Projektverantwortlichen wurden Product Owner*innen auf Basis der Definition nach Scrum. Product Owner*innen sind die internen Stellvertreter*innen des Kunden: Sie sind die Ansprechpartner unserer Kunden und repräsentieren die Wünsche und Anforderungen der Auftraggeber und User*innen der Software. Intern arbeiten sie je nach Projekt mal mit diesem und mal mit jedem Entwicklungsteam zusammen.
Unsere Softwareentwicklungsteams sind "permanent" und werden nicht wie in der Vergangenheit für jedes Projekt neu zusammengestellt. Die Teams haben darüber hinaus sogenannte Team Captains. Die Team Captains sind selbst Softwareentwickler in ihrem Team und sind darüber hinaus auch für die sozialen und organisatorischen Belange des Teams verantwortlich: Zum Beispiel fördern sie eine optimale Teamkultur, sind Ansprechpartner für die Product Owner*innen sowie auch Team-Ansprechpartner und sorgen für einen teamübergreifenden Wissensaustausch. Auf keinen Fall sind sie Team-Chefs. Auch hier gilt das Motto "Teamwork statt Hierarchie".
"The best architectures, requirements and designs emerge from self-organizig teams."
Mit unseren fixen Teams sorgen wir für Stabilität im Kernaufgabenbereich unseres Unternehmens, der Softwareentwicklung: Unsere Kunden profitieren von langfristig bestehenden Ansprechpartner*innen, die ihre Arbeitswelt und Prozesse kennen (Stichwort: Domain Driven Design).
Zusätzlich verfügen mehrere Softwareentwickler*innen über das Know-how und die Erfahrung mit den umgesetzten Lösungen. So werden zum Beispiel lange "Wieder-Einlern-Phasen" vermieden, wenn eine Softwarelösung erweitert wird, die schon länger im Einsatz ist.
Auch das Zwischenmenschliche spielt dabei eine große Rolle: Wir achten darauf, dass in jedem Team Entwickler*innen miteinander arbeiten, die einander gut ergänzen und Spaß am gemeinsamen Arbeiten haben. So fließt die volle Energie unserer Teams in die Softwarelösung und nicht in laufendes "Team-Rebuilding" oder gar Konfliktlösung.
Austausch zwischen den Teams
Der nächste Schritt war die Einsetzung von Communities of Practice:
Das sind Arbeitsgruppen, die an einer teamübergeifenden Verbesserung von Arbeitsprozessen und der generellen Zusammenarbeit im Unternehmen arbeiten. Dies führt unter anderem dazu, dass unsere Product Owner*innen keine Einzelkämpfe führen, sondern sich über Erfahrungen oder Probleme austauschen und sich gegenseitig unterstützen.
Unsere Rollen sind nicht in Stein gemeißelt
Wie die Software-Entwicklung an sich, verändert sich auch unser Unternehmen laufend weiter. Neue Chancen und neue Herausforderungen sorgen für eine laufende Anpassung und Änderung unseres Organisationsmodells.
Bei den Rollen schaffen wir neue, wenn sich in der Praxis zeigt, dass sie benötigt werden.
Bei uns werden somit die Rollen an den Arbeitsalltag und an die Teammitglieder angepasst und nicht umgekehrt!
Das haben wir jetzt davon!
Und so sieht nach den Veränderungsprozessen unsere "CSS-Welt" aus:
- Wir arbeiten jetzt zu 100% teamorientiert statt projektorientiert.
- Jedes Team arbeitet eigenverantwortlich, die meisten in internen 1-Wochen-Entwicklungszyklen.
- Es gibt regelmäßige Meetings innerhalb der Teams und der Communities of Practice um zu planen, sich intern abzustimmen und um das große Ganze zu überblicken.
Generell gilt bei uns: Rollen und Verantwortungen statt Hierarchien, Teams statt Einzelkämpfer! Das führt unserer Erfahrung nach zu eindeutig motivierteren Mitarbeiter*innen.
Niemand in unserem Team will nur Befehle empfangen; alle können ihr Wissen und ihre Erfahrung einbringen, um mitzugestalten und unser Unternehmen weiterzuentwickeln. Denn eines ist für uns klar: Ohne ein glückliches Team gibt es keine Software, die glücklich macht!