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.

April 2016 (Update Mai 2017)


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!).


Zitat eines Team-Mitglieds: Jeder hat eine Rolle, daher gibt es kein Theater.
 

Wie wir zu unserem Rollen-Modell kamen

Das Wort „entwickelt“ im letzten Satz 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 pro Projekt immer zu einem neuen Team zusammengestellt und nach dem Projekt wurden diese Teams wieder aufgelöst. Projekt-Verantwortlicher konnte jeder werden, der das Interesse und die geeigneten Qualifikationen dafür hatte.

Die Projektorientierung, die nicht funktionierte

Das hört sich zwar sehr flexibel an, aber wir kamen bald darauf, dass es mehrere große Probleme gab:

  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 "Unternehmens-Kern", der Software-Entwicklung, für das Funktionieren eines Unternehmens unserer Art wichtig sind (z.B. Human Resources, Public Relations, Sales, Consulting).



Unsere 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 Strukturierung. 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

Leadership neu gedacht

Es gibt den bekannten Spruch: „Der Fisch fängt vom Kopf an zu stinken.“. Positiver ausgedrückt: Wie das Management agiert, spielt eine immens wichtige Rolle für das Funktionieren des Unternehmens und vor allem auch für Veränderungsprozesse. Unsere Philosophie: Es ist nicht Aufgabe des Managements Entscheidungen im Planungs- oder Projektalltag zu treffen. Jeder trägt Verantwortung für seinen Bereich und trifft in diesem selbstständig Entscheidungen. Wir wollen bewusst kein „Ich sag dir, was du tust UND WIE du es tust.“.


Ein Dilbert-Comic zum Thema Leadership
Quelle: http://dilbert.com/


Vielmehr muss das Management die Unternehmenskultur und den Nährboden dafür schaffen, dass Teammitglieder selbst die Entscheidungen treffen können, die im Arbeitsalltag wichtig sind. Das führt unserer Überzeugung nach nicht nur zu besseren Entscheidungen. Entscheidungen werden auch viel schneller getroffen, was letztendlich auch dem Projektfortschritt und damit dem Kunden hilft.

Auf dem Weg zur neuen Struktur: Fixe Teams

Die Entwicklung unseres neuen Rollenmodells und die Umstellung darauf erfolgte nach und nach. Aus den Projektverantwortlichen wurden Product Owner laut der Definition im Scrum-Rollenmodell. Product Owner sind die internen Stellvertreter des Kunden in unserem Team: Sie sind die Ansprechpartner unserer Kunden und repräsentieren die Wünsche und Anforderungen der Auftraggeber und User der Software.
Das Bild zeigt unsere sechs Product Owner, die sich gegenseitig unterstützen.
Unsere sieben Product Owner bilden ein Team und unterstützen sich gegenseitig (v. l. n. r. : Thomas Hiebl, Marcel Hauer, Johannes Wirgler, Johannes Widmann, Hans-Peter Zillner, Harald Deitzer und Rainer Wickenhauser).


Ein großer Schritt war die Festlegung permanenter EntwicklerInnen-Teams mit sogenannten Team Captains. Die Team Captains sind Software-Entwickler sowie auch Team-Ansprechpartner und verantwortlich für die Junior-Ausbildung im Team. Auf keinen Fall sind sie Team-Chefs. Auch hier gilt das Motto „Rollen, Verantwortlichkeiten und Teamwork statt Hierarchie“.

Das elfte Prinzip für Agile Software: “The best architectures, requirements, and designs emerge from self-organizing teams.”


Mit diesen fixen Teams sorgen wir jetzt für Stabilität im Kernprozess unseres Unternehmens, der Softwareentwicklung: Es gibt langfristig mehrere und fixe Ansprechpartner für bestimmte Projekte und mehrere Personen haben das Know-how und die Erfahrung mit den umgesetzten Lösungen. Auch Zwischenmenschliches spielt dabei eine Rolle: Wir achten darauf, dass in jedem Team EntwicklerInnen miteinander arbeiten, die einander gut ergänzen und Spaß am gemeinsamen Arbeiten haben.

Eine Softwareschmiede braucht mehr als nur Entwickler

Der nächste Schritt war die Definition weiterer Rollen. Jedes unserer Team-Mitglieder hat jetzt eine Rolle (in manchen Fällen auch mehrere). 

Eine interessante Evolution dabei war, dass Personen, die gleiche Rollen haben, automatisch Teams bilden. So sind zum Beispiel unsere Product Owner keine Einzelkämpfer, sondern arbeiten als Team, tauschen sich aus und unterstützen einander gegenseitig. Auch das Management des Unternehmens ist als Team organisiert.


Eine Darstellung unserer aktuellen Struktur und dem typischen Weg eines Projektes. Es geht von der Rolle Sales zum Product Owner, von diesem weiter an den Team Manager, der es wiederrum einem Team weitergibt.
Die Grafik zeigt (sehr vereinfacht) den Weg eines Projektes, den es in der neuen Struktur nimmt: Die Rolle "Sales" hat den Erstkontakt zum Kunden und gibt das Projekt danach an einen Product Owner weiter. Dieser bespricht mit dem Team Manager welches Team dafür ideal wäre. In Absprache mit den Team gibt der Team Manager diesem dann das Projekt zur Umsetzung. Jedes Team hat einen Team Captain, der als Ansprechparter für die anderen Rollen zur Verfügung steht. Wenn das Projekt einem Team zugeordnet ist, erfolgt die Projektkommunikation anschließend direkt: Kunde – Product Owner – Team.
 

Diese „Team-Bildung“ zeigt sich auch räumlich: Die Mitglieder eines Entwicklungs-Teams und jedes „Rollen-Teams“ (bzw. Rollen, die miteinander zu tun haben) sitzen gemeinsam in Büros. Eine kurze Nachfrage oder ein schneller Informations-Austausch sind also einfach möglich. Dadurch bekommen die Team-Mitglieder vieles in Echtzeit mit, ohne dass dafür lange Meetings organisiert werden müssen.

Die Rollen sind natürlich nicht in Stein gemeißelt! Wie die Software-Entwicklung an sich, verändert sich auch unser Unternehmen immer weiter. Neue Chancen und neue Herausforderungen sorgen für eine laufende Anpassung und Änderung unseres Rollen-Modells. Aktuell arbeiten wir zum Beispiel daran, mit teamübergreifenden Retrospektiven das Lernen voneinander zu fördern.

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 in internen 1-Wochen-Entwicklungszyklen.
  • Ein zentrale Rolle im Unternehmen ist der Team Manager, der sich um die teamübergreifende Aufteilung der Projekte kümmert.
  • Es gibt regelmäßige Meetings der „Rollen-Teams“ (Development-Teams, Product Owner, Sales, Management) um das große Ganze zu überblicken und sich gegenseitig abzustimmen.
  • Für den Überblick gibt es auch 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 statt Hierarchien, Teams statt Einzelkämpfer! Das führt unserer Erfahrung nach zu eindeutig motivierteren Mitarbeiterinnen und Mitarbeitern. Keine und keiner in unserem Team will nur Befehlsempfänger sein; alle können ihr Wissen und ihre Erfahrung einbringen, um mitzugestalten. Denn eines ist für uns klar: Ohne ein glückliches Team gibt es keine Software, die glücklich macht!

Video: Unser Team

Wer könnte besser erklären, was wir tun und wie wir arbeiten als unsere Team-Mitglieder? Daher haben wir die Scheinwerfer auf sie gerichtet und sie vor der Kamera interviewt. Das "Best of" sehen Sie hier – viel Spaß beim Anschauen!



Text: Isabel Birnstingl, Sven Schweiger, Thomas Hiebl & Johannes Widmann

 

Sie möchten mehr über uns erfahren und haben ein interessantes Software-Projekt für uns? Dann kontaktieren Sie uns!