Was sind selbstorganisierende Teams?

Donnerstag, 28. Oktober 2010 von  
unter Fachartikel Scrum

Zusammen mit den Begriffen der agilen Softwareentwicklung beziehungsweise dem agilen Projektmanagement wird auch immer öfters von selbstorganisierenden Teams gesprochen und oft betont, dass diese selbstorganisierenden Teams ein wichtiger Bestandteil der agilen Welt ist. Aber was genau bedeutet das denn, wenn ein Team selbstorganisierend ist?

„Das ist doch ganz einfach“, wird uns oft entgegnet, „das sind Teams, die ihre Arbeit selber organisieren“. Das ist doch schon mal ein Ansatz: Die Arbeit wird anders, „selber“ organisiert. Und was genau damit gemeint sein kann, ob es wirklich nur bei der Selbstorganisation der Arbeit bleibt und welche Konsequenzen das hat, genau damit wollen wir uns in diesem Artikel beschäftigen.

Fangen wir im ersten Schritt mal mit der Definition eines Teils der Fragestellung an, was verstehen wir denn unter einem Team?
Als Team verstehen wir im Folgenden eine Gruppe von Personen, die innerhalb eines Unternehmens gemeinsam eine bestimmte Aufgabe zu erfüllen haben. Dabei kann es sich grundsätzlich sowohl um interdisziplinäre Projektteams handeln, die bestimmte Projektziele erreichen sollen wie auch um Funktionsgruppen, wie beispielsweise die Systembetreuung eines Unternehmens, die bestimmte Maintenanceaufgaben wahrnehmen. All diesen Teams ist gemeinsam, dass das Team als solches eine bestimmte Aufgabe hat und die Teammitglieder zur Erreichung dieser Aufgabe miteinander interagieren.
Da derzeit meistens noch im Zusammenhang mit agiler Softwareentwicklung von selbstorganisierenden Teams gesprochen wird, werden wir uns in diesem Artikel manchmal auf softwareentwickelnde Projektteams beziehen. Die meisten der besprochenen Aspekte gelten jedoch auch für alle anderen Arten von Teams.

Wenn wir von selbstorganisierende Teams sprechen, was ist denn dann eigentlich ein nichtselbstorganisierendes Team, von dem wir uns ja jetzt scheinbar abgrenzen möchten?
Für diese Definition bietet sich die klassische Art der Teamorganisation an, die wir heute noch in den meisten Organisationen beobachten können. Eine Gruppe von Personen, die von einem Teamleiter geführt wird und in der jedes Teammitglied die Aufgaben durchführt, die ihm von seinem Teamleiter zugeordnet werden. Und dabei werden sowohl der Zeitpunkt wie auch die Art der Durchführung vom Teamleiter oder anderen organisatorischen Vorgaben vorgegeben. Der Großteil der Verantwortung und das Wissens über die Zusammenhänge liegen dabei beim Teamleiter, wofür er ja oft auch besser bezahlt wird. Diese Form der Teamorganisation zu diskreditieren, wollen wir uns an dieser Stelle ersparen. Welche Folgen sie haben kann (und ich möchte hier betonen, dass wir hier von können und nicht von müssen sprechen), ist Ihnen als Leser dieses Artikels selber schon bekannt.

Kommen wir also endlich zu dem, was uns wirklich interessiert, was bedeutet das Selbstorganisieren bei selbstorganisierenden Teams? Vorweg die Anmerkung, dass es dafür keine DIN Norm gibt und auch keine andere verbindliche Vorschrift, wann ein Team als selbstorganisierend gilt und wann nicht. Wir werden gleich eine Reihe von Aspekten besprechen, die Teil der Selbstorganisation eines Teams sein können. Welche davon dann für ein spezielles Team wirklich Sinn machen, hängt immer von den Umständen ab, unter denen dieses Team arbeiten muss und ist mit gesundem Menschenverstand zu entscheiden. Bedenken sie dabei, die Selbstorganisation ist kein Selbstzweck und es gibt auch keinen Orden dafür. Das warum des Ganzen wollen wir uns später ansehen.

