TopMenue

03. Uneingeschränkte Selbstorganisation des Teams

Dieser Beitrag befindet sich noch in Bearbeitung!

scrum.that.runs

Ein Teil dieser Seiten wurde ursprünglich für doktor-scrum.de geschrieben und ziehen nun hierher nach scrumcess.de um; leider sind sie aber inhaltlich noch nicht vollständig auf scrumcess.de umgearbeitet. Zudem ist es durchaus möglich, dass die enthaltenen Links noch ins Leere zeigen, bzw. noch auf doktor-scrum.de verweisen.
Ich bitte Sie, das zu entschuldigen.

Zur uneingeschränkten Selbstorganisation ermunterte Teams sind in ihrem Denken unabhängiger, schneller, kreativer und innovativer und erarbeiten aufgrund dieser Vorteile die besseren Lösungen und die Möglichkeit höchster Wertschöpfung für alle Beteiligten

Die klassische Organisation  ^

In einer klassischen, disziplinarisch-hierarchisch orientierten Organisation arbeiten die Mitglieder eines Teams auf Anweisung verantwortlich leitender Personen, z.B. dem Team- oder Projektleiter, an den sie jeweils auch den Fortschritt ihrer Aufgabe berichten, bzw. zu gegebener Zeit die Fertigstellung melden („command and control„). Sie werden in so einem Zusammenhang oftmals im Wesentlichen darauf reduziert, Produktionsfaktoren zu sein. Sie haben laufende Kosten (Lohn/Gehalt), sie gehen kaputt und brauchen Wartung (Krankheit/Arzt), sie haben Ausfallzeiten (Krankheit, Urlaub), usw., und so fort.

Zumindest in der Theorie arbeiten sie in einer solchen Organisationsform weder intuitiv, noch initiativ, sondern führen die ihnen jeweils zugewiesenen, mehr oder wenig klar definierten Aufgaben ausschließlich auf Anweisung aus; Planung, Verteilung und Nachverfolgung sind Aufgaben der leitenden Person. Sind für die Lösung einer Aufgabe mehrere Teammitglieder notwendig, führt die leitende Person die Zuordnung der Mitarbeiter zu der Gruppe, die die Aufgabe lösen soll, durch und weist ihnen die auszuführenden Teilaufgaben zu. Mit diesem Arbeitsmodell lassen sich die Leistungen als einzelner Mitarbeiter und auch als Teil einer Projektgruppe gut überprüfen, wobei jeder Mitarbeiter zumeist ausschließlich für sich, statt im Kontext eines / seines Teams, betrachtet wird.
Die o.g. Einschränkung „zumindest in der Theorie“ rührt daher, dass sich das beschriebene System auch implizit „umdrehen“ kann, wodurch der Mitarbeiter trotz gleicher Rahmenbedingungen auch ohne angemessene Ausstattung mit Befugnissen (und demzufolge zumeist auch ohne das notwendige Mandat) doch initiativ und kreativ Lösungen erarbeiten und die Verantwortung für seine Ergebnisse übernehmen soll, was aufgrund des fehlenden ausdrücklichen Mandats für den Mitarbeiter leicht zu einer Gratwanderung werden kann.

Das Prinzip von „Command and control“  ^

Das zentralistisch organisierte Prinzip „command and control„, dass man frei mit „Befehl und Gehorsam“ übersetzen könnte, engt die Handlungsfähigkeit der Teams und jedes einzelnen Mitarbeiters stark ein und führt zudem — Sprache ist nur selten exakt, sondern muss nahezu permanent inhaltlich einer Interpretation unterzogen werden — leicht zu Missverständnissen über die konkrete Art des gewünschten Lösungswegs. In der Praxis kann so ein Fall leicht zu weiteren Verzögerungen im Ablauf führen (Nachfragen, wiederholtes Abgleichen), da die Mitarbeiter in dieser Situation keinen eigenen, für sie spezifischen Lösungsansatz verfolgen, den sie aus ihrer eigenen Erfahrung und Kompetenz heraus intuitiv, schnell und sicher durchführen könnten. Stattdessen müssen sie sich zunächst in das Gedankenmodell des Auftraggebers und der von ihm präferierten Lösung hineinversetzen und einarbeiten und müssen diesen Vorgang zur eigenen Absicherung anschließend auch noch verifizieren.

