Zum Inhalt springen

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.

Letzte Änderung: April 2022


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. 
  • Diese sorgt für eine einfache Ressourcen-Planung, konstantere Entwicklungsphasen und sich aus der Praxis ergebende Rollen mit klaren Kern-Aufgaben.
  • Basis ist unsere Philosophie, dass jede*r Verantwortung im eigenen Bereich trägt und selbst enscheidet. Das Management muss die Unternehmenskultur und den Nährboden dafür schaffen, dass Teammitglieder selbst die Entscheidungen treffen können.
  • Wir haben jetzt fixe Entwicklungsteams mit fix verbundenen Product Ownern. Sogenannte "Communities of Practice" sorgen für den Wissensaustausch. 


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.“

CSS-Teammitglied


Wie wir zu unserer Organisationsform kamen

Das Wort "entwickelt" im letzten Absatz zeigt es schon: Die Struktur, die wir jetzt leben, gab es nicht von Anfang an. Drehen wir also die Zeit um ein paar Jahre zurück!

Die Organisation unseres Teams war damals rein projektorientiert: Zum Beispiel wurden unsere Softwareentwickler*innen bei jedem Projekt immer zu einem neuen Team zusammengestellt und nach dem Projekt wurde dieses Team wieder aufgelöst. Projekt-Verantwortliche*r konnte jede*r werden, der/die das Interesse und die geeigneten Qualifikationen dafür hatte.


Die Projektorientierung, die nicht funktionierte

Das hört sich zwar sehr flexibel an, es gab aber mehrere große Probleme mit diesem Modell:

  1. 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 hat und niemand überlastet war.
  2. 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 eigentlich schon wieder in einem anderen Team an einer ganz anderen Lösung arbeitete.
  3. Die Planung musste komplett umgeworfen werden, wenn Projekte später als geplant abgeschlossen wurden.
  4. Projekt versus „Kleinkram“: Die Planung von Aufgaben wie z.B. Schätzungen, Nacharbeit, Bug-Fixing und Wartung konkurrierte mit der Projekt-Arbeit.
  5. 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.
  6. Der Wissensaustausch bzw. das Teamlernen waren unkoordiniert.
  7. Hoher Kommunikationsaufwand war nötig, um einen Überblick über alle Projekte zu erhalten.
  8. Das Thema „Planung von Teilzeitmitarbeitern“ machte die Situation nicht einfacher.


Dazu kam, dass wir manche Rollen überhaupt noch nicht definiert hatten, die neben dem "Unternehmenskern", der Software-Entwicklung, für das Funktionieren eines Unternehmens unserer Art wichtig sind (z.B. Personalwesen, PR & Marketing, Backoffice). 


Darstellung der alten Organisationsform: keine fixen Teams, keine klaren VerantwortlichkeitenUnsere alte Struktur machte die Planung schwer und hatte etwas Konfliktpotential...


Auf zu neuen Uf..äh, Rollen!

Auf der Suche nach Lösungen für diese Probleme machten wir uns Gedanken über eine neue Organisationsform. Wir setzten uns zusammen und definierten gemeinsam folgende Ziele:

  1. Einfachere Ressourcen-Planung
  2. Konstantere Entwicklungsphasen (wenig bis kein Hin- und Herspringen zwischen Projekten, Einplanung von Zeit für unplanbare Arbeiten wie zum Beispiel Supportanfragen)
  3. Definierte Rollen mit klaren Kern-Aufgaben, die sich aus der Praxis ergeben


Leadership neu gedacht

Es gibt den bekannten Spruch: „Der Fisch fängt vom Kopf an zu stinken.“. Positiv ausgedrückt: Wie das Management agiert, spielt eine wichtige Rolle für das Funktionieren des Unternehmens und vor allem auch für Veränderungsprozesse. Unsere Philosophie: Es ist nicht Aufgabe des Managements im Planungs- oder Projektalltag Entscheidungen zu treffen. Jeder 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.“.

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. Den Inhabern des Unternehmens kommt dabei die besonders wichtige Aufgabe zu, die Werte festzulegen auf deren Basis sich die dazu passende Unternehmenskultur entwickeln kann. Wir sind überzeugt, dass ein „kollegial geführtes Unternehmen“ nicht nur zu besseren Entscheidungen führt. Entscheidungen werden auch viel schneller getroffen – und zwar genau da, wo sie benötigt werden: in den Teams im Arbeitsalltag 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

Die Entwicklung unseres neuen Organisationsmodells und die Umstellung darauf erfolgte nach und nach. Aus den Projektverantwortlichen wurden Product Owner auf Basis der Definition nach Scrum. Product Owner 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 arbeitet jede*r Product Owner mit einem fix verbundenen Entwicklungsteam zusammen.

Unsere Software-Entwicklungsteams 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 Software-Entwickler 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 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."

11th Principle of Agile Software


Mit unseren fixen Teams sorgen wir für Stabilität im Kernaufgabenbereich unseres Unternehmens, der Softwareentwicklung: Unsere Kunden profitieren von langfristig bestehenden Ansprechpartnern, 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. Dies hilft zum Beispiel bei Funktionserweiterungen einer langfristig eingesetzten Softwarelösung lange "Wieder-Einlern-Phasen" zu vermeiden. Auch Zwischenmenschliches 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:

Product Owner und Team Captains arbeiten in permanenten Arbeitsgruppen an einer teamübergeifenden Verbesserung von Arbeitsprozessen und der generellen Zusammenarbeit im Unternehmen. Dies führt unter anderem dazu, dass unsere Product Owner keine Einzelkämpfer*innen sind, sondern sich über deren Erfahrungen oder Probleme austauschen und sich gegenseitig unterstützen. 

Hier eine sehr vereinfachte Darstellung unserer Organisationsform: Es gibt fixe Teams mit zugeordneten Product Ownern. Im Unternehmen haben manche zwei oderer mehrere Rollen. Die Hauptrollen werden durch die schwarzen Männchen dargestellt; die grauen stehen für zusätzliche Rollen. Die gestrichelten Linien rund um die Product Owner sowie Team Captains zeigen die Communities of Practice. 


Rollen sind in unserem Unternehmen 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 Organisations-Modells. Bei den Rollen verfolgen wir den Weg dann neue zu erschaffen, wenn sich in der Praxis zeigt, dass sie benötigt werden – und nicht umgekehrt. 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 (Team Captains, Product Owner) um zu planen, sich intern abzustimmen und um das große Ganze zu überblicken.
  • Für den Überblick über die für Projekt- und Produkt-Entwicklung anstehende Arbeit gibt es ein zentrales Product Backlog (unternehmensweite, team- & projektübergreifende „Liste von Arbeit“): Jegliche Arbeit, die von Entwicklungsteams geleistet werden soll, muss in diesem System verplant werden.


Generell gilt bei uns: Rollen und Verantwortungen statt Hierarchien, Teams statt Einzelkämpfer! Das führt unserer Erfahrung nach zu eindeutig motivierteren Mitarbeiter*innen. Keine und keiner in unserem Team will nur Befehlsempfänger*in sein; 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!