Wir hatten es bereits am Anfang, ein wichtiger Punkt bei der Selbstorganisation ist die Organisation der Arbeit. Oder auch: Wer macht Was Wann! Beim wer macht was geht es erst mal darum, wer überhaupt was machen kann. Es gibt gerade bei Projektteams zwei extreme Ausprägungen für die Verteilung der notwendigen Fähigkeiten im Team: Spezialisten oder Generalisten.
Im ersten Fall kann jede notwendige Tätigkeit oft nur von einer, wenn das Team Glück hat von zwei Teammitgliedern ausgeführt werden. Damit beantwortet sich die Frage nach dem wer macht was quasi automatisch. Im zweiten Fall kann jeder im Team alles, das bedeutet, jede notwendige Tätigkeit kann von jedem Teammitglied in einer verantwortbaren Qualität durchgeführt werden. Ein hoher, aber nicht unmöglicher Anspruch, vor allem wenn man ihn dadurch etwas abmildert, das alle notwendigen Tätigkeiten nur von mindestens zwei oder besser drei Teammitgliedern ohne Qualitätsverlust durchführbar sein müssen.
Die Form der Selbstorganisation liegt darin, dass das Team selber entscheidet, welche Ausprägung der Wissensverteilung es wählen möchte, eher die Spezialisierungen oder doch die Generalisierung. Und das Team ermittelt auch selber welche Tätigkeiten für die erfolgreiche Erfüllung aller Teamaufgaben notwendig sind und welche Skills dafür im Team zur Verfügung stehen müssen. Wird externes Knowhow benötigt, ist es Aufgabe des Teams zu beschreiben, was genau benötigt wird, der eigentlichen Einkauf wird in der Regel dann jedoch durch andere Stellen im Unternehmen erfolgen. Geht es dabei jedoch um die Einstellung neuer Mitarbeiter für das Team, dann sollte das Team ein Mitspracherecht bei der Entscheidung haben. Denn das Team kann am besten beurteilen, ob ein neuer Mitarbeiter sowohl vom fachlichen wie auch sozialen Skill ins Team passt.
Entscheidet sich das Team eher für die Variante der generalisierten Wissensverteilung, dann liegt es auch in der Verantwortung des Teams für die notwendige Verteilung des Wissens zu sorgen. Das kann durch schriftliche Dokumentation erfolgen oder durch regelmäßige Vorträge im Team oder durch konsequente Zusammenarbeit von immer zwei Kollegen bei der Durchführung von Aufgaben (in der Softwareentwicklung auch als Pair Programming bezeichnet). Wichtig ist hierbei, dass Wissen, dass noch verteilt werden muss konsequent identifiziert wird. In einem mir bekannten Team führen wir hierfür regelmäßig eine sogenannte Truck-Faktor-Analyse durch. Das bedeutet wir analysieren für jedes Teammitglied, welche Auswirkungen hätte es für das Team wenn der Mitarbeiter morgen von einem LKW (Truck) überfahren würde und damit von heute auf morgen dem Team unwiderruflich nicht mehr zur Verfügung stände. Natürlich können Sie das bei sich auch weniger brachial formulieren, z.B. der Kollege ist wegen Steuerschulden über Nacht aus dem Land geflohen und nun nicht mehr auffindbar oder ähnliches. Sie verstehen schon, worauf es ankommt. Und dann überlegen Sie, ob ohne diesen Kollegen notwendige Tätigkeiten im Team nicht oder nur mit Schwierigkeiten durchführbar wären. Und wenn ja, beschließen Sie, wie Sie das vermeiden können.

