TopMenue

Ist Scrumcess eine Religion?

Scrum ist nicht einsetzbar“, behaupten immer wieder die Kritiker agiler Softwareentwicklung über Scrum, weil es „verboten sei, Scrum an die spezifischen Bedürfnisse des Unternehmens anzupassen“. Das Wissen über Scrum würde von den Scrum-„Jüngern“ als „Religion gepredigt“ und Scrum dürfe nur so, wie es von den „Gurus“ erdacht worden war, verwenden werden. Das sei für die Unternehmen nicht akzeptabel.

Dieser Kritikpunkt wiegt schwer, da Scrum und Scrumcess hiermit Ineffizienz durch dogmatische Strukturen unterstellt wird und die Unternehmen daraus ableiten könnten, dass Scrum und Scrumcess für den Einsatz in ihrem Projektgeschäft untauglich sind. Aus diesem Grund wird immer wieder die Forderung erhoben, die Implementationen bereits im Vorwege des ersten Einsatzes gründlich an die eigene Unternehmensstruktur anpassen zu können, bevor man sich Gedanken über einen erfolgversprechenden Einsatz machen könne.

Was ist an Scrumcess anders als an anderen Softwareentwicklungsprozessen?  ^

Die klassischen Softwareentwicklungsprozesse sind gekennzeichnet durch eine außerordentlich große Menge an Vorschriften und Regeln bis ins letzte Detail hinein, was im Gegenzug aber zu hohen Einarbeitungsaufwänden führt. Die Projektplanung erfolgt einmalig zu Beginn des Projektes. Werden im Verlauf des Projektes Änderungen notwendig, muss ihre Realisation entweder unter großem Aufwand in den alles umfassenden Projektplan eingebaut oder in eine spätere Phase des Projektes verlagert werden. Eine Auslieferung erfolgt i.A. nur am Ende einer Phase, z.B. einer Version.

Scrum und Scrumcess setzen dagegen auf eine kleine Anzahl ausgesuchter und optimal aufeinander abgestimmter Bestandteile (Rollen, Artefakte, Prozeduren, etc.) und Regeln, und beim Team auf ein hohes Maß an Professionalität und Pragmatismus. Dabei wird das Ziel verfolgt, den Teammitgliedern einen möglichst weiten Raum zur Entfaltung ihrer kreativen Fähigkeiten zu verschaffen, kommunikative Reibungsverluste zu minimieren, Defizite der konkreten Prozess-Implementation zu erkennen und zu beseitigen, um daraus Synergieeffekte zu generieren.

Mit dem agilen Ansatz ist man jederzeit darauf vorbereitet, dass sich Anforderungen — und damit der Plan der kommenden Phase (Sprint) — ändern können. In Scrum und Scrumcess werden auf den verschiedenen zeitlichen Ebenen (Version, Release, Sprint) mit unterschiedlicher zeitlicher Reichweite geplant. Es gibt es keine allumfassende, vorab festgelegte Checkliste, mit der man sich durch Abhaken der einzelnen Punkte durch jedes Detail des gesamten Projektes arbeiten kann.

Darüber hinaus erhalten die Stakeholder in Scrum und Scrumcess regelmäßig am Ende eines Sprints einen neuen, einsetzbaren Softwarestand.

Welche Unternehmen interessieren sich eigentlich für Scrum und Scrumcess?  ^

Im Prinzip haben alle Unternehmen Interesse an Scrum, die Softwareentwicklungsprojekte durchführen, deren Komplexität einer besonderen Strukturierung bedarf und mit Projektteams von jeweils ca. 5-9 Entwicklern durchgeführt werden.

Bei sehr kleinen Teams (bis 3 Entwickler) oder leicht überschaubaren Projekten (was meist gemeinsam einhergeht), ist es normalerweise nicht notwendig, für diese Projekte extra einen Entwicklungsprozess zu implementieren.

Welche Vorteile dürfen sich Unternehmen von Scrum und Scrumcess erhoffen?  ^

