Management

Dieser Beitrag befindet sich noch in Bearbeitung!

Scrum ist der Rahmen, Scrumcess der Prozess

Das Management als „business enabler“

Das Management ist in Scrum zwar keine ausdrückliche, im Hinblick auf das Projektziel produktive Rolle, es ist jedoch die Gruppe, die ein Projekt ermöglicht und vorantreibt. Gleichzeitig ist es ein Verbindungsglied zwischen dem Projektteam und der Administration des Unternehmens. Wie auch immer „das Management im Unternehmen definiert ist, gehören aus Sicht von Scrum auch alle „oberhalb“ der designierten Teammitgliedern angesiedelten Mitarbeiter, also auch Abteilungs- und Teamleiter, etc. dazu.

Das in dieser Art von Scum definierte Management hat die Aufgabe, die bestmöglichen Rahmenbedingungen für eine erfolgreiche Durchführung der Projekte zur Verfügung stehen, indem es Räumlichkeiten, Arbeitsmittel, Technik, etc., zur Verfügung stellt. Darüber hinaus stellt es auch das Team zusammen und sollte dabei auch Bedürfnisse, Vorschläge und Anregungen der Beteiligten nicht außer Acht lassen, z.B. wenn es bereits gut eingespielte Entwicklungsteams gibt, bzw. Teams aus Entwicklern und Product-Owner, bzw. Scrum-Master.

Im Projektverlauf ist das Management die Instanz, die konsultiert wird, wenn es innerhalb des Projektteams zu schwerwiegenden Problemen kommt, die sich mit den Möglichkeiten des Teams allein nicht lösen lassen. Das Management ist häufig der Ansprechpartner des Scrum-Masters, wenn er die Impediments, die er in seinem Impediment-Backlog sammelt, also Behinderungen, die Produktivität des Teams einschränkenden, bearbeitet und auflöst.

Das Management hat wesentlichen Anteil am Aufbau der für den Erfolg von Projekt, Team und Scrum sehr wichtigen optimalen Produktionssituation für das Team — insbesondere für das Entwicklungsteam — indem es ihm formell zu Beginn des Projektes ausdrücklich die umfassende Ermächtigung ausspricht, alles Notwendige tun zu können und zu dürfen, um das Projekt zu einem erfolgreichen Ende zu führen.

Schaffung von Gestaltungsräumen

Diese Punkte sind von großer Bedeutung, da erst sie dem Team — und hier wiederrum insbesondere dem Entwicklungsteam — die für sie und ihre Arbeit außerordentlich wichtigen Frei- und Gestaltungsräume verschaffen und sie in die Lage versetzen, bestmögliche Leistungen zu erbringen. Darüber hinaus ist Scrum nicht nur ein Managementrahmen für Softwareentwicklungsprojekte, sondern gleichzeitig auch ein auf Prozess, Projekt und Produkt ausgerichtetes Qualitätsmanagementsystem. Ohne diese Rahmenbedingen sind die beteiligten Personen kaum in der Lage, bestmögliche Arbeitsergebnisse in höchstmöglicher Qualität herzustellen, ohne die es für sie sehr schwer wird, das Produkt höchstmöglichen Wertschöpfungspotenzials für den Auftraggeber herzustellen.

Der Verantwortungskonflikt

Insbesondere das Management in klassisch geprägten, zentralistisch, hierarchisch orientierten Unternehmen tut sich jedoch oft mit Scrum schwer, da mit dem Einsatz von Scrum wesentliche Teile der Verantwortung — und damit einhergehend auch die Möglichkeiten der Einflussnahme — vom Management auf das Projektteam, insbesondere das Entwicklungsteam, übergehen. In vielen Unternehmen, in denen Scrum erstmalig eingeführt wird, ist zunächst lediglich die Softwareentwicklung von der Agilisierung „betroffen“, die anderen Teile des Unternehmens verbleiben in ihrer traditionellen Form, die zumeist nicht-agil ist. Das jeweilige Management fungiert als Schnittstelle zwischen „oben“ und „unten“ und behält weiterhin die Verantwortlichkeit für die durchzuführenden Projekte, die sie jedoch per Definition an das Projektteam abgegeben hat und sieht sich daher dem Konflikt ausgesetzt, zwar auf der einen Seite die Verantwortung zu tragen, aber auf der anderen Seite — zumindest gefühlt — das Heft des Handelns aus der Hand geben zu müssen, was immer wieder zu starken Vorbehalten gegenüber der Einführung von Scrum, Ressentiments und hohen Beharrungskräften führt.