Damit ist schon mal die Frage geklärt, wer KANN was. Jetzt kommen wir zur Frage zurück, wer MACHT was. Von außen werden Anforderungen an das Team gestellt. Ein selbstorganisierendes Team bricht die Anforderung in tatsächlich durchzuführende Tätigkeiten (auch als Tasks bezeichnet) runter, gibt sofern gefordert Aufwandsschätzungen ab und verteilt die dadurch entstehende Arbeit innerhalb des Teams. Diese Verteilung der Arbeit kann dadurch geschehen, dass das Team sich regelmäßig oder bei Bedarf trifft und im Gespräch die Aufgaben verteilt oder aber auch durch bestimmte Mechanismen, die allerdings ebenfalls vom Team bestimmt werden. So ein Mechanismus ist zum Beispiel einen Teamwand wie bei Scrum oder Kanban, auf der die anstehenden Tasks aufgeführt sind und die Teammitglieder je nach Verfügbarkeit sich die Aufgaben selber nehmen.

Dann haben wir gerade gesehen, dass eventuell geforderte Aufwandsschätzung vom Team selber erstellt werden und nicht von jemand außerhalb. Das ist sofort einsichtig, da nur der, der die Aufgabe durchführen soll auch wirklich sagen kann, wie lange er dafür brauchen wird. Wenn wir das jetzt noch damit kombinieren, dass das Team selber organisiert, wer was macht, dann ist natürlich sofort klar, dass das Team auch bei der eigentlichen Projektplanung eine wesentliche Rolle spielt. In Scrum ist das beispielsweise durch das Sprint Planningmeeting gelöst. Der Product Owner, ein Produktmanager, Anforderungsmanager oder wie auch sonst die Rolle bezeichnet wird, die dafür verantwortlich zeichnet fachliche Anforderungen anzunehmen, zu bewerten und zu priorisieren stellt dem Team vor, welche fachlichen Anforderungen/Aufgaben in welcher Priorität zu erfüllen sind. Und das Team bestimmt anschließend, welche Tätigkeiten und Aufwände sich daraus ergeben und bis wann diese durchführbar sind, bzw. welche Aufgaben innerhalb eines bestimmten Zeitraums erfüllt werden können.
Klingt verwirrend und aufwändig? Wenn ich unbedingt für die nächsten 24 Monate planen möchte bestimmt. Dann doch besser als einzelkämpfender Projektleiter alleine die Planung machen? Wenn Sie damit bessere, realistischere Projektpläne bekommen, lassen Sie mich es bitte wissen 🙂 Doch das ist eine andere Diskussion.

Was ist, wenn absehbar ist, dass das Team die aktuelle Planung nicht einhalten kann? Traditionell greift nun ein Projektleiter/Teamleiter ein und verordnet Maßnahmen. Nicht bei selbstorganisierenden Teams. Wir kommen später noch zu dem Punkt der Übernahme von Verantwortung durch Team und Teamitglieder. Auch hier ist das Team gefordert zu entscheiden, welche Maßnahmen sinnvoll erscheinen um entweder die Planung doch noch erfüllen zu können oder die Auswirkungen durch die Nichterfüllung zu minimieren. Das kann selbstverordnete Mehrarbeit sein, die Reduzierung der technischen Ansprüche an die Lösung (halt im ersten Schritt nicht das superneue supercoole Framework von XY einsetzen sondern erstmal was bewährtes) oder die Konzentration auf die wichtigsten fachlichen Features.

Was fällt noch unter die Selbstorganisation? Da fällt zum Beispiel auch die Art, wie gearbeitet wird drunter. Bei Softwareentwicklern sind das zum Beispiel Programmiervorgaben, welche Tools verwendet werden, Dokumentation im Code, welche Tests sind zu schreiben bzw. durchzuführen, welche weiteren Maßnahmen sind zur Erhöhung der Arbeitsqualität einzuhalten wie beispielsweise Pair Reviews oder Test Driven Development, Continous Integration oder die Wahl der Iterationslänge.