Sofern der Scrum-Prozess z.B. in Form von Scrumcess gut implementiert und von den beteiligten Personen akzeptiert und angenommen wurde, führt Scrumcess zu einer modernisierten Softwareentwicklungskultur.

Neu gestaltete, klar zuzuordnende Verantwortlichkeiten, schlankere Abläufe, eine effektivere und entspanntere Art der Zusammenarbeit, häufige und frühe Auslieferungen an die Stakeholder und daraus folgend frühes Feedback an das Unternehmen resultieren in einer höheren Mitarbeitermotivation, geringerem Projektdruck und -risiko, höhere Kunden-, Mitarbeiter- und damit auch Unternehmenszufriedenheit, was die Erfolgschancen des Projektes erhöht.

Welche Unternehmen befürchten Probleme in der Einführung von Scrum oder Scrumcess?  ^

Probleme sehen insbesondere Unternehmen, die zuvor einen klassischen Softwareentwicklungsprozess wie Wasserfall, V-Modell oder andere eingesetzt haben. Sie haben ihre Mitarbeiter in der Handhabung des klassischen Prozesses geschult, ihn in Projekten eingesetzt und damit ihre Softwareentwicklungskultur geprägt und sehen sich nun für den Fall, zu einem agilen Softwareentwicklungsprozess zu wechseln vor der Aufgabe, ein neues und in wesentlichen Punkten anderes Vorgehensmodell adaptieren zu müssen. Das bedeutet, erneut zu investieren, neue Wege zu beschreiten, die Prägung ihrer Softwareentwicklungskultur zu verändern, damit evtl. sogar einen Paradigmenwechsel herbeizuführen, was bei den beteiligten Mitarbeitern in Management und Entwicklung zu einer Verunsicherung führen kann, sich eventuell in einem gefühlt existentiellen Rahmen umorientieren oder vielleicht sogar neu definieren zu müssen.

Keine Probleme mit dem Einsatz von Scrum und Scrumcess haben hingeben Unternehmen, die erstmalig Softwareentwicklungsprojekte in der genannten Größe durchführen und noch nicht über eine gefestigte Softwareentwicklungskultur verfügen, sowie solche, die schon erfolgreich Entwicklungsprojekte mit agilen Softwareentwicklungsprozessen durchgeführt haben und daher bereits über eine entsprechende Kultur verfügen. Sie sind nicht durch den Einsatz der klassischen Softwareentwicklungsprozesse geprägt und müssen keinen Paradigmenwechsel durchführen.

Welche Gruppen argumentieren gegen Scrum und Scrumcess?  ^

Das Problem betrifft nicht Scrum oder Scrumcess allein, sondern generell den Wechsel von den klassischen zu den agilen Softwareentwicklungsmethoden; Scrum und Scrumcess ist aktuell lediglich der verbreitetste Vertreter dieser Methoden.

Es gibt eine Reihe von Personengruppen, die die Einführung eines neuen Prozesses fürchten:

  • Diejenigen, die eine Entscheidung treffen müssen, ob ein Prozess eingeführt werden soll, denn vielleicht hat es zuvor noch gar keinen Prozess gegeben, vielleicht hat sich ein zuvor implementierter Prozess als unpassend oder nicht tauglich herausgestellt.
  • Diejenigen, die Veränderungen gegenüber generell Vorbehalte haben, da es ihnen die Sicherheit des bekannten Umfeldes, in dem sie sich eingerichtet haben, nimmt.
  • Diejenigen, denen eine größere Mitwirkungspflicht zugemutet werden soll (z.B. Entwickler oder Stakeholder), die aber gar nicht tiefer eingebunden werden wollen.
  • Diejenigen, deren Möglichkeiten zur Einflussnahme eingeschränkt werden (z.B. hat keine der Rollen in Scrum und Scrumcess eine direkt Weisungsbefugnis gegenüber einer anderen Rolle).
  • Diejenigen, die Ängste haben, dass die Rolle, die sie bislang innehatten (z.B. Projektleiter) wegfällt, zumal so eine Rolle leicht mit einer Stellung im Betrieb (z.B. Abteilungsleiter) assoziiert wird und sie dann den Verlust von Privilegien, Einfluss, vielleicht sogar des Arbeitsplatzes fürchten.
  • Diejenigen, die sich davor fürchten, sich für zusätzliche / zukünftige Aufgaben umorientieren oder sogar neu qualifizieren zu müssen (z.B. Aufgaben als Product-Owner oder als Scrum-Master).