Es soll hier nicht kolportiert werden, dass das Management per se subtil oder ganz offen als Bremsklotz oder Blockierer von Scrum agieren würde, jedoch stellt die Herangehensweise von Scrum die Sicht vieler Manager auf ihre Aufgaben, Kompetenzen, Handlungsweisen und eingesetzten Management-Methoden auf den Kopf, was zunächst zwangsläufig zu Irritationen und Widerständen führt. Häufig werden diese Sorgen auf einer sehr sachlichen Ebene artikuliert, wo man als Coach im Gespräch sehr viel erreichen kann, manchmal werden die mit der Einführung von Scrum einhergehenden Veränderungen — das betrifft nicht nur Manager, sondern auch andere Beteiligte — auch wie eine existenzielle Bedrohungen wahrgenommen, was den Einführungsprozess stark erschweren und die Erfolgschancen verringern kann.

Die Einflussmöglichkeiten verändern sich

Um es klar auszudrücken: anders, als häufig vom Management befürchtet, muss es beim Einsatz agiler Methoden nicht seine Einflussmöglichkeiten fürchten. Tatsache ist jedoch, dass die Einflussmöglichkeiten sich verändern und das Management, bzw. alle Beteiligten diesen Veränderungsprozess mitgehen müssen.

Das Mikromanagement wird lokal durchgeführt

Einer dieser Punkte ist der Wegfall des Mikromanagements, das „wer macht genau jetzt was, wie und wie lange und in welcher Form und Reihenfolge„. Das Mikromanagement wird unter Einsatz von Scrum von jedem Teammitglied eigenständig im Kontext seines Teams und der zu bearbeitenden Aufgaben situationsbezogen durchgeführt. Die Teammitglieder werden damit zu ihren eigenen Mikromanagern, was die Entscheidungswege und -aufwände, sowie die Laufzeiten entscheidend verkürzt und der Effizienz und der Produktivität in hohem Maß zugutekommt.

Ein „running team“ nicht verändern

Ein weiterer, für das Management problematischer Punkt ist die gefühlte Beschränkung der Freizügigkeit des Einsatzes der Mitarbeiter, das „die Mitarbeiter jederzeit so einsetzen, wie es die aktuelle Situation des Unternehmen gerade verlangt„, was in Scrum aus Gründen der Effizienz nicht mehr vorbehaltlos und jederzeit durchgeführt werden sollte.

Scrum schöpft seine Vorteile und Kraft aus den vorhandenen Optimierungspotenzialen aller relevanten Bereiche, indem es den gesamten Produktionsvorgang, sowie seine Rahmen- und Umfeldbedingungen soweit wie möglich von den vorhandenen Insuffizienzen zu befreien versucht. Dabei betrachtet Scrum das Team — insbesondere das Entwicklungsteam als Motor des Projektes — stets als homogenen, atomaren Körper, der seine Kräfte und Fähigkeiten im Inneren bündelt und einsetzt und nach außen als Einheit kommuniziert und agiert. Diese operative und produktive Einheit darf daher in ihrer Beschaffenheit — Umfang, Struktur und Zusammenstellung — nur in außergewöhnlichen und unausweichlichen Notfallsituationen und unter Wahrnehmung und Berücksichtigung aller sich ergebender Konsequenzen für Prozess, Projekt und Team, verändert werden! Änderungen an einem produktiven Team können tief und störend in den Projektverlauf eingreifen und das Bemühen um größtmögliche Optimierung schnell und umfassend stören und sollten daher ausschließlich im Konsens aller Betroffenen durchgeführt werden.

Die Freizügigkeit des Einsatzes der Mitarbeiter wird von Scrum also nicht ausgeschlossen, sondern lediglich unter den Vorbehalt gestellt, eine Veränderung des Teams innerhalb eines laufenden Projekts, bzw. eines laufenden Sprints nur in Absprache mit dem Scrum-Team und unter Berücksichtigung aller Risiken (z.B. Verringerung der Produktivität) und Konsequenzen (z.B., dass das Commitment nicht aufrecht gehalten werden kann) durchzuführen!

Agilität bedeutet nicht, jederzeit und überall beliebige Veränderungen durchführen zu müssen, sondern gibt lediglich dem Team die Mittel an die Hand, notwendige Veränderungen jederzeit im Projektfluss handhaben und berücksichtigen zu können, denn das Ziel eines Projektes ist nicht die Veränderung als Selbstzweck, sondern die Schaffung eines Produktes höchstmöglichen Wertschöpfungspotenzials für den Auftraggeber!

Scrum-but„: Den Prozess beugen, bevor man ihn kennt?

Ausgehend von einem Management-Begriff, der alle Personen einschließt, die sich hierarchisch „oberhalb“ des zu bildenden Projektteams befinden, leitende Funktionen und etwas zu diesem Thema zu sagen haben, also auch die Team- und Projektleiter, zeigt sich in der Praxis oft, dass der Wunsch, den zu implementierenden Scrum-Prozess soweit wie irgend möglich an die bekannten, bestehenden, eigenen bislang genutzten Vorgehensweisen anzupassen, zumeist direkt oder indirekt aus diesem Management heraus kommt. Werden diese Ambitionen aus der Reihe der Entwickler geäußert, zeigt sich oft — wenn auch nicht immer — dass dahinter entweder voreilender Gehorsam steckt („das lässt sich bei uns sowieso nicht durchsetzen„), Frustration („die machen das sowieso, wie sie wollen„), oder direkte, mehr oder weniger subtile „preparation of mind“ durch das Management.

Daran ist zunächst einmal nichts Negatives, denn eine der Aufgabe des Managements ist ja auch, Kontinuität zu bewahren und die Vorgehensweise von Scrum bedeutet schon einen z.T. gewaltigen Wandel.

Die Risiken dahinter sind jedoch offenbar. Scrum ist von Haus aus bereits hoch optimiert und sehr, sehr schlank und es braucht den Einsatz einer „kritischen Masse“ der Anteile von Scrum, damit der Prozess „zünden“ kann. Einzelne Teile aus dem vermeintlichen Werkzeugkasten „Scrum“ zu entnehmen („Wir nutzen nur das, was zu uns passt„) und einzusetzen führt nicht zum Zünden des Prozesses und ist daher relativ nutzlos und z.T. auch nur als Kosmetik zu sehen. Gleiches gilt, wenn zwar mehr oder alle Bestandteile von Scrum dem Namen nach eingesetzt werden, aber ihre Ausprägung und ihr Zusammenspiel derart modifiziert wird, dass sie die bislang praktizierte Vorgehensweise wiederspiegeln und ihre eigentliche Leistung nicht mehr erbringen können.

Zeigt sich dann, dass sich mit dem Einsatz dieses „Scrum-but“s („Yes, wie do Scrum, but …„) nichts oder nur sehr wenig positiv verändert, wird das pauschal Scrum angelastet („Scrum funktioniert nicht„, bzw. das freundlichere „Scrum funktioniert bei uns nicht„), oft gefolgt von einem „Ich habe es gleich gesagt„.

So verständlich die Haltung zunächst einmal ist, so kontraproduktiv ist sie in der Sache und es ist auch häufig nicht „das Management„, das so agiert und auch nicht pauschal diskreditiert werden soll; es sind sondern oftmals lediglich einzelne, einflußreiche Beteiligte, deren individuelle Motivation sehr vielschichtig und differenziert ausgeprägt sein kann. Und obwohl auch gerade die Entwickler von der Einführung von Scrum profitieren, können es auch Entwickler oder andere Beteiligte sein, die aus den verschiedensten Gründen mehr oder weniger offen gegen die Einführung von Scrum intervenieren.

Weitere Informationen finden Sie hierzu auf der Seite „Ist Scrum eine Religion“.

[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1503090852DE