Was das Team möglicherweise auch selber regeln kann ist die Anwesenheit. Ja, es gibt Situationen und Umstände, in denen die unternehmens- oder bereichsweite Vorgabe von Kernarbeitszeiten Sinn macht. Und in vielen Fällen sind diese Vorgaben leider nur einer formalistischen Denkweise geschuldet. Wenn ein Team in einer bestimmten Phase keine Schnittstellen zu anderen Mitspielern hat oder diese nicht zeitnah benötigt werden, was spricht dann dagegen, dass das Team nachts arbeitet wenn dieses dem Team entgegen käme. Oder die Teammitglieder zeitversetzt arbeiten, solange diese ihre Arbeit untereinander ohne Verlust von Qualität und Zeit koordiniert bekommen? Wenn die Verantwortlichen dem Team unterstellen, dass es im Sinne des Unternehmens denkt, dann können sie dem Team die Entscheidung über die Arbeitszeiten ruhig selber überlassen. Und das schließt auch die Entscheidungen darüber ein, wer wann in Urlaub gehen kann.

Als letztes wollen wir noch die Selbstorganisation der Kommunikation im Team betrachten. Ein selbstorganisierendes Team bestimmt selber darüber, wie es innerhalb des Teams kommuniziert. Damit ist zum Beispiel gemeint, dass das Team festlegt ob es Teammeetings braucht und falls ja wie oft und lang diese sein müssen. Oder wie mit Problemen im Team umgegangen wird, seien es technische oder zwischenmenschliche. Hat ein Teammitglied beispielsweise ein technisches oder fachliches Problem, dann kann es eine Teamvereinbarung sein, dass er formlos eine Quick Design Session einberufen kann Auf der könnte er die anderen Teammitglieder zum Rat oder ihre Meinung bitten. Und es gehört auch zur Teamvereinbarung, ob die Teilnahme an solchen Quick Design Sessions Pflicht ist oder eben nicht.

Wir haben jetzt eine ganze Reihe von möglichen Aspekten der Selbstorganisation eines Teams gesehen. Und allen gemeinsam ist, dass mit Ihnen nicht nur die Freiheit der Entscheidung einhergeht sondern auch die Übernahme von Verantwortung. Befragt man die Entscheider in Unternehmen, ob sie selbstorganisierende Teams einführen möchten, so bekommt man oft zögerliche oder sogar direkt ablehnende Antworten. Der zumeist unausgesprochene Grund dafür ist meist die Annahme, dass die Teams die Freiheit der Entscheidung zum Nachteil des Unternehmens ausnutzen würden. Die Motivation oder Kompetenz zugetraut im Sinn des Unternehmens zu agieren wird oft erst den Team- oder Projektleitern zugetraut.

Die Einführung selbstorganisierender Teams bedingt also den Paradigmenwechsel, dass alle Mitarbeiter des Unternehmens motiviert und befähigt sind, eigenverantwortlich im Sinne des Unternehmens zu agieren. Und dazu gehört auch, dass das Team selber die Verantwortung für die erfolgreiche Bewältigung der Aufgaben übernimmt. Und hier ist mit Team nicht irgendein abstraktes Gebilde gemeint, sondern jedes einzelne Teammitglied muss sich diese Verantwortung zu Eigen machen. Das kann bei Teams, in denen die einzelnen Mitglieder unterschiedliche Ansichten bezüglich der Übernahme von Verantwortung und damit dann auch dem Einsatz zum Erreichen der gemeinsamen Ziele haben, schnell zu interessanten Spannungen führen. Hier setzt ein gruppendynamischer Effekt ein, in dem sich rasch herauskristallisiert, wer „mitzieht“ und wer nicht. In den meisten Fällen wird das Team das intern regeln können und sollte dazu auch die Chance bekommen. „Regeln“ bedeutet dabei oft, dass sich in den gruppeninternen Diskussionen klärt, warum der eine oder andere nicht motiviert genug ist, den notwendigen Einsatz zu zeigen. Und es zeigt sich, ob durch Anpassung der internen Organisation nicht doch alle zufrieden gestellt werden können, oder eben auch nicht. Gruppenzwang ist dabei ein hässliches Wort und meistens auch ein bisschen überzogen. Aber manchmal wirkt er auch Wunder.