Warum wollen Unternehmen Scrum und Scrumcess schon vor der Einführung anpassen?  ^

Softwareentwicklungsprojekte und -prozesse sind sehr komplexe Themen und gerade die klassischen Softwareentwicklungsprozesse mit ihrer überbordenden Reglementierung aller Belange des Projektes bis nahezu in kleinste Details hinein, bedeuten einen intensiven Einarbeitungsaufwand.

Voreilender Kostenreduzierungsreflex  ^

Dazu kommt, dass in den Unternehmen auf der Entscheidungsebene oftmals kein wesentlicher Unterschied zwischen den Aufwänden für die Einführung agiler und klassischer Prozesse gemacht wird. Dort versucht man dann reflexhaft, die Aufwände von vornherein dadurch zu begrenzen, dass nur die für sie gefühlt wichtigen Teile des Prozesses implementieren werden sollen.

Sie sehen Softwareentwicklungsprozesse oft als Bündel von Maßnahmen und Möglichkeiten, die für die eigenen Belange beliebig konfigurierbar sind und nicht als homogene, integrierte und im Fall von Scrum und Scrumcess bereits weitestgehend optimierte Lösung.

Problemzone „Ego“  ^

Manche Unternehmen sagen, „was wir nicht an uns anpassen können, ist nicht für uns gemacht„, oder „Der Prozess ist für uns da und nicht wir für ihn„. Interessant ist auch die selbstbewusste Aussage „Wir nutzen keine Standards, wir setzen sie!„.

Solche Aussagen sind insbesondere dann interessant, wenn sich die Unternehmen mit Scrum oder Scrumcess beschäftigen, weil sie oft zuvor Probleme mit den eigenen Prozessen (egal ob klassisch, „Eigenbau“ oder im Prinzip gar nicht vorhanden) hatten und händeringend nach Alternativen oder den Weg aus einer Krise suchen.

In diesen Unternehmen trauen sich die hausinternen Ansprechpartnern in den Fachbereichen häufig nicht, diese Aussagen aus der Entscheidungsebene in Frage zu stellen oder ihnen entgegenzutreten, weil sie befürchten müssen, bei einem eventuellen Fehlschlag selbst in die Verantwortung genommen zu werden.

Scrum als Marketinginstrument?  ^

In diesem Fall interessieren sich die Unternehmen so gut wie gar nicht für Scrum oder Scrumcess als potenzieller Softwareentwicklungsprozess, sondern aus einem ganz anderen Grund: Marketing.

Scrum ist im Trend, Scrum ist hip, Scrum ist angesagt, man „machtScrum und wer kein Scrummacht„, der ist nicht „top„, der ist nicht „dabei„. Dem Unternehmen ist es in diesem Fall weitestgehend egal, was Scrum oder Scrumcess leisten können, oder ob Scrum oder Scrumcess überhaupt etwas für das Unternehmen leisten kann, denn es will lediglich nach außen hin darstellen, dass es Scrum nicht nur „kann„, sondern Scrum auch „macht“ (um „dazu zu gehören„). Für diesen Zweck will es allerdings keine besonderen Aufwände treiben, sondern nur, dass Scrum irgendwo präsent ist, sich aber ansonsten ganz an die bereits vorhandenen Prozesse anpasst, unabhängig davon, wie erfolgreich die eingesetzten Prozesse bislang waren.

Scrum oder Scrumcess als Personalmanagement?  ^

