TopMenue

11. Höchstmögliche Konzentration des Teams

Dieser Beitrag befindet sich noch in Bearbeitung!

Ungestört und hochkonzentriert arbeiten zu können, ist eine der wichtigsten Anforderungen für eine effiziente Arbeitswelt, denn konzentrierte Teams sind produktiver, schneller und verlässlicher in ihren Leistungen und in der Qualität ihrer Ergebnisse

Unterstützer der Entwickler  ^

Um dem Entwicklungsteam die vollständige Konzentration auf ihre Aufgaben zu ermöglichen, ist es Teil der Zuständigkeiten des Scrum-Masters, alle störenden, die Produktivität des Entwicklungsteams beeinträchtigenden Einflüsse zu beheben, bzw., von ihnen fernzuhalten. Er sammelt diese Hindernisse im Impediment-Backlog, arbeitet sie ab, indem er sie z.B. in Zusammenarbeit mit dem Product-Owner oder dem Management beseitigt und berichtet dem Entwicklungsteam im Daily-Scrum darüber.

Scrum schafft Transparenz  ^

Scrum sieht die eigene Aufgabe ausdrücklich nicht darin, die Entwickler in einem schlauchartigen Wege-Labyrinth auf engen Bahnen und ohne eigene Bewegungsmöglichkeiten in Richtung des Projektzieles zu führen. Statt dessen baut Scrum, um einmal bei diesem Beispiel zu bleiben, in diesem, die tägliche Arbeit des Softwareentwicklers darstellenden Labyrinth, (virtuelle) Übersichtsplattformen auf, mit denen die Entwickler sich schnell einen Überblick über das Chaos — Verzeihung, das Labyrinth — verschaffen können, um möglichst schnell und effizient an das Ende des Parcours zu gelangen, z.B. mit Daily-Scrum, Taskboard, Sprint-Burndown-Chart und Release-Burndown-Chart oder dem Refinement-Meeting.

Konzentration der Entwickler auf ein Projekt  ^

Für ein optimales Ergebnis (und nicht weniger wird i.A. zumindest von einem Scrum-Team erwartet) gehört auch die kontinuierliche Arbeit an einer Aufgabe; arbeiten z.B. die Entwickler jedoch real betrachtet entweder explizit (Teilzeit in mehreren Projekten) oder implizit (sie arbeiten zwar Vollzeit im Projekt, müssen aber immer wieder zeitweise Aufgaben außerhalb des Projektes wahrnehmen oder werden immer wieder anderweitig abgelenkt) nur in Teilzeit für das Projekt, kann und wird sich der durch Scrum zu erwartende Erfolg nur schwer einstellen. Das ergibt sich schon allein daraus, dass die sich zwangsläufig einstellenden Umschalt-, bzw. Umrüstzeiten (im Kopf, auf dem Schreibtisch, in den Unterlagen, etc.) und die daraus erwachsenden Konsequenzen sowohl einzeln, als auch in der Summe an Konzentration und Produktivität der Entwickler nagen; je häufiger sie auftreten, umso mehr.

Aus diesem Grund sollten die Teammitglieder, insbesondere die Entwickler, soweit irgend möglich, immer in die gesamte, ihnen zur Verfügung stehende Arbeitszeit konzentriert in dem einen Projekt arbeiten und nicht gleichzeitig in mehreren.

Konzentration der Entwickler auf ihre Aufgaben  ^

Scrum bezieht seine Kraft aus der Konzentration der Teammitglieder auf ihre jeweiligen Aufgaben, aus ihrer permanenten, wertvollen und einander bereichernden Zusammenarbeit, sowie aus einer effizienten Kommunikations- und persönlichen Weiterentwicklungskultur; also aus einem optimalen, sich stetig weiterentwickelnden Teamwork. Störungen ihrer Konzentration wirken sich direkt auf ihre Produktivität und damit auf die Performance des Projektes aus.

Optimale Zusammenarbeit ist essenziell  ^

Eine optimale Zusammenarbeit im Team ist das A und O für eine höchstmögliche Produktivität und damit eine der wesentlichen Zielsetzungen von Scrum. Nur wenn alle Seiten gleichermaßen und gemeinsam konzentriert auf das gemeinsame Ziel hinarbeiten und am gleichen Strang ziehen, um in kürzester Zeit die bestmögliche Lösung zu erarbeiten, kann im Projekt ein Produkt höchstmöglichen Wertschöpfungspotenzials erarbeitet werden.

Gewollte / ungewollte Konkurrenz im Team ist kontraproduktiv  ^