Und was mache ich, wenn ich doch einen unverbesserlichen Querschläger im Team habe, der durch seine Verweigerung den Erfolg des Teams und die Gemeinschaft an sich gefährdet? Was machen Sie denn in einem traditionellen Team mit so jemand? Wenn Sie ausreichend taff sind, dann entfernen Sie ihn aus dem Team, in den meisten Fällen wird er jedoch einfach als Ballast geduldet und mitgeschleppt. Ist das wirtschaftlich und hilft es dem Unternehmen? Steigert es die Motivation und Zufriedenheit der restlichen Mitarbeiter? Nein, definitiv nicht! In einem selbstorganisierenden Team wird es aufgrund der verstärkten Gruppeneffekte schwierig, so jemand zu dulden. Bleibt also nur, das Problem endgültig zu lösen. Klingt hart? Ist es auch, jedoch nur für den Verweigerer. Der Rest profitiert.
Nur damit wir uns richtig verstehen, dass ist nicht der Aufruf zu „wer nicht richtig funktioniert, der fliegt“. Die Selbstorganisation in Teams räumt allen Beteiligten wesentlich mehr Möglichkeiten ein, genau die Form des Einsatzes zu zeigen, die ihm jeweils am besten liegt. Und führt damit fast automatisch zu einer wesentlich höheren Motivation. Und auch individuelle Defizite wie fehlende Skills oder das jemanden bestimmte Tätigkeiten „einfach nicht richtig liegen“ können in einem solchen Team wesentlich besser aufgefangen werden. Das Team als Gemeinschaft findet selber raus, wie die individuellen Fähigkeiten jedes Einzelnen am besten genutzt werden können und wie das Team davon am besten profitiert. Und auch wie jeder sich im Team konstant verbessern und damit auch seinen eigenen Marktwert steigern kann. Und das sollte doch Anreiz genug sein. Noch sozialer geht es wohl kaum.

So, nachdem wir jetzt gesehen haben, welche Rechte zur Selbstbestimmung ein selbstorganisierendes Team haben sollte, welche Ansprüche darf umgekehrt der Projektleiter, Teamleiter, Produktmanager, Abteilungsleiter, etc. an das Team haben?
Nun als erstes Transparenz. Wir haben gerade noch davon gesprochen, dass für selbstorganisierende Teams Vertrauen durch die Verantwortlichen ins Team bzw. die Teammitglieder notwendig ist. Dieses Vertrauen ist wesentlich leichter aufzubringen und aufrechtzuerhalten, wenn für die Außenstehenden die Prozesse im Team und die Regeln, nach denen das Team agiert nachvollziehbar sind. Wenn ich als Vorgesetzter wissen möchte, wie das Team intern die Arbeit verteilt, dann ist die Antwort „Machen Sie sich keine Sorgen, wir regeln das schon irgendwie“ nicht besonders vertrauenerweckend. Am besten veröffentlicht das Team seine Regeln pro aktiv, z.B. in einem firmeninternen Wiki. Spätestens aber auf Anfrage sollten die aktuellen Regeln verständlich und vollständig kommuniziert werden.

Ein weiterer Punkt ist, wer die Aufgaben des Teams festlegt. Teams, und auch selbstorganisierende Teams, sind kein Selbstzweck, sondern haben ihre Daseinsberechtigung immer in den Aufgaben, die sie erfüllen sollen. Und die Aufgabe wird dort festgelegt, wo das Geld herkommt. In Köln sagen wir dazu: „Wer die Musik bestellt, der bestimmt auch was sie spielt“. Wenn sich die Aufgaben für das Team ändern oder weitere Aufgaben hinzukommen und das Team das Gefühl hat, für diese neuen Aufgaben eigentlich nicht richtig zu sein, dann kann es natürlich die Verantwortlichen darauf hinweisen. Ein grundsätzliches Verweigerungsrecht besteht aber zumindest in meinem Modell von Welt nicht. Das ist nicht anders, als bei traditioneller Teamorganisation.
Das wird besonders deutlich bei Projektteams, die während der Projektphasen laufend mit neuen Anforderungen konfrontiert werden. Die Auswahl, welche Anforderungen umzusetzen sind und in welcher Priorität, bestimmt der verantwortliche Projektleiter oder Produktverantwortliche. Das Team bestimmt dann darüber, wie die Umsetzung geschieht und wie lange es dauern wird.