In diesem Fall versuchen die Unternehmen, Scrum oder Scrumcess als Personalmanagement-System einzusetzen. Es gibt dann nicht ein Projekt, an dem alle gemeinsam arbeiten, sondern meist für jeden einzelnen Entwickler ein eigenes, die aber alle in ein übergeordnetes Projekt eingebettet sind. Scrum-Master, Product-Owner, Teamgeist und Kollaboration, Projektplanung (des übergeordneten Projektes), etc. werden nicht benötigt, lediglich ein Projektleiter, der im Daily-Scrum und im Sprint-Review die Berichte der Entwickler entgegennimmt.

Warum soll man Scrum und Scrumcess nicht bereits im Vorwege anpassen?  ^

Weil man zu diesem Zeitpunkt noch gar keine Grundlage dazu hat.

Scrum und Scrumcess sind Systeme  ^

Ein implementiertes Scrumcess ist ein pragmatischer, sich an den real auftretenden Bedürfnissen in der Softwareentwicklung orientierender, bereits „out-of-the-box“ hochoptimierter Softwareentwicklungsprozess, der in Form eines kompletten Systems darauf hinarbeitet, dass, wie in einem gut geschmierten und gewarteten Getriebe, ein Rädchen spiel- und verlustfrei in das andere greift.

Scrum und Scrumcess sind kein Werkzeugkasten  ^

Man darf sich Scrum und Scrumcess — wenn man sich einen umfassenden Vorteil aus dem Einsatz verspricht — nicht als Maßnahmenbündel und auch nicht als Werkzeugkasten vorstellen, aus dem man ein beliebiges Werkzeug entnehmen und irgendwo einsetzen kann, denn dann nutzt man nur dieses eine Werkzeug (oder eben eine Anzahl von ihnen), aber nicht das optimierte Zusammenspiel eines gut durchdachten Prozesses. Die einzelnen Werkzeuge (z.B. Rollen, Artefakte oder Meetings) sind ohne Frage einzelne und wichtige Bestandteile, aber den ihnen innewohnenden Vorteil spielen sie erst in der Komposition, im Zusammenspiel, in der Melodie des Prozesses aus, genau wie Akkorde in der Musik oder die perfekte Zusammenarbeit eines perfekten Teams.

Mangelnde Erfahrung  ^

Greift man in die hochoptimierten Abläufe eines organisatorischen Körpers, wie Scrumcess ihn darstellt, ein, ohne Erfahrungen mit den dort z.T. sehr diskret ablaufenden und zumeist zwischenmenschlichen Prozessen gemacht zu haben, läuft man Gefahr, in der Absicht, eine Verbesserung herbeizuführen, das Zusammenspiel des Ganzen zu stören. Damit schränkt man den vom Prinzip her sehr gut funktionierenden Prozess in seiner Leistungsfähigkeit ein und verhindert die Ausbildung von Synergien, die der eigentliche Ertrag des optimierten Zusammenspiels aller Komponenten sind.

Hier wird das Verhältnis der Teammitglieder zum Projektprozess durch die von außen zugeführten Störungen des optimalen, harmonischen Zusammenspiels aller Komponenten (Flow) belastet, was negative Auswirkungen auf die Teamleistung hat.

Was ist der Flow?  ^

Der Flow ist die Kraft von Scrum und Scrumcess. Er erschließt sich nicht direkt aus der Beschreibung des Prozesses, sondern ist eine erwünschte Konsequenz, ein gewollter Effekt. Er entsteht aus dem vom Unternehmen geschaffenen, positiv besetzten Umfeld, sowie dem Teamgeist der Mitarbeiter und ist eine der Grundlagen für den Erfolg von und durch Scrum und Scrumcess.

Der Teamgeist nährt sich von der vom Product-Owner erstellten Produktvision, aus einer Atmosphäre gegenseitiger Achtung, Respekt, Vertrauen und der Überzeugung, an einem wertvollen Projekt des Unternehmens beteiligt zu sein, für das alle gemeinsam an einem Strang ziehen, und, dass alle gleichermaßen an den Wert und Erfolg des Projektes glauben und bereit sind, hart dafür arbeiten.