Menschen schöpfen ihre Potenziale zudem meist erst als Teil einer Gruppe voll aus, denn eine Gruppe (hier das Team) irrt sich aufgrund der Pluralität der in ihr enthaltenen Meinungen, Fähigkeiten und Kompetenzen und des in ihr stattfindenden kommunikativen Austauschs weniger oft, als eine einzelne Person. Daher ist es für ein optimales Ergebnis nützlich und in vielerlei Hinsicht äußerst sinnvoll, die Mitarbeiter dahingehend zu unterstützen, situationsbezogen spontan autonome (Aktions-) Gruppen zu bilden, in denen sie ihre Aufgaben selbstorganisiert und gemeinsam die Gruppenintelligenz nutzend in der für sie spezifischen Herangehensweise intuitiv bearbeiten und zu einem gruppenspezifisch optimalen Ergebnis führen können.

Hierarchische Strukturen vermeiden, Selbstorganisation fördern und unterstützen  ^

Die Demokratisierung von Prozess und Team, sowie die umfassende Ermächtigung durch das Management, sind die Voraussetzungen für die selbstorganisierenden Entwicklungsteams in Scrum. Hierarchische Strukturen werden konsequent und ausdrücklich vermieden, die Mitglieder der Entwicklungsteams arbeiten miteinander, selbstbestimmt und gleichberechtigt auf Augenhöhe; jeder Mitarbeiter ist sein eigener Manager im Kontext seines Teams. Dies geschieht auf Basis vollständiger Verantwortungsübernahme durch das jeweilige Team und jedes einzelne Mitglied. Das Ziel dabei ist, den Overhead, der sich aus einer zentralen, permanent und für nahezu jede Entscheidung immer wieder aufs Neue zu konsultierenden Verwaltungsinstanz fast zwangsläufig ergibt, zu vermeiden.

Das Pull-Prinzip  ^

Entwicklungsteams in Scrum arbeiten nach dem Pull-Prinzip. Sie warten nicht, bis ihnen Arbeit zugewiesen wird (Push-Prinzip), sondern sie holen sich initiativ aus dem von ihnen selbst verwalteten Pool — in diesem Fall dem Sprint-Backlog, das, wie alle anderen Backlogs auch, absteigend nach der eindeutig vergebenen Priorität sortiert ist — das jeweils in der Reihenfolge als nächstes zu realisierende, noch nicht in Arbeit befindliche Arbeitspaket höchster Priorität. Auf diese Weise sind steter Nachschub höchstpriorisierter Aufgaben und kontinuierliche Produktivität auf hohem Niveau gewährleistet.

Was ist denn „Selbstorganisation“?  ^

Die Selbstorganisation eines Teams besteht aus der Summe aller Entschlüsse, Absprachen und Handlungen, die intern von und zwischen den Teammitgliedern getroffen oder durchgeführt werden, die dem inneren Aufbau des Teams und der Strukturierung, Koordination und Vernetzung ihrer Aktivitäten im Hinblick auf die Durchführung der Aufgaben, die sie als Team haben oder erhalten werden, dienen.

Die Selbstorganisation des Entwicklungsteams

  • ist die teaminterne, eigenverantwortliche Steuerung sämtlicher projektrelevanter Belange des Teams durch die Teammitglieder im Hinblick auf das vereinbarte Etappen- / Projektziel,
  • macht aus einem zusammengewürfelten Trupp von Softwareentwicklern ein Team, das die Aufgaben, die es erhält, optimal, also schnell, sicher, zielorientiert und in hoher Qualität, durchführen kann,
  • ist ein entscheidendes Konzept in Scrum und daher für den Erfolg von Scrum und die mit Scrum durchgeführten Projekte von grundlegender Bedeutung,
  • sollte oder muss dem Team je nach Status des Teams (neues / bereits eingespieltes Team) durch den Scrum-Coach, bzw. durch den Scrum-Master nahegebracht und eingeführt werden,
  • muss vom Management durch die öffentliche Erklärung der „umfassenden Ermächtigung des Entwicklungsteams einmalig zu Beginn eines Projektes offiziell erklärt und zweifelsfrei mitgetragen werden.