Da wo es Sinn macht, gelten natürlich auch unternehmensweite Vorgaben bzgl. der Systemlandschaft, der Architektur, der zu verwendenden Tools und Dokumentations- und Qualitätsvorschriften. Die Betonung liegt jedoch tatsächlich auf „da wo es Sinn macht“. Prüfen Sie in Ihrem Unternehmen mal kritisch, welche der bestehenden Vorschriften tatsächlich unternehmensweit Sinn machen. Die zu verwendenden Tools aus Lizenzgründen einzuschränken kann Sinn machen. Auch die Systemlandschaft zentral reguliert übersichtlich zu halten macht Sinn. Einheitliche Qualitätsstandards finde ich sogar besonders gut. Wobei allerdings hier schnell die Frage aufkommen kann, wie sich dieses Qualitätsstandards einheitlich für ein größeres Unternehmen definieren lassen. Und zwar so, dass wirklich Qualität erzeugt wird und nicht nur unnötige Arbeit in den Teams. Und bei einheitlichen Dokumentationsrichtlinien fangen die meisten Unternehmen schon an mit Kanonen auf Spatzen zu schießen (meist durch wichtige Unternehmensberater dazu aufgestachelt). Und unternehmensweite Programmierrichtlinien sind fast immer mehr schädlich als nützlich. Ich verstehe die gute Absicht hinter all diesen Vorgaben. Aber das Gegenteil von Gut ist oft nicht Böse sondern gutgemeint.

Kommen wir mal zu einer anderen interessanten Frage: Braucht ein selbstorganisierendes Team eigentlich noch einen Teamleiter? Teamintern hat er ja eigentlich keine Aufgaben mehr: Er verteilt nicht die Arbeit, er muss den Urlaub nicht regeln, keine Zeitpläne oder Arbeitsergebnisse kontrollieren. Also unnötig, oder? Nun, nicht so ganz. Der Großteil der Unternehmen ist immer noch streng hierarchisch und meist recht unflexibel organisiert. Und in diesem Umfeld müssen sich dann auch die selbstorganisierenden Teams bewegen. Das bedeutet, dass sie klar definierte Ansprechpartner für die Welt außerhalb des Teams haben müssen. Der Teamleiter ist also kein Vorgesetzter mit Weisungsbefugnis mehr sondern eher ein Dienstleister, der als Schnittstelle und Koordinator für das Team fungiert.

Und wie verhält sich das mit der disziplinarischen Führung bei selbstorganisierenden Teams? Die disziplinarischen Führung beinhaltet in Unternehmen in der Regel die Entscheidungen darüber, wer in eine Organisationseinheit (z.B. das Team) kommt und wer nicht, bzw. diese Einheit verlassen muss, die Beurteilung von Mitarbeitern und das Gehalt derselben.
Bezüglich der Zusammensetzung des Teams, also Einstellung und Entlassung von Teammitgliedern, hatten wir schon gesehen, dass das Team hier ein Mitspracherecht haben sollte. Beim Gehalt gelten die gleichen Regeln wie sonst auch mit einer Ausnahme: Bei variablen Gehaltsanteilen die mit der Erreichung von individuellen Zielen gekoppelt sind, ist darauf zu achten, dass diese individuellen Ziele nicht im Widerspruch zu den aktuellen Teamregeln stehen oder die schon besprochenen Möglichkeiten des Teams zur Selbstorganisation einschränken. Wenn ein Teammitglied als individuelle Vorgabe die Spezialisierung auf ein bestimmtes Thema bekommen hat, das Team aber bei der Wissensverteilung auf Generalisten setzt, dann besteht hier ein Widerspruch der entweder die Teamvereinbarung gefährdet oder aber den variablen Gehaltsanteil des Mitarbeiters. Besser ist es die variablen Gehaltsanteile an Teamziele zu koppeln, Ziele die das Team als ganzen erreichen kann und deren Erreichen damit auch positive Effekte für alle Teammitglieder haben.