Eine weitere Grundlage für den Flow ist die in Scrum und Scrumcess optimierte Abstimmung der Prozeduren, das Design der Rollen mit ihren „do’s and dont’s“, sowie ihren klar voneinander abgegrenzten Verantwortlichkeiten und dem kontinuierlichen Informationsfluss zwischen allen Beteiligten. Jedem sollte jederzeit bewusst sein, ein wichtiger und wesentlicher Teil des Team und wirklich mittendrin, statt nur dabei zu sein.

Der Flow ist ein Zustand, aus dem effiziente Kommunikation, hohe Leistungs- und Einsatzbereitschaft und eine außerordentliche Motivation, das gesteckte Ziel erreichen zu wollen, entsteht und wachsen kann. Dem Team scheint es dann, als liefe alles leicht und wie von selbst.

Ambivalentes Verhalten des Unternehmens  ^

Will ein Unternehmen Scrum oder Scrumcess einführen oder zumindest prüfen, besteht und drängt aber von vorn herein auf unternehmensspezifische Veränderungen des Prozesses, drückt es damit eine deutliche Skepsis gegenüber dem Prozess aus und stellt hierdurch den Sinn und den Wert einer Einführung in Frage. Eine weitere Unsicherheit ergibt sich daraus, dass im Vorwege nicht vollständig geklärt werden kann, ob Prozess und Team nach den Änderungen noch in der Lage sind, ihr Potential vollständig zu entfalten.

Die vom Unternehmen ausgehende Skepsis und Unsicherheit überträgt sich auf das Team und verhindert, dass der Prozess richtig „zündet“. Ist das Verhältnis der Teammitglieder zu Projekt und Prozess erst einmal derart belastet, führt das in einem eventuellen Pilotprojekt ebenfalls zu Unsicherheiten und im weiteren Verlauf zu einer Leistungsbeschränkung von Team und Prozess; der Flow kommt nicht zustande.

Man kann es vielleicht vergleichen mit einer Situation, wo eine optimal eingestellte Maschine hoher Leistung zum Einsatz kommen soll, die Techniker aber, ohne die Maschine oder ihr Setup zu kennen, Teile ihrer Peripherie austauschen, sowie Einstellungen und Parameter ändern, etc. Ob die Maschine nach diesen Modifikationen die erwartete Leistung von erbringt, ist fraglich.

Wer ist schuld?  ^

Bleibt die Leistung des Systems, bestehend aus Team und Prozess, hinter den Erwartungen zurück oder scheitert das Projekt sogar, wird dies meist reflexhaft und unabhängig vom Ursprung der Probleme, dem System „Team+Prozess oder ausschließlich dem Prozess angelastet und nicht den belastenden Vorbedingungen, den Änderungen und den daraus zu erwartenden Nebenwirkungen.

Gibt es eine Lösung?  ^

Pilotprojekt mit striktem Scrum oder gleich Scrumcess  ^

Um eine zielorientierte, kontroverse und konstruktive Diskussion und Auseinandersetzung über den Prozess, seine Stärken und spezifischen Anforderungen führen zu können, reicht das Studium von Büchern über Scrum nicht aus. Das Unternehmen sollte ganz pragmatisch ein gut überschaubares Pilotprojekt mit einem von einem erfahrenen Scrum-Coach oder Scrum-Master implementierten, unmodifizierten, strikten Prozess und einem gut motivierten Team durchführen.

Ziel dieses Projektes ist auf der einen Seite natürlich, das Projekt erfolgreich durchzuführen und abzuschließen, auf der anderen Seite aber auch, den Prozess kennen zu lernen und Erfahrungen mit ihm zu machen. Aus dem Projektverlauf heraus sollte man Erkenntnisse darüber erhalten, ob und wie Scrum oder Scrumcess erfolgreich im Unternehmen einzusetzen ist. Damit diese Erkenntnisse aussagekräftig und belastbar sind, müssen Prozess und Projekt mit uneingeschränkter Unterstützung und Wertschätzung des Unternehmens ausgestattet sein, da Prozess, Projekt und Team sonst der für eine erfolgreiche Durchführung notwendige Rückhalt fehlt.

Prozessanpassungen?  ^