Ein optimales Team handelt als homogene Einheit  ^

Von außen betrachtet, stellt sich ein optimales Team als ein homogener, einheitlicher Organismus dar, dem man seine innere Struktur nicht ansieht. Es sollte immer mit einer Stimme sprechen, unabhängig davon, mit welchem Teammitglied man spricht. Um das zu erreichen, muss sich das Team intern so aufstellen und abstimmen, dass jedes Mitglied, unabhängig von seiner Stellung und Funktion innerhalb des Teams, genau über die innere Struktur seines Teams, die inneren und äußeren Aktivitäten, die Ziele und die geplanten Abläufe und Lösungswege informiert ist, sodass es das Team jederzeit nach außen hin repräsentieren kann.

Repräsentieren bedeutet an dieser Stelle nicht, das jedes Teammitglied jederzeit spontan vielleicht weitreichende Entscheidungen im Namen des gesamten Teams treffen sollte, sondern, dass es den Entscheidungsbedarf zunächst aufnimmt, um ihn vor der (gemeinsamen) Entscheidung innerhalb des Teams besprechen und diskutieren zu können! Ist dies in dem Moment nicht nötig oder nicht möglich und muss die Entscheidung (die in so einem Fall mit hoher Wahrscheinlichkeit lediglich vorläufig sein wird) sofort gefällt werden, müssen die restlichen Mitglieder des Teams natürlich so bald als möglich über den Vorgang informiert werden. Da alle Entwickler in Scrum in räumlicher Nähe zueinander arbeiten sollten, um ihren kommunikativen Overhead so klein wie möglich halten zu können und nicht immer alle Teammitglieder für eine Entscheidungsfindung notwendigerweise anwesend sein müssen, sollte sich der zeitliche Aufwand dieser Besprechungen in akzeptablen Grenzen bewegen, sodass eine endgültige Entscheidung des Teams zeitnah zur Verfügung stehen können sollte.

Kurze Entscheidungswege  ^

Ermächtige, kompetente und selbstorganisierende Teams handeln verantwortungsbewusster und verkürzen damit die Entscheidungswege in ihrem jeweiligen Kompetenzbereich ganz entscheidend, weil sie direkt im Thema sind und spontan über einen Sachverhalt reflektieren und entscheiden können. Sie müssen nicht erst auf eine dritte Instanz zugehen und zuvor vielleicht noch ein Dokument als Entscheidungsgrundlage erstellen, um dann evtl. doch noch auf eine Entscheidung warten zu müssen. Wie bereits gesagt, ein gut funktionierendes Team irrt sich aufgrund der ihr innewohnenden Gruppenintelligenz weniger oft als eine einzelne Person und fällt damit — zumindest was den ureigenen Kompetenzbereich des Teams betrifft — höchstwahrscheinlich die besseren Entscheidungen.

Alle profitieren, hauptsächlich aber das Entwicklungsteam  ^

Selbstorganisierende Teams sind schneller, flexibler und i.A. deutlich kreativer als zentral gesteuerte Teams. Sie handeln spontan und intuitiv und nehmen aufgrund ihrer weitaus größeren Spielräume und Flexibilität ohne wesentlichen Zeitverlust die jeweilig zur Lösung der Aufgabe optimale Struktur an. Ein Teil der durchzuführenden Teilaufgaben könnte z.B. jeweils von einzelnen Teammitgliedern gelöst werden, ein anderer Teil lässt sich vielleicht besser von einer sich spontan zusammenfindenden Teilgruppe lösen, die dann vielleicht kurzzeitig wieder in einzelne Mitglieder zerfällt, um Teilergebnisse zu produzieren, die dann kurz danach von der Teilgruppe wieder zu einer komplexen Lösung zusammengefügt werden kann. Auf diese Weise wird die Produktivität gesteigert, da die innere Koordination der Teams spontan, effizient und situationsoptimiert greifen kann und evtl. auftretende Leerlaufzeiten auf diese Weise effektiv und proaktiv vermieden werden.