Zum Schluss die Königsfrage: Warum sollten Teams selbstorganisierend sein und macht das wirklich bei allen Teams Sinn?
Einen Teil der Vorteile von selbstorganisierenden Teams können wir schon den Argumentationen weiter oben entnehmen. Die stärkere Übernahme von Verantwortung durch das Team selber und die einzelnen Teammitglieder. Die damit verbundene bessere Motivation und die gruppendynamischen Effekte, die in der Regel zu höherer Effektivität führen. Die Selbstregulierungskräfte eines solchen Teams, das fast automatisch die Fähigkeiten der einzelnen Mitglieder optimal einsetzen und die Defizite ausgleichen wird.

In klassischen Teams mit zentraler Führung ist der Teamleiter schnell ein Flaschenhals, wenn es an ihm liegt die Arbeit im Team zu verteilen und zu kontrollieren. Selbstorganisierende Teams neigen dazu, auftretende Flaschenhälse schnell zu identifizieren und zu beseitigen. Dazu ist es übrigens von Vorteil in selbstorganisierenden Teams die agile Denkweise des „inspect and adapt“ zu verankern. In der klassischen Organisationslehre neigen wir dazu Regeln immer als für die Ewigkeit zu betrachten und den Umstand, dass Regeln geändert werden müssen als Versagen anzusehen. Deshalb ist das Erstellen von Regeln oft so komplizierter Akt, weil ja nicht falsch gemacht werden darf und führt so oft zu umfangreichen komplexen Regelwerken, die möglichst jede Eventualität berücksichtigen sollen. Nicht so in der agilen Denkweise. Einfache Regeln erstellen, die Regeln anwenden, beurteilen ob die Regeln zu den gewünschten Ergebnissen führen, wenn notwendig die Regeln anpassen, usw.
Durch dieses Vorgehen entsteht im Team automatisch ein kontinuierlicher Verbesserungsprozess, durch den das Team auch bei sich ändernden Rahmenbedingungen die maximale Leistungsfähigkeit behält.

Ein kleiner Nachteil der selbstorganisierenden Teams ist, dass sie in der Anlaufphase etwas langsamer sind. Wird so ein Team neu aufgebaut, dann muss die Gruppe erst mal anfangen einen ersten Wurf von Regeln zu definieren und auszutesten, welche Regeln die besten Ergebnisse erzielen. Und dass wird anfangs von vielen ausufernden Diskussionen im Team begleitet sein. Vor allem wenn sich die Teammitglieder vorher noch nicht kannten wird das einen recht intensiven Prozess des sich gegenseitig kennenlernen beinhalten. Und dann wird das Team nach und nach Fahrt aufnehmen. Das bedeutet aber im Gegenzug, dass die Selbstorganisation eher ungünstig für Teams mit hoher personeller Fluktuation ist oder zeitlich nur stark begrenzter Lebensdauer.

Um abschließend auf die erste Formulierung zurückzukommen: Ja, selbstorganisierende Teams sind Teams, die ihre Arbeit selber organisieren. Und eben auch noch mehr!

Kommentare

Ein Kommentar zu “Was sind selbstorganisierende Teams?”

  1. Von Selbstorganisierende Teams | Scrum-Karriere am Samstag, 27. November 2010 09:04

    […] Rechte hat so ein Team?” und auch “Welche Pflichten hat so ein Team?” in einem Blogartikel und einem Podcast (Folge 9 als MP3) beantwortet. Dieser Beitrag wurde unter Allgemein abgelegt […]

Einen Kommentar hinzufügen...

Sie müssen registriert und angemeldet sein um einen Kommentar zu schreiben.