Die dunkle Seite von Scrum

Ich glaube, dass Scrum als moderner iterativ-inkrementeller Softwareentwicklungsansatz der auf Werten beruht ein großes Potential für langfristige Produktivitätssteigerungen besitzt.

Aber “reines” Scrum funktioniert nicht überall. Und “reines” Scrum hat – wie andere “reine Lehren” auch – viele “dunkle” Seiten.

Selbst Evangelisten wie Ken Schwaber gehen auf Probleme bei Einführung von Scrum in Unternehmen ein. Einige der Punkte aus “The Enterprise and Scrum” von Ken möchte ich aus einer eher skeptischen Perspektive kommentieren.

Aus Part I, “Adopting Scrum”:

Staff turnover will occur

Ja, manche Personen möchten nicht mehr Verantwortung und mehr Freiheit. Manche Angestellten arbeiten, um Geld zu verdienen – nicht weil es sich um ihre Berufung handelt. Zugrunde liegt ein Vertragsverhältnis und ein Vertrauensverhältnis. Die Organisation möchte dies nun einseitig ändern. Widerstand wird die Folge sein, Kosten entstehen, Veränderung verlangsamt sich.

Conflict will occurimage

Veränderungen führen zu Konflikten. Sind alle darauf vorbereitet mit Konflikten richtig umzugehen? Hat die Organisation Antworten auf die Fragen die in den Gesprächen gestellt werden? Hat die Organisation die Kraft die Konflikte zu lösen? Meine Erfahrungen hier sind ernüchternd. Mir ist keine ältere Organisation bekannt, die gut mit Konflikten umgehen kann. Unternehmenspolitik spielt hierbei eine wichtige Rolle. Möchte man dies überwinden, so kostet dies Geld und Zeit. Oft müssen auch Personen im mittleren und höheren  Management ausgetauscht werden.

Product management’s job will change and will be harder

Klar, Scrum verschiebt die wirklich komplexen Entscheidungen dorthin, wo sie hingehören: Zum Management. Die wichtigsten Fragen sind: WAS will ich tun – und vor allem was will ich NICHT tun?

Dafür, dass diese Fragestellungen von zentraler Bedeutung sind, wird die Rolle des PO meiner Meinung nach zu wenig beachtet. Der gestiegenen Verantwortung steht im Allgemeinen leider keine gestiegene Entlohnung gegenüber. Im Grunde ein Verlustgeschäft für die betroffenen Manager – zumindest wenn man nur die finanziellen Aspekte betrachtet und eine mögliche gestiegene Motivation durch schnellere Ergebnisse vernachlässigt.

Meiner Erfahrung nach ist es aber auch häufig so, dass aus verwaltenden Produktmanager einfach verwaltende ProductOwner gemacht werden. Zu häufig ist der PO eben nicht er “Gold Owner” und damit geht viel Einflussmöglichkeit dieser Rolle verloren.

Engineering is accountable for quality

Eine Frage, die ich mir immer wieder stelle: Woher wissen die Techniker, was Qualität ist? Qualität muss im Kontext betrachtet werden. Eine Entwicklung für eine Messepräsentation muss nicht unbedingt wartbar oder performant sein. Für eine Software, die der Grundstein für ein Produkt ist, ist dies jedoch sehr wichtig. Zu oft erlebe ich in der Praxis, dass hier immer mit einem Maß gemessen wird. Technik ist nicht Business, Business soll aber die Richtung (“was”) vorgeben. Wenn Technik dann nur eine Art von Qualität liefern kann, dann ist dies zu teuer und es wird kein Geschäftswert generiert.

Compensation policies need to change

Damit wird Scrum zur Restrukturierungsmaßnahme im großen Stil. Viel Spaß mit dem Widerstand, auf den man treffen wird. Betriebsrat? Gewerkschaft? Sind die Manager wirklich so gut, diese Veränderungen an die Belegschaft zu verkaufen?

Jobs will change

Für Deutschland eine spannende Sache. Veränderung der Stellenbeschreibung bei Festangestellten. Vielleicht wollen diese ihre alte Position behalten und klagen dagegen? Nicht jeder ist mit den Veränderungen einverstanden. Mit Widerstand ist zu rechnen – wiederum muss mit Kosten und Verzögerungen gerechnet werden.

Management’s primary responsibility will shift from command to servant leadership

Das Management wird reduziert auf die Beseitigung von Hindernissen. Hier wird stets davon ausgegangen, dass Selbstorganisation funktioniert. Ich bezweifle dies. Leider sprechen meine Erfahrungen dagegen. Die meisten Teams, die ich kenne, denken zu technisch und zu sicherheitsorientiert. Zu langsam und damit unbezahlbar. Der Grund? Meist Überforderung in Form von Multi-Projekt-Abarbeitung und dauernde Veränderung des Fokus. Ja, ein Management-Problem. Ihr könnt aber sicher sein, dass das Management dies gerne lösen würde – aber nicht kann. Superheld Produktmanager (PO) scheitert an der Realität. Wer hätte das erwartet?

Trotz Selbstorganisation wird im Allgemeinen auch nur der Manager an die Wand gestellt. Single wrinkable neck eben.

Management turnover will occur

Für viele Manager ist der Deal mies: Mehr Verantwortung, mehr Stress und Druck. Weniger Einflussmöglichkeiten. Immer noch im Schussfeld, wenn es Probleme gibt – während die Entwicklung ziemlich geschützt ist. Naja, da kann man verstehen, dass der eine oder andere Manager eine Position vorzieht, in denen er mehr bewegen kann.

Fazit

Aus meiner Sicht sieht das Fazit so aus:

Mit Scrum werden die Defizite einer Organisation deutlich. Jede Organisation hat Defizite und Probleme. Was tun? Ken warnt davor, Scrum anzupassen – da dann die Probleme nicht beseitigt werden. Verständlich – aber auch realistisch? Vielleicht. Wenn man in der Lage ist die Kosten einer Einführung von Scrum (as from the book) zu bezahlen. Falls dies nicht der Fall ist, muss mit Kompromissen gearbeitet werden.

Sorry, wollte euch nicht den Tag vermiesen ;-)

11 thoughts on “Die dunkle Seite von Scrum

  1. Danke, gute Punkte. Insbesondere die Bilanz zu »Management turnover will occur« ist zwar ernüchternd, wird aber gern mit einem »Sie haben’s halt nicht verstanden und hängen auf ewig im Gestern« abgetan. Das ist zwar charmant arrogant, aber eben auch wenig hilfreich.

  2. Ich schreibe aus Frankreich.
    Inlands Seite von Bordeaux, Sud-Frankreich.
    Wie ist es um Euch herum mit Generation Y, actuellen 12-35 jährige, und dessen Begriffen?
    Turn-over wird akut steigen, dies ist gewiss mit der Y-Gen.

    Schönen Tag,
    A+

  3. Danke armer Kater. Ich hoffe, dass (endlich) mehr realistische Scrum-Kommentare kommen Die meisten Artikel im Netz zu Scrum stammen von Menschen, die davon leben, anderen Leuten Scrum bei zu bringen. Und haben eine verkaufsfördernd-optimistische Grundhaltung

    Wenn ich sehe, was in unserer Firma seit der Scrum-Einführung passiert, dann ist das Ergebnis nur schlecht.

    a) Ich hatte vorher mehr Freiheit und mehr Verantwortung. Ein Entwickler, der über Jahre hinweg “seinen Codeteil” pflegt und sich gegenüber dem Projektmanager als verlässlicher Partner empfohlen hat, konnte schon immer mit dem Kunden zusammen gute Lösungen umsetzen. Gerade wenn man es mit komplexer Businesslogik zu tun hat, kann und muss man als Entwickler die richtigen Fragen stellen. Collective code ownership bedeutet vor allem, dass jeder Fehler des PO sofort bis zum Kunden durch schlägt, denn die kritische Instanz “Fachentwickler” gibt es nicht mehr.

    b) Früher gab’s die Regel “Jeder ist für seinen Codeteil verantwortlich und fällt auch die entsprechenden Entscheidungen”, solange die Entwicklungsleitung damit leben kann.
    Damit entfielen viele überflüssige, Zeit und Nerven raubende, Konflikte.
    Mich stört die im Scrum übliche ausschließlich positive Sicht auf die Konflikte. Klar, manche Konflikte müssen ausgetragen werden und bringen das Team damit auch vorwärts. Aber oft genug ist es für den Kunden nahe zu egal, welche Entscheidung am Ende getroffen wird. Eine klare Regel wer welche Entscheidung fällt, führt dazu, dass schnell “hinreichend gute” Entscheidungen getroffen werden. Insbesondere wenn Anfänger von einem guten Teamleiter unterstützt werden.
    Man darf auch nicht vergessen, dass gerade Entwickler als eher introvertiert gelten. Die Freude am kreativen streiten ist da im Team sehr ungleich verteilt. Es setzen sich daher nicht immer die besten Lösungen durch.

    c) Die kurzen Releasezyklen fordern Objektorientierte Programmierung, Unit-Test, Regressionstests, Daily Build.
    Alles gute Dinge, die jeder Entwickler bei einer Neuentwicklung gerne berücksichtigen wird.
    Aber was macht man mit einem großen alten System? In einer alten Programmiersprache ?
    Die weder Unit-Test noch Refaktoring vernünftig unterstützt? Wo es länger dauert, den Test zu schreiben als den Code? Wie vermeidet man hier technische Schulden? Wenn der Planungshorizont nicht mal 4 Wochen ist?

    d) Das “der Sprint ist Fix und die Entwickler brauchen die Zeit zum Programmieren” führt dazu, dass notwendige Fragen nicht mehr an uns herangetragen werden. Da versucht sich der Support irgendwie zu helfen, da trifft der PO einsame Entscheidungen, da bekommen Anwender Falschinformationen.
    Es gibt Dinge, die können eben nicht drei Wochen bis zum nächsten Planungsmeeting warten. Dürfen sie nicht mehr an die Entwickler herangetragen werden, dann werden eben ohne Rücksprache mit der Entwicklung Fakten geschaffen, mit denen die Entwickler in Zukunft irgendwie zurecht kommen müssen. Früher konnte ich da durchaus manchmal steuernd eingreifen, wenn ich z. B. ein Angebot gegengelesen habe.

    • Sehr interessanter Kommentar, viele der angesprochenen Punkte kenne ich aus eigener Erfahrung!

      Ich bin ganz klar von Scrum überzeugt – allerdings darf man vor den ganzen Herausforderungen nicht die Augen verschließen und verlangen, dass sich die ganze Organisation oder die Kunden gefälligst ändern sollen.

      In manchen Konstellationen macht Scrum auch keinen Sinn. Vielleicht kann noch der eine oder andere Ansatz übernommen werden, aber dies ist im Einzelfall zu prüfen.

  4. Hallo Felix,
    ich sehe ja auch, dass Scrum gute Ansätze hat:
    Kurzfristige Planung, ein vernünftiges Menschenbild, die richtige Erkenntnis, dass ausschließlich der Entwickler die Verantwortung für den Code übernehmen kann, der Versuch trotz des ständigen Zeit- und Kostendrucks Qualität zu schaffen….
    Da sind viele gute Dinge drin.
    Aber auch vor Scrum haben nicht alle in einem hoch reglementierten Wasserfall gearbeitet, in dem die Mitarbeiter nur bessere Kodiermaschinen waren.

    Du sprichst hier wirklich die richtigen Dinge an. Auch mit deinem wichtigen Hinweis auf die Kosten.

    Manchmal frage ich mich, ob es nicht effektiver wäre, einfach noch ein oder zwei Entwickler einzustellen, als die ganze Firma nach Scrum umzubauen. Irgendwo habe ich den Verdacht, dass die in der Entwicklung gewonnene Produktivität von den anderen Abteilungen bezahlt wird. Das kann der PO sein, der jetzt eine Verantwortung trägt, die ein Mensch alleine kaum tragen kann. Der Überstunden macht um pünktlich zum Meeting das priorisierte Backlock vorweisen zu können. Das können die Supporter oder Verkäufer sein, die die Kunden bis zum nächsten Sprint vertrösten müssen, denn eine Zeitschätzung zwischendurch gibt’s halt nicht….

    Und… der mise Deal des Managements: So zugespitzt hatte ich das noch nicht gelesen. Aber recht hast du.

  5. Hallo,

    bin froh endlich auch mal von Leuten zu lesen, die Scrum durchaus auch kritische Seiten abgewinnen können. Wenn man sonst im Web von Scrum liest, ist das fast auschließlich positiv.
    Bei uns in der Firma wird seit ca. 2,5 Jahren nach Scrum gearbeitet. Vor der Scrum Ära war ich für bestimmte Module verantwortlich. Man kannte sich in seinen Sachen sehr gut aus und konnte schnell etwas neu entwickeln. Ich habe eine bestimmtes Feature “begleitet” von der Formulierung der Anforderungen bis hin zur Doku schreiben am Ende. Mir hat es Spaß gemacht.
    Seitdem wir Scrum eingeführt haben, habe ich das latente Gefühl, das wir im Grunde genommen, neue Features langsamer entwickeln. Also, das wir insgesamt stark an Effizienz verloren haben. Scrum setzt ja irgendwie voraus, das die Teammitglieder sich in allen Themen Bereichen gleich gut auskennen. Da wir jedoch sehr unterschiedliche Module verwalten müssen, hat das in den letzten Jahren eher dazu geführt, das man von vielen Dingen wenig weiß. In meinem “ehemaligen” Modul bin ich noch immer der Experte. Zweimal habe ich Teammitgliedern eine Einführung gegeben, damit das Wissen weiter gestreut wird und sie mir helfen können. Die Einarbeitung hat Zeit gekostet. Dann jedoch wurde wieder über längere Zeit kein Item von meinem ehemaligen Modul eingeplant. Das führte dazu, das meine Teamkollegen, das kürzlich erworbene Wissen wieder vergessen haben!

    Im letzten Sprint hatten wir ein großes Item eingeplant, das wir mit 5 Teammitgliedern bearbeiten sollten. Leider hat man dabei vergessen auch zu bedenken, daß man nicht jede Arbeit endlos parallelisieren kann. Es war also ein Riesenproblem alle 5 Leute sinnvoll zu beschäftigen. Hätte man die Aufgabe mit 2 Personen abgearbeitet, wäre es vermutlich genauso schnell gewesen. Man kann eben nicht die Fenster einbauen, bevor die Wände stehen.

    Ein Riesenproblem ist auch, uns zu einigen. Früher hat man als Modulverantwortlicher technische Entscheidungen selbst treffen können. Wenn man das Bedürfnis hatte, hat man sich mit Kollegen ausgetauscht, von denen man geglaubt hat, das sie einem hinreichend gut beraten können. Dabei sind auch immer ganz gute Entscheidungen rausgekommen. Jetzt ist es so, daß wir manchmal selbst über Kleinigkeiten endlos diskutieren, ohne das oftmals ein greifbares Ergebnis raus kommt.

    Fazit: Nach 2,5 Jahren Scrum bin ich ziemlich demotiviert. Es ist für mich nur noch ein Job zum Geld verdienen geworden. Der Spaß ist dabei verloren gegangen.

    Das entspricht wohl nicht der schönen neuen Welt, die Scrum schaffen soll!

  6. Hallo Ursel,

    alle Punkte die Du genannt hast können passieren. Ich frage mich nur, wie Ihr in der Retrospektive darauf reagiert. Auch bei uns hat es ähnliche Situationen wie “5 Leute an einem Feature sind zu viel”. Es vergeht aber keine Retro bei der wir aus solchen Erfahrungen keine Konsequenzen ziehen würden.

  7. Hallo Felix,

    das Thema “Product management’s job will change and will be harder” beschäftigt mich auch gerade. Ich hab mal – passend zur Jahreszeit – eine kleine Weihnachtsgeschichte draus gemacht:

    hhttp://www.experts-at-work.de/news/blog/weinachten-nach-scrum-manier.html

Comments are closed.