TopMenue

04. Konsequente Demokratisierung des Teams

Dieser Beitrag befindet sich noch in Bearbeitung!

Scrum ist der Rahmen, Scrumcess der Prozess

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.

Die konsequente Demokratisierung der Projektstrukturen führt zu Gleichberechtigung auf Augenhöhe und ermöglicht, fördert und unterstützt wert- und verantwortungsvolles, effizientes Handeln aller Beteiligten

Keine disziplinarischen Hierarchien  ^

In Scrum-Projekten wird jedes disziplinarische Hierarchiegefälle vermieden. Die Stakeholder sind nicht die Chefs des Product-Owner, der Product-Owner ist nicht der Chef des Scrum-Masters und/oder des Entwicklungsteams, was auch der Scrum-Master nicht ist. Alle arbeiten im Sinne Scrums und zum Vorteil des Projektes pragmatisch und zielorientiert mit- und füreinander und suchen im Konfliktfall — wo immer möglich — den Konsens.

Die Strukturen in Scrum sind ausschließlich demokratischer Natur  ^

Alle Beteiligten begegnen sich ausschließlich auf gleicher Augenhöhe, sind gleichberechtigt und gleichermaßen dem Ziel und dem Erfolg des Projektes — der Schaffung des höchstmöglichen Geschäftswertes für den Kunden — verpflichtet. Sie handeln, arbeiten und kommunizieren effizient und in gegenseitigem Respekt, tiefem Vertrauen und großer Kooperationsbereitschaft. Niemand schreibt anderen vor, wie was zu tun oder zu unterlassen ist. Jeder wird darauf verpflichtet, seinen Aufgaben und Verpflichtungen bestmöglich und verantwortungsvoll nachzukommen.

Mut, Selbstbewusstsein und Ermächtigung  ^

Sämtliche Projektmitglieder arbeiten miteinander in dem Wissen, dass jede Rolle ihre spezifische Position mit einem angemessenen Maß an Professionalität, Pragmatismus, Achtung und Toleranz, aber auch mit Selbstvertrauen, Verantwortungsbewusstsein und der notwendigen Zielstrebigkeit und Entschlossenheit vertreten wird. Um diesen anspruchsvollen Rahmenbedingungen gerecht werden zu können, ist es für jede beteiligte Person von essenzieller Bedeutung, mutig, selbstbewusst und — ganz wichtig — auch dazu ermächtigt zu sein, im Rahmen der Absprachen zwischen den Beteiligten und unter Beachtung der Rahmenbedingungen des Projektes, für jede auftretende Aufgabenstellung den jeweils spezifisch optimalen Lösungsweg zu suchen, zu finden und diesen dann auch beschreiten zu dürfen.

Können sich z.B. die Entwickler nicht unabhängig von äußerer Einflussnahme dem Lösungsdesign widmen, sondern sehen sie sich gezwungen, von Seiten außerhalb des Entwicklungsteams, z.B. vom Product-Owner, offen oder subtil „durch die Blume“ an sie herangetragene Lösungsansätze verfolgen zu müssen, die unter Berücksichtigung technischer, fachlicher, organisatorischer, zeitlicher und / oder team-, bzw. entwicklungsspezifischer Gesichtspunkte nicht optimal durch sie umsetzbar sind, wird das nicht nur ihre innere Organisation und ihre Kreativität, sondern auch ihr Selbstverständnis, ihren Leistungswillen und ihre Innovationsfähigkeit beeinträchtigen, was fast zwangsläufig zu einer Verringerung der Produktivität führen wird. Insbesondere unter Berücksichtigung des zeitlichen Notstands, unter dem sich Projekte fast permanent befinden, ist es daher wichtig, dass die Entwickler vollständige Freiheit in der Wahl ihrer Mittel und Lösungen genießen.

Das bedeutet nicht, dass nicht auch eine ausserhalb des Entwicklungsteams stehendes Person, z.B. der Product-Owner, sofern er selbst über Kompetenzen im Bereich Softwareentwicklung verfügt, eigene Ideen beisteuern dürfe. Allerdings sollten sich in diesem Fall alle Beteiligten darüber klar sein oder darüber klar werden, dass es sich bei der Idee lediglich um einen weiteren, mit der notwendigen und angemessenem Enrsthaftigkeit zu behandelnden Beitrag handelt, der dann erörtert, diskutiert und angenommen oder verworfen werden kann — und nicht um eine bindende Anweisung oder Vorgabe; kompetenter Input ist immer willkommen!

Nicht tun, was man tun will, sondern tun, was getan werden muss  ^

Es geht dabei nicht darum, dass die Mitglieder des Teams machen können, was sie wollen, sondern darum, dass sie, um ihren Auftrag erfüllen zu können, in die Lage versetzt werden müssen, kreative und innovative Lösungen finden zu können, die unter Beachtung der spezifischen Rahmenbedingungen des jeweiligen Projektes und Teams die jeweiligen Optima abbilden. Dies ist eine Fähigkeit, auf die man sich im Team ersteinmal besinnen und einlassen muss, um sie für sich nutzen zu können, denn in Scrum-Projekten siegen oder verlieren immer alle gemeinsam, nie einer alleine.

Hierarchische Abhängigkeiten blockieren das Team  ^

Dies gilt nicht nur dann, wenn diese Abhängigkeiten offenbar sind und aktuelle Gültigkeit haben (z.B. in einem klassischen Softwarentwicklungsprojekt zwischen Entwicklungsteam und Projektleiter), wenn also z.B. im Scrum-Projekt der aktuelle und aktive Team- oder Abteilungsleiter gleichzeitig auch produktives Mitglied des Projektteams ist, sondern auch, wenn dieses Abhängigkeitsverhältnis

  • für die Zeit im Projekt offiziell aufgehoben wurde und erst nach Abschluss des Projektes wieder reaktiviert wird, oder
  • bis zum Projektbeginn bestanden hatte und nun beendet oder (zumindest zeitweise) ausgesetzt ist, oder
  • erst in der Zukunft nach Abschluss des Projektes etabliert wird.

All das hat zwangsläufig Einfluss auf das Verhältnis zueinander, sei es aktuell, sei es aus der Vergangenheit her oder sei es im Hinblick auf die Zukunft.

Ähnliches gilt, wenn sich im Team implizite, also unausgesprochene, nicht ausdrücklich installierte, sondern aus den Rahmenbedingungen erwachsene Hierarchien manifestieren, z.B. im Entwicklungsteam aufgrund der Dauer der Team-, Betriebs- oder Abteilungszugehörigkeit, die das Prinzip der „Begegnung auf Augenhöhe“ durchaus auf eine äußerst subtile Weise aushebeln können. Hier ist es die Aufgabe des Scrum-Coachs, bzw. des Scrum-Masters, diese subtilen oder offenen hierarchischen Gefälle im Zuge der Teamfindung je nach Ausprägung im Team zu Bewusstsein zu bringen, auszugleichen und zu glätten, um zu erreichen, dass aus einem zusammengewürfelten Trupp von Individualisten ein homogener, optimal im Sinne der Aufgabe funktionierender und hochproduktiver Organismus wird.

Es soll nicht dargestellt werden, dass derartige Konstellationen in der Praxis ständig aufträten und zum Scheitern von Scrum oder der jeweiligen Projekte führen müssen oder führen werden. Es soll auch nicht ausgedrückt werden, dass ein erfahrener Kollege einem (vielleicht auch nur in einem Spezialgebiet) weniger erfahrenen Kollegen etwas sagen dürfe. Wenn sich diese Situationen jedoch zu impliziten Hierarchien auswachsen — was tatsächlich immer wieder anzutreffen ist — beeinflussen sie die Produktivität oft negativ, z.B. wenn einige der Kollegen „nur“ noch auf Anweisung eines anderen Kollegen arbeiten und selbst gar keine eigenen Ideen oder Konzepte mehr beisteuern (können). Manchmal schaffen es die Teams dann intuitiv und ganz von allein, sich dieser Gefahren bewusst zu werden und sie auszugleichen oder zumindest auf eine förderliche Art zu handhaben, oft aber muss man als Scrum-Coach, bzw. Scrum-Master insbesondere bei neuen Teams zumindest unterstützend eingreifen.

Tut man das nicht, kann es zu einer wesentlichen Beeinträchtigung der Produktivität kommen, die dann tatsächlich den Erfolg der Einführung von Scrum oder den Erfolg des Projektes gefährden kann.

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.


[zurück zum Seitenanfang]


, ,

No comments yet.

Schreibe einen Kommentar

V1503130747DE