“Es dürfte Ihnen schwer fallen zu erklären, warum Sie eine Leiche vergraben, die Sie nicht getötet haben.”
aus dem Film “Immer Ärger mit Harry”
In Scrum arbeiten selbstorganisierte, selbständige Teams an der Entwicklung der Software. Sie stellen am Ende eines jeden Sprints ein neues lauffähiges System für den Kunden bereit.
Auf diesem System kann der Kunden arbeiten und Erfahrungen sammeln. Dabei wird er feststellen, dass er vielleicht gewisse Features noch vermisst, andere als unnötig empfindet, entdeckt vielleicht Fehler oder im angenehmsten Fall, ist er von der neuen Version begeistert.
Neue Anforderungen des Kunden werden vom Product Owner in Form von Stories an das Team übergeben und es liegt in der Verantwortung des Product Owner, die neuen Anforderungen verständlich und nach absteigenden Business Value dem Team zur Verfügung zu stellen.
In der Verantwortung des Teams liegt es, so viele Features wie möglich im Sprint umzusetzen. Neben einer schnellen und korrekten Umsetzung muss das Team auch für eine nachhaltige Entwicklung sorgen. Dazu muss es auf die Qualität, die Wartbarkeit, die Erweiterbarkeit und die Testbarkeit der Software achten.
Was hat dieser kurze Blick auf Scrum denn nun mit Hierarchien zu tun und wieso bedeuten Hierarchien Ärger? Eine Hierarchie verursacht Probleme, wenn ihre Grundmotivation den Prozesszielen entgegensteht. Ob der Prozess nun Scrum, XP, Kanban, Wasserfall oder V-Modell ist, wenn die Triebfeder der Führungskräfte nicht aus dem jeweiligen Prozess heraus entsteht, führt dies zu massiven Störungen.
Der halbherzige Schritt in Richtung Scrum, der alte Strukturen in der Firma unberührt lässt, ist eine selbsterfüllende Prophezeiung des Scheiterns. Schon Parkinson formulierte in seinen Gesetzen zur Arbeit, dass sich Hierarchien erhalten wollen und sich nicht von selber optimieren. Daher werden Management Pyramiden die für Umsätze und Erfolgsmeldungen honoriert werden, sich immer in die Arbeit ihrer Untergebenen einmischen.
Neben den Führungskräften, die Scrum ablehnen und ganz bewusst den neuen agilen Ansatz torpedieren, gibt es aber auch viele, die an der Reibungsfläche zwischen Führung und Autonomie scheitern.
Grundsätzlich Fehler machen Führungskräfte, die versuchen den Prozess von außen zu optimieren. Ein beliebtes Werkzeug ist Meetings nur noch mit den wichtigen Mitgliedern durchzuführen und dadurch Zeit zu sparen. Dies ist natürlich eine Milchmädchenrechnung, da die interne Kommunikation im Team erhöht wird und sich Fehler durch diese Art von Stille Post einschleichen. Die Trennung zwischen wichtigen und unwichtigen Mitgliedern treibt einen Keil ins Team, der die Motivation einzelner Mitarbeiter und das Zusammenspiel im Team gefährdet. Oft kommen die gewichtigen Einwände von den Kollegen, die in den Augen der Führungskräfte nur kritisch, anstrengend und übervorsichtig sind und deshalb natürlich nicht zu Meetings eingeladen werden. Wenn dann eintritt, was diese Kollegen vorhergesagt haben, hört man nicht umsonst ein verächtliches “Das hätte ich euch sagen können” auf den Fluren.
Direkten Druck auf das Team auszuüben, ist ein weitaus schwierigeres Unterfangen, dass meist von den Teams und ihren Scrum Master abgeblockt werden kann. Da das Team über seine Commitments den Zufluss der Arbeit steuert, kann hier nur an das Gewissen der einzelnen Kollegen appelliert werden. Das funktioniert einige Male, aber dann muss die Führungskraft sich der Eitelkeit der Entwickler bedienen. Nichts schmeichelt einem Mitarbeiter mehr als Sonderaufgaben oder die Wahrnehmung der eigenen Expertise durch Führungskräfte. Kurzfristig ein Erfolgsmodell, dass aber schnell zum Bumerang wird, weil der Mitarbeiter zum Außenseiter im Team wird. Die Performance fällt und das Team und der Scrum Master müssen die Situation klären.
Die fatalsten Schäden werden aber verursacht, wenn die Führungskräfte der Idee verfallen, man könne Projektaufgaben beliebig über die Teams verteilen, oder schon Teilarbeiten von Stories irgendwo dazwischen drücken. Das dies überhaupt möglich ist, liegt an einer Firmenkultur, in der Scrum noch nicht angekommen ist. Jedes vernünftige Team sollte Stories für ein fremdes Projekt, die es ohne Absprachen mit dem verantwortlichen Team vorgestellt bekommt, ablehnen. Benötigt ein Projekt mehrere Teams, dann müssen diese Teams durch ein Scrum-konforme Mechanismen, wie etwa Scrum of Scrum oder Nexus zusammengehalten werden und nicht durch den Product Owner. Der Product Owner kann die technische Kopplung zwischen den Teams nicht gewährleisten, da seiner Rolle die entsprechenden Fähigkeiten und Befugnisse fehlen.
Wer Geld verschwenden will, der gönnt sich eine vielschichtige Hierarchie über seine Teams. Alle anderen sorgen für mehr Luft, damit sich Scrum entfalten kann.