Erst wenn man den Prozess und seine Spezifika kennen gelernt hat und weiß, wie die konkret beteiligten Personen mit dem aktuell implementierten Prozess interagieren, kann das Projekt-Team, ggf. gemeinsam mit einem Scrum-Coach, nach Stellschrauben suchen und beginnen, Stück für Stück an ihnen zu drehen. Tut man das ohne die notwendige Erfahrung mit Prozess, Team und dem integrierten System aus Prozess und Team, kann man keine fundierte Aussage mehr über die Veränderungen des Verhalten machen und hat sich selbst, dem Prozess und dem Team bereits im Vorfeld jede Chance genommen, zu einer optimal operierenden Einheit zu verschmelzen.

„inspect & adapt“  ^

Darüber hinaus stellen Scrum und Scrumcess von Haus aus eine Möglichkeit zur Team/Prozess-individuellen Verbesserung des Prozesses als Teil der Sprint-Retrospektive, des letzten Meetings ganz am Ende jeden Sprints, zur Verfügung: „inspect & adapt“ (Untersuchen und Anpassen). In der Sprint-Retrospektive kann das Entwicklungsteam gemeinsam mit dem Scrum-Master, ggf. dem Scrum-Coach und, falls gewünscht, dem Product-Owner, über die Dinge, die nicht optimal abgelaufen sind, zu sprechen und Wege zu finden, diese Defizite abzustellen. Ein wesentliches Merkmal der Sprint-Retrospektive ist, dass am Ende — sofern Probleme identifiziert wurden — konkrete Maßnahmen beschlossen werden, um die Probleme im Laufe des nächsten Sprints zu beheben. Es ist dann die Aufgabe des Scrum-Masters, darauf zu achten, dass die beschlossenen Maßnahmen auch durchgeführt werden.

Sind Scrum oder Scrumcess denn nun eine „Religion“?  ^

Nein. Die Aussage, man dürfe Scrum und Scrumcess nicht an seine Bedürfnisse anpassen, ist falsch. Weder Scrum, noch Scrumcess sind Dogma oder Religion. Man kann, man darf und man sollte Scrum und Scrumcess nach einer ernsthaften Überprüfung der Notwendigkeit an die eigene spezifische Kultur anpassen; sollte aber erst nach einer erfolgreichen Einführung des Prozesses damit beginnen, da man dann erst die Erfahrungen gemacht hat, die einen dazu in die Lage versetzen.

Auf keinen Fall sollte man es jedoch bereits im Vorwege tun; da weiß man nämlich noch nicht, welche Konsequenzen die Änderungen für Prozess und Team haben.

Allerdings sollte man sich weiterhin ernsthaft die Frage stellen, ob die zusätzlich Ressourcen bindende Initiierung eines solch ausdrücklichen Anpassungsprozesses wirklich notwendig ist, denn das Prinzip permanenter Verbesserung — und damit Veränderung der konkreten Implementation im Unternehmen — ist, wie beschrieben, bereits originär in Scrum und Scrumcess durch „inspect & adapt“ in Form der Sprint-Retrospektive tief verankert.

Das Ziel sind umfassend erfolgreiche Projekte  ^

Ohne Frage hat jedes System seine Stärken und Schwächen und man mag es als ein potentielles Defizit von Scrum oder Scrumcess ansehen, dass es auf Professionalität und eine gut ausgebildete und gelebte Fähigkeit zur Zusammenarbeit der Mitarbeiter, sowie auf einen ausgeprägten Teamgeist (aus innerer Überzeugung, nicht als Lippenbekenntnis) baut.

Man darf aber an dieser Stelle auch nicht vergessen, dass es darum geht, Softwareentwicklungsprojekte in einem immer enger und schwieriger werdenden Markt zu einem für Unternehmen und Auftraggeber / Kunde zu einem erfolgreichen Abschluss zu bringen.

Das funktioniert nun mal ohne ein gerütteltes Maß an Professionalität, Pragmatismus und Teamgeist nicht … das hat es noch nie.

[zurück zum Seitenanfang]


, ,

No comments yet.

Schreibe einen Kommentar

V1710260636DE