Konkurrenz innerhalb eines Teams konterkariert diese Zielsetzung, da nun plötzlich das „besser als die Kollegen sein“ in den Vordergrund rückt und damit die Konzentration auf die bestmögliche Lösung eines Problems aus dem Fokus drängt. Die Arbeit wird nicht mehr koordiniert in Zuge der selbstorganisierten Zusammenarbeit des Teams stattfinden, sondern (zumindest tendenziell) unkoordiniert und gegebenenfalls sogar mehrfach, da Mitglieder des Teams nunmehr potentiell parallel an den gleichen Aufgaben / Lösungen arbeiten, um jeweils eine bessere Lösung schneller als die Kollegen zu entwickeln. Spätestens jetzt verändert sich das Projekt zu einem Marktplatz, auf dem die Teammitglieder als Marktteilnehmer nicht mehr gemeinsam koordiniert auf das gemeinsame Ziel hinarbeiten, sondern sich statt dessen vielmehr gegeneinander abgrenzen, um sich und die eigene Leistung(en) vorteilhaft zu präsentieren.

Das mag in manchen Teams so gewollt sein, immerhin kann eine ausgeprägte Konkurrenzsituation bei Einzelnen sicherlich zu persönlichen Höchstleistungen führen, kommt dem Wunsch einer Stabilisierung der Produktivität auf dem teamspezifisch höchstmöglichen Niveau über einen längeren Zeitraum jedoch nicht entgegen. Die Existenz teaminternen oder teamübergreifenden Wettbewerbs ist — wenn auch häufig als gängige Managementstrategie eingesetzt — zumindest dann, wenn man auf die optimale Durchführung eines Projektes in „scope & time“ Wert legt (der Auftraggeber wird das ganz sicher tun), nicht nur suboptimal, sondern für den Erfolg des Projektes sogar hinderlich, da die Mitglieder des Teams in dieser Situation nicht mehr mit-, sondern gegeneinander arbeiten. Die Kräfte des Teams werden — anders, als mit dem Einsatz von Scrum beabsichtigt — nicht mehr gemeinsam auf die team- und situationsspezifisch bestmögliche Lösung konzentriert, sondern diversifiziert. Teamwork findet dann kaum mehr statt, Synergie– und Emergenz-Effekte bleiben aus, die Produktivität sinkt, was so ziemlich das Gegenteil von dem ist, was Scrum zu erreichen gewillt und auch im Stande ist.

Nur die kontinuierliche Performance des Teams zählt  ^

Scrum setzt gerade nicht auf die durch Stress hervorgebrachten, Team und Team-Mitglieder verschleißenden, persönlichen Höchstleistungen einzelner, sondern darauf, dass das Team in möglichst optimaler Kooperation und möglichst perfekter Zusammenarbeit und Symbiose miteinander konzentriert und entspannt beste Werte für Leistung und Geschwindigkeit erreicht. Das Team sollte dabei in der Lage sein, diese teamspezifisch optimale (optimale, nicht höchstmögliche!) Performance nahezu unbegrenzt aufrecht erhalten zu können, obwohl sie vielleicht oder vielmehr wahrscheinlich das Maß der Summen persönlicher Höchstleistungen einzelner — die nur selten über einen längeren Zeitraum wirklich stabil aufrecht zu erhalten sind — überschreitet.

Das bedeutet nicht, dass individuelle Höchstleistungen nicht anerkennenswert oder nicht wertvoll wären, sie sollen nur das System weder beherrschen, noch kennzeichnen oder bestimmen, da sie es in diesem Fall gleichzeitig erodieren würden. Das Credo von Scrum ist liegt nicht in der Diversifizierung von Kräften und Lösungen, sondern in der Bündelung und Konzentration aller vorhandener Kräfte auf die gemeinschaftliche Lösung der jeweiligen Aufgabe.

Der Scrum-Master ist der Hüter und Beschützer des Entwicklungsteams  ^

Treten immer wieder Situationen auf, in denen das gesamte Entwicklungsteam oder einzelne Mitglieder in der Erfüllung ihrer Aufgaben gestört werden, ist der Scrum-Master eine geeignete Adresse, um diese Probleme anzusprechen und beheben zu lassen. Er ist der Hüter der Produktivität des Teams und hat schon allein von daher ein vitales Interesse daran, dass das Entwicklungsteam effizient und konzentriert arbeiten kann. Dies trifft auch dann zu, wenn sich der Product-Owner als mögliche Quelle der Probleme oder als möglicher Retter in der Not herausstellen sollte.



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

V1710260636DE