Selbstorganisierende und funktionsübergreifende Teams sind ein Kernelement in agilen Projekten, aber keine Erfindung der agilen Bewegung. Sie werden seit vielen Jahrzehnten erfolgreich in japanischen und einigen amerikanischen Unternehmen eingesetzt. Diese einzigartige Managementmethode, bei der Führungskräfte als Coaches ohne Führungsfunktionen und weniger Führungsebenen agieren, wurde leider fast vergessen. Mit dem agilen Projektmanagement wurden in den letzten Jahren Empowerment und selbstorganisierende Teams wiederentdeckt. Lesen Sie in diesem Artikel, wie selbstorganisierende Teams entstanden sind, was ihre Eigenschaften sind und wie sie funktionieren.
Selbstorganisierende Teams gibt es seit Jahrzehnten
Die Prinzipien, Methoden und Werte, auf denen agiles Projektmanagement basiert, gibt es seit Jahrzehnten. Die meisten von ihnen stammen aus dem Toyota Production System (TPS), das in dem interessanten Buch “The Toyota Way” ausführlich beschrieben wird.
Das Toyota Produktionssystem entstand nach dem Zweiten Weltkrieg und war ein Treiber für viele effektive Managementmethoden, wie Lean Production, Lean Management, Business Process Reengineering und Six Sigma. Selbstorganisierende Teams waren ein Kernelement des TPS und wurden dann in den 1950er und 1960er Jahren in verschiedenen japanischen und einige Jahre später in amerikanischen Unternehmen erfolgreich eingesetzt.
Selbstorganisierende Teams waren in diesen Unternehmen sehr erfolgreich, aber überraschenderweise haben sie sich nie wirklich breit in der Industrie etabliert. Nur die Automobilindustrie hat von dem Toyota Produktionssystem und der Lean Production gelernt und profitiert. Obwohl verschiedene Studien in den 90er Jahren zeigten, dass selbstorganisierende Teams die Produktionskosten um 20-40% und die Produktivität um bis zu 50% gesenkt haben, wurden dieses fast vergessen, bis agiles Projektmanagement entstand.
Wenn Sie einen tieferen Einblick in die Ursprünge und Eigenschaften von selbstorganisierenden Teams erhalten möchten, kann ich das Buch von Kimball Fisher sehr empfehlen: Leading Self-Directed Work Teams – A Guide to Developing New Team Leadership Skills.
Was macht Teams in der Produktentwicklung erfolgreich?
Ein Kernelement im agilen Projektmanagement ist die Zusammenarbeit in Teams und das Anwenden von Wissen. Um mehr darüber zu erfahren machen wir kurz einen Abstecher in die Vergangenheit.
Hirotaka Takeuchi und Ikujiro Nonaka beschrieben 1986 im Harvard Business Review Artikel „The New New Product Development Game“ die Eigenschaften erfolgreicher Produkteentwicklungsteams. Der Inhalt des Artikels ist stark beeinflusst vom „Toyota Production System“ und japanischen Produkteentwicklungsmethoden z.B. bei Canon, Honda oder NEC aus den 1970er Jahren. In diesem Artikel werden wesentliche Eigenschaften von erfolgreichen Product-Development-Teams beschrieben:
- Built-in instability: Das Management stößt den Entwicklungsprozess an, setzt herausfordernde Ziele und Anforderungen und gibt dem Team größtmögliche Freiheit in der Entwicklung.
- Self-organizing project teams: Das Team arbeitet wie ein Start-up Unternehmen, es ist initiativ, geht Risiken ein und hat eine unabhängige Agenda: Die Teams charakterisieren sich durch folgende drei Eigenschaften:
- Autonomy: Die Teams organisieren sich selber.
- Self-transcendence: Stetiges lernen. Das Team strebt nach vorne und will immer besser werden.
- Cross-fertilization: Die Teams arbeiten funktionsübergreifend. Diese Diversität fördert neue Ideen und Konzepte, was zu erfolgreicheren Produkten führt.
- Overlapping development phases: Mit stark überlappenden Phasen wird der Entwicklungsprozess schneller und flexibler.
- Multilearning: Durch Lernen auf verschiedenen Unternehmensebenen und in Gruppen, durch stetigen Erfahrungsaustauch und durch den Kontakt mit der Umwelt kann man schneller auf verändernde Marktbedingungen reagieren.
- Subtle control: Das Management setzt genügend Checkpunkte, obwohl sich das Projektteam selbst organisiert. Damit sollen Instabilität, Unklarheiten und Spannungen vermieden werden.
- Organizational transfer of learning: Gelerntes Wissen soll in die Organisation einfließen, um sich stetig zu verbessern.
Die meisten dieser sechs Punkte beeinflussten agiles Projektmanagement und moderne Softwareentwicklung, insbesondere aber selbstorganisierende Teams.
Die geringe Erfolgsquote bei Softwareprojekten in den 1990er Jahren lag nicht in der Ausbildung der Mitarbeiter oder an der fehlenden Reife, der noch jungen Informatik. Die Hauptgründe dafür waren schwergewichtige, sequentielle Implementierungsmethoden und unzureichende Zusammenarbeit in Projekten. Ken Schwaber und Jeff Sutherland haben dies erkannt und dann aus dem Wissen von „The New New Product Development Game“ und eigenen Erfahrungen ein erfolgreiches Softwareentwicklungs-Framework entwickelt – SCRUM.
Was ist ein selbstorganisierendes Team?
Definition: Ein selbstorganisierendes Arbeitsteam ist eine Gruppe von Mitarbeitern, die tagtäglich die Verantwortung für sich und ihre Arbeit übernehmen mit einem Minimum an direkter Aufsicht. Mitglieder von selbstorganisierenden Teams übernehmen in der Regel Aufgaben, planen Arbeiten, treffen produktions- und/oder dienstleistungsbezogene Entscheidungen und ergreifen selbständig Maßnahmen bei Problemen.
Selbstorganisierend bedeutet nicht, dass das Team seine Ziele selber bestimmt. Die Strategie und die Ziele (was produziert oder entwickelt werden soll und bis wann) definiert das Management, der Projektsponsor bzw. der Kunde. Wie das Ziel bestmöglich erreicht wird und mit welchen Aktivitäten und Prozessen definiert dann das Team selbst.
Hier finden Sie einen sehr gut geschriebenen Artikel über den Unterschied zwischen Self-Organised vs. Self-Managed vs. Self-Directed Teams.
Übersetzt in den agilen Kontext heißt dies: Agile Projekte haben keinen Projektleiter, Teamleiter oder Manager. Der Product Owner definiert zusammen mit dem Kunden, Management oder Projekt Sponsor und Stakeholdern die Vision und Strategie des Projektes. Der Product Owner definiert dann das Ziel für den Release und den nächsten Sprints Das Development-Team beurteilt, ob dieses Ziel umsetzbar ist und entscheidet dann selbst, welche Aufgaben notwendig sind, um dieses Ziel zu erreichen. Es koordiniert und überwacht seine Arbeit selbst. Das bedeutet: Es organisiert sich selbst.
Jedes selbstorganisierende Team braucht einen Coach, und das ist in Scrum der Scrum Master, der dafür besorgt ist, dass das Development-Team möglichst effizient arbeitet.
Der Unterschied zwischen traditionellen Organisationen und selbstorganisierenden Teams
Die folgende Tabelle hilft Ihnen den Unterschied zwischen traditionellen Organisationen und selbstorganisierenden Teams besser verstehen.
Selbstorganisation ist ein Lernprozess
Die Arbeit selber zu organisieren ist für neue Development-Teams ein Lernprozess, der durch den Scrum Master wesentlich unterstützt wird. Weil Development-Teams enger zusammenarbeiten und kein „Chef“ vorhanden ist, treten Konflikte häufiger auf. Auch hier hilft der Scrum Master, damit das Team die Fähigkeiten erwirbt Konflikte positiv zu lösen und Entscheidungen einvernehmlich zu treffen. Die Zusammenarbeit im Development-Team ohne Führer ist anspruchsvoll – und dies muss ein Scrum-Team zuerst einmal lernen.
Ein selbstorganisierendes Scrum-Team ist nur erfolgreich, wenn es Werte, Prinzipien und Regeln definiert und diese auch lebt. Hier bilden die Scrum-Werte das Fundament für die erfolgreiche Zusammenarbeit.
Selbstorganisierende agile Projekte haben folgende Stärken:
- Erhöhte Flexibilität und Reaktionsfähigkeit
- größere Produktivität und schnelle Resultate
- verbesserte Qualität der Resultate
- durch ständiges Lernen werden sie immer leistungsfähiger
- Bessere Einstellung und Engagement der Mitarbeiter
- Die Arbeit ist sinnvoller, interessanter und lohnenswerter
Diese Eigenschaften fördern die Zusammenarbeit
Wichtig für die Selbstorganisation, die Teamdynamik und die Entwicklung des Teams ist, dass es sich an den agilen Werten orientiert und diese verinnerlicht. Aber auch folgende Eigenschaften jedes einzelnen Teammitglieds fördert die Zusammenarbeit und sorgt für ein Arbeitsumfeld, das Vertrauen schafft. [ (Larsen, 2004):
- Glaubwürdigkeit: Jeder sollte Konsequenz und Zuverlässigkeit in seiner Rolle zeigen.
- Zuhören: Jeder sollte Interesse zeigen und ein offenes Ohr haben.
- Offenheit: Jeder sollte sich öffnen und nicht hinter einer Maske verschanzen.
- Empathie: Jeder sollte sich in die Lage des anderen versetzen können.
- Feedback: Jeder sollte Feedback erwarten und eigenständig geben können
- Interesse: Jeder sollte ein natürliches Interesse am Team oder den Kollegen haben.
Sie können sich sicher vorstellen, dass dies natürlich Eigenschaften sind, die nicht bei jedem Teammitglied gleich stark ausgeprägt sind und die man nicht einfach so schnell lernen kann. Sie liegen meistens in der Persönlichkeit des Teammitgliedes. Daran arbeitet man teilweise Monate, Jahre oder das ganze Leben.
Ownership übernehmen
Ownership bedeutet: So im Projekt zu handeln, als würde ich mein eigenes Haus entwickeln und mein eigenes Geld dafür ausgeben. Dafür würde von Ihnen vermutlich jeder das Beste leisten. Habe ich recht?
Sie haben die Autorität zu Handeln und sind für ihr Handeln selber verantwortlich.
Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. (Agile Manifesto Principle)
Jedes Development-Teammitglied eines funktionsübergreifenden, selbstorganisierenden Development-Teams übernimmt Verantwortung und Initiative für sein Projekt, für seine Arbeit und für die Resultate, als wäre es sein eigenes „Kind“ das er entwickelt. Das Top-down Management traditioneller Projekte fördert diese Reife von Ownership leider nicht oft.
Um Ownership zu übernehmen sind zwei wesentliche Bestandteile notwendig sind:
- Das Management vertraut dem Scrum-Team und gibt ihm die Freiheit und Verantwortung.
- Das Scrum-Team übernimmt Verantwortung, nutzen die Freiheit und fördert eine Kultur der Autonomie und steigert damit seine Fähigkeit, ein leistungsstarkes Team zu werden.
Ein Kernelement von Scrum ist, dass das Development-Team nicht nur große Verantwortung übertragen wird, sondern es gleichzeitig auch bevollmächtigt ist. Das heißt, es entscheidet z.B. allein, wie viele Anforderungen es innerhalb des nächsten Sprints umsetzen kann. Es entscheidet auch selber, wie es die Arbeit organisiert und welche Arbeitsschritte dafür notwendig sind.
Wird wirklich jeder im Team gleich behandelt?
Eigentlich müsste jeder im selbstorganisieren Scrum-Team den gleichen Stellenwert haben und müsste gleich behandelt werden? Nach dem Motto:
Everyone is equal in my team – everyone sweeps the floor
Ja, dies trifft meistens zu. Aber in selbst-organisierenden Teams muss nicht jeder im Team immer gleich behandelt werden.
Wenn ein sehr erfahrenes Teammitglied sagt, “das wird schwer zu entwickeln sein”, sollten die anderen Teammitglieder diese Meinung entsprechend berücksichtigen. Wenn der Juniorpraktikant, den Sie gestern eingestellt haben, dasselbe sagt, sollten die Teammitglieder zuhören, aber dieser Meinung weniger Bedeutung beimessen. Sie sollten Meinungen gewichten auf der Erfahrung von Teammitgliedern bzw. ihrer Glaubwürdigkeit.
Jedes Teammitglied sollte den Respekt bekommen, den es verdient – gemäß dem Scrum-Wert „Respekt“.
Literatur zu diesem Artikel:
- John Richard Hackman, PhD, Buch: Leading Teams: Setting the Stage for Great Performances
- Kimball Fisher, Buch: Leading Self-Directed Work Teams – A Guide to Developing New Team Leadership Skills
- Jeffrey K. Liker, Buch: The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer
- Artikel: Von selbstorganisierenden zu selbstmanagenden Teams in Scrum – Was ist der Unterschied?
Hier gibt es noch mehr Wissen
Wollen Sie mehr erfahren, wie Sie Ihre agilen Projekte mit Scrum noch erfolgreicher machen? Mein Buch „Scrum – Agiles Projektmanagement und Scrum erfolgreich anwenden“ bringt Sie einen wichtigen Schritt weiter!
Kennen Sie jemanden, den dieser Beitrag auch interessieren könnte? Dann leiten Sie ihn einfach weiter oder teilen ihn. Danke!