Das Entwicklungsteam ist der zentrale und erfolgskritische Produktionsfaktor  ^

Die Sicht auf das Entwicklungsteam ist die Sicht auf einen geschlossenen, autarken, homogenen, unteilbaren und ausschließlich sich selbst organisierenden (und ggf. auch disziplinierenden) Organismus, der nicht nur EINEN, sondern DEN erfolgskritischen Produktionsfaktor innerhalb Projektes darstellt. Aus diesem Grund darf weder das gesamte Scrum-Team, noch das Entwicklungsteam — zumindest dann, wenn man das Projektziel nicht gefährden will — für Ränkespielchen im jeweiligen Kontext der Projekte, Abteilungen und Unternehmen und deren Verantwortlichen, oder als unternehmenspolitische Manövriermasse zur Verfügung stehen, sondern muss stattdessen im Hinblick auf das erfolgreiche Erreichen des Projektzieles umfassend von allen Beteiligten unterstützt und beschützt werden.

11 Freunde sollt ihr sein?  ^

Da es gerade in der professionellen Softwareentwicklung intensiv ums Geschäft geht, reicht eine Beschwörung der „11-Freunde“-, bzw. „Mantel & Degen“-Romantik allein nicht aus, um aus ideal 7 +/- 2 Entwicklern ein Team im Sinne Scrums zu machen, obwohl der Geist, der durch „einer für alle, alle für einen“ ausgedrückt wird, einen durchaus angemessenen Aspekt darstellt. Die Erfahrung zeigt, dass es nicht nur nicht schadet, wenn das Entwicklungsteam einen starken inneren Zusammenhalt hat, sondern sich Zusammenarbeit, Kommunikation und Interaktion stark verbessern und auch die Leistungsbereitschaft des Teams und damit einhergehend die Produktivität mit steigender sozialer Kooperation umso mehr ansteigt, je besser, effizienter und reibungsfreier die Teammitglieder miteinander interagieren, kommunizieren und Verständnis für einander entwickeln.

Der Teambildung kommt in Scrum daher eine besondere Aufmerksamkeit zu, wird von Scrum selbst jedoch nicht genauer geregelt, da es sehr auf die beteiligten Personen, Scrum-Coach, Scrum-Master, Entwickler und auch das Management und die jeweiligen Charaktere, Fähigkeiten und Schwerpunkte, sowie auf ihren aktuellen Team-Status (neues oder bereits eingespieltes Team) ankommt. Aus diesem Grund ist es die Aufgabe des Scrum-Coaches, bzw. des Scrum-Masters, das Team in seiner Findung zu begleiten, zu führen, anzuleiten und zu unterstützen.

Das Entwicklungsteam ist der Motor des Projektes, denn nur sie produzieren die notwendigen Wertschöpfungsprodukte des Projektes. Wie jeder andere Motor auch, braucht es — insbesondere dann, wenn es sich um ein neues oder von der Struktur her inhomogenes Team handelt — eine teamspezifisch unterschiedliche Zeitspanne und den nötigen Freiraum, um auf Touren zu kommen, sprich, um sich im Inneren optimal aufzustellen und die spezifische und optimale Produktionsgeschwindigkeit des Teams zu finden und zu erreichen.

Teambildung ist eine schützenswerte Investition  ^

Hat das Team einen Status erreicht, in dem es stabile, vorhersag- und damit planbare Ergebnisse im Hinblick auf Produktivität, Qualität und Performance erreicht, sollte die Zusammensetzung des Teams nur noch in Ausnahmefällen geändert werden („never change a running team“), denn jede Veränderung, z.B. durch eine Umbildung oder dass jemand Neues dazukommt oder jemand das Team verlässt, wird zu einer zumindest teilweisen Wiederholung des Teambildungsprozesses führen und die Produktivität (und damit auch Qualität und Performance) — zumindest eine Zeit lang — negativ beeinflussen.

Während des Projektes ist es von essenzieller Bedeutung, dass alle Beteiligten dem gesamten Team vertrauen, es schützen, es sich weiterentwickeln und es seine Arbeit ungeachtet äußerer Umstände in Ruhe und ungestört ausführen lassen. Der Projektfortschritt ist jederzeit anhand der jeweiligen Burndown-Charts (Sprint-Burndown-Chart, Release-Burndown-Chart) ersichtlich und wird drüber hinaus jeweils am Ende einer jeden Iteration anhand der im Sprint-Review präsentierten Ergebnisse und des auslieferbaren Produktinkrements deutlich. Zudem sollten sich alle Beteiligten bewusst machen, dass Fehler häufig nicht Versagen darstellen, sondern vielfach eher Hinweise auf Chancen sind.

Wertschätzung gegenüber dem Team  ^

Indem das Management dem Entwicklungsteam die Ermächtigung ausspricht, es schützt und in seiner Selbstorganisation unterstützt, drückt es Wertschätzung und Vertrauen aus, was sich gleichermaßen positiv auf Motivation und Arbeitsmoral, sowie auf Leistungsbereitschaft und -willen des gesamten Teams und damit außerordentlich positiv auf Produktivität, Projekt-Performance und am Ende auch auf das zu realisierende Produkt auswirkt.

Prinzipien und Werte bilden ein System  ^

Jedes Prinzip und jeder Wert ist der Kopf einer eigenen Beeinflussungskaskade anderer Prinzipien und Werte, denn jede Wertänderung wirkt sich auf weitere Prinzipien und Werte, die auf ihnen aufbauen, aus. An vielen Stellen stehen die Prinipien und Werte sogar in direkter Wechselwirkung zueinander.

Aus diesem Grund müsste jede Wertänderung eines beliebigen Prinzips oder Wertes durch die Kaskadierung Wertänderungen aller anderen Prinzipen und Werte nach sich ziehen, so dass dieses System -- einmal angestoßen -- im Grunde nie wieder zur Ruhe kommen dürfte. Das ist in der Praxis jedoch nicht der Fall, da es sich bei den Abhängigkeiten und Wechselwirkungen um ein soziales, gedämpftes System handelt, dessen innere Wirkung sich von Ebene zu Ebene abschwächt.

Aus diesem Grund werden hier als Quellen und Ziele der wertändernden Beeinflussungen nur die jeweils direkten Addressaten angegeben und nicht diejenigen, die in einer tieferen Ebenen der jeweiligen Kaskade betroffen sind.

Sowohl die Definitionen der Prinzipien und der Werte und ihre jeweiligen Zusammenhänge, Beeinflussungen, bzw. Verknüpfungen oder Nicht-Verknüpfungen, können nicht den Anspruch von Vollständigkeit und Korrektheit erheben, da es sich um eine weitestgehend subjektive Sicht handelt. Man kann daher aus diesen oder jenen Gründen durchaus anderer Meinung sein (zumal die Auswahl und die Beziehungen zueinander aktuell auch noch nicht vollständig von mir kommentiert sind). Sollten Sie also anderer Meinung sein als ich, würde ich mich über einen diesbezüglichen Kommentar sehr freuen; recht vielen Dank!

Was aktuell noch vollständig fehlt, sind Darstellung und Beschreibung der Beeinflussung der Werte untereinander; dieser Teil befindet noch in der Analyse.

’03. Uneingeschränkte Selbstorganisation‘ beeinflusst

Prinzipien
  • 02. Umfassende Ermächtigung des Entwicklungsteams
  • 04. Konsequente Demokratisierung

    Uneingeschränkte Selbstorganisation, konsequente Demokratisierung und umfassenden Ermächtigung sind drei Prinzipien, die aufeinander aufbauen und in einer steten Wechselwirkung zueinander stehen. Auf der einen Seite ist die umfassenden Ermächtigung Basis und Voraussetzung für die uneingeschränkte Selbstorganisation und die konsequente Demokratisierung, auf der anderen Seite bestimmt das Maß, in dem die beiden Prinzipien uneingeschränkte Selbstorganisation und konsequente Demokratisierung vom Team umgesetzt und in der täglichen Praxis eingesetzt werden, inwieweit die umfassenden Ermächtigung angenommen und zum Vorteil des Projektes eingesetzt wird.

Werte


[zurück zum Seitenanfang]


, ,

No comments yet.

Schreibe einen Kommentar

V1503130747DE