Scrum für Schlipsträger – Nachhilfe in Sachen Change Management

Anforderungen sind jetzt Geschichte(n), was früher Rolling Wave Planning hieß wird heute als “agil” gelobt, aber generell sind Pläne pfui, das sind jetzt Backlogs und sie sind eher unverbindlich. Time Boxing, Demingzyklus und Leistungswertanalyse werden unter anderem Namen der jubelnden Entwicklerschar als brandneu und viel geeigneter als alles zuvor verkauft. Außerdem steht jetzt der Mensch im Vordergrund, alles ist Produktentwicklung und Personentage gibt es nicht mehr in der schönen Welt des Scrums.

Wenn es wie eine Ente watschelt, wie eine Ente quakt und wie eine Ente aussieht, kannst du es eine Giraffe nennen, aber es ist dennoch eine Ente.

image

Wir wissen ja: Chaos im Unternehmen ist bekanntlich Folge des bösen und generell untauglichen Wasserfallmodells. Fortschritt durch das neue Vorgehen ist hingegen wissenschaftlich belegt gemäß des Axioms “Tausend Gurus können nicht irren” sowie Beweis durch vollständige Anekdote.

Eine dieser Anekdoten geht wie folgt: Man nehme ein vorzugsweise leicht ausgebranntes Entwicklerteam, schule es ein paar Tage in angenehmer Umgebung durch einen hochmotivierten Scrumverkäufer, zelebriere einen unbelasteten Neubeginn, lasse das Team in Ruhe werkeln und messe sodann die Arbeitseffizienz. Überraschung – die Effizienz steigt! Wer hätte das gedacht? Und wer glaubt, dass ein solcher Versuch etwas nachweisen kann?

Alter Wein in neuen Schläuchen

Es lebe die neue, agile Welt, alles wird gut. Nun, mit Sicherheit wird alles für Autoren gut, denn jetzt kann man viele Bücher füllen mit Dingen, die es alle schon mal gab und jetzt neu erklärt werden müssen.

NEU ÄHNLICHE HERKÖMMLICHE BEGRIFFE
Sprint Iteration, Zyklus, Time Box
Scrum Master Kümmerer, Moderator
Product Owner Produktmanager, Projektleiter
Backlog Projektstrukturplan, Phasenplan, Roadmap, Themenspeicher
Story Arbeitspaketbeschreibung
Planning,Daily,Feature Done/Sprint Review,Retro Plan,Do,Check,Act
Burndown Fortschrittsbewertung
Planning Poker Broadband Delphi
Scrum Wall Kanban Board

Ein kleines Wörterbuch für Traditionalisten

Miesmacher, so bin ich eben, Europäer halt: wir vermarkten nicht jeden Pups als wundervoll. Dabei mag ich Scrum. Hassen tue ich die Evangelisten, die olle Kamellen über den Klee loben und sich wundern, warum die Entscheider auf ihren Etagen immer noch so zögerlich sind.

Vertriebs-Bullshit

Ich kann es ihnen nicht verdenken, ich habe selbst genug Genglishen Bullshit gehört und gelesen in den letzten Jahren, als heilige Wahrheit deklariert:

  • “Wasserfall ist total veraltet und kann gar nicht funktionieren.”, und
  • “CMMI ist überholt. Und mit Scrum hat man CMMI Level 3 ohnehin schon implementiert.”, und
  • “Klassische Planung ist deterministisch, deterministische Pläne sind nutzlos, nur agile Methoden können mit Änderungen umgehen.”, und
  • “Up-front Requirements können nicht funktionieren. Erzählt lieber eine Geschichte anstelle Anforderungen zu schreiben.”

Was schon eher stimmt

Dabei sind die Aussagen nicht völlig verkehrt, mit etwas Mühe kann man ein paar Körner Wahrheit finden. Legen wir die rosa Brille des Verkäufers ab und differenzieren wir:

  • Echte Arbeitsabläufe sind viel turbulenter als Phasenmodelle sie beschreiben; sich sklavisch an Phasen zu klammern ist daher schädlich.
  • Scrum ist kompatibel mit den CMMI-Anforderungen und erfüllt viele davon adäquat. CMMI Assessoren lösen sich langsam auch von der Faustregel, im Zweifel einfach alles zu dokumentieren.
  • Neuplanung ist seit jeher ein Teil der Planung; anscheinend haben das viele Planer verdrängt. Effizientes Änderungsmanagement ist aber essentiell für effiziente Projekte.
  • Man muss nicht alle Anforderungen kennen, um beginnen zu können, aber je früher man klare Anforderungen festhält, desto unwahrscheinlicher werden böse Überraschungen. Um Anforderungen richtig interpretieren zu können, muss man Motivation und Zielgruppe kennen.”

Oooh, das klingt jetzt nicht mehr wirklich spektakulär, dürfte aber vorstandstauglich sein.

Bedeutung von Marketing

imageAus eigener Erfahrung weiß ich: Wenn man das Marketing unterschätzt, wird Scrum für praktisch alle Probleme verantwortlich gemacht, die es gibt, inklusive der ausgegangenen Kaffeebohnen. Die wenigsten Probleme sind von dabei Scrum abhängig; schaut man genauer hin (wir haben die rosa Brille ja oben abgesetzt), kann man oft Rahmenbedingungen vorfinden, mit denen man jeden Prozess, und sei er noch so gut, hätte torpedieren können. Da werden Product Owner eingesetzt, die inhaltlich gar nicht verantwortlich waren (also keine “Schweine” im Sprachgebrauch von Scrum, wenn man mal vom Grunzen absieht), Teams mit zig parallelen Projekten überfrachtet, Wander-Stories zwischen den Sprints hin- und hergeschubst, Voraussetzungen für Stories übersehen, oder schlicht Dinge entwickelt, die keiner braucht.

Selbst wenn diese Rahmenbedingungen kommuniziert sind, bleiben Zweifel, auch bei den gutwilligsten Schlipsträgern. Scrum kommt bei ihnen nämlich nicht als sehr “agil” herüber: Wenn man die Regeln strikt handhabt,  dann könnte Vertriebsmanager McNuggets gackern wie er will – seine Abschätzung für ein Angebot bekäme er erst im nächsten Sprint. Freilich: Niemand zwingt einen, Scrum den Buchstaben nach einzuhalten. Ganz positivistisch gesehen: Wenn’s funktioniert ist’s richtig. Doch dazu ein andermal mehr.

Argumente für Führungskräfte

Wenn mich heute Entscheidungsträger zu Scrum befragen, führe ich gerne Argumente der folgenden Bauart ins Feld:

  • Scrum ist ein mit geringer Investition zu etablierender Prozess: Die Schulung ist nicht aufwändig und die bestehende Infrastruktur reicht völlig aus.
  • Scrum fördert das Arbeitsklima in der Entwicklung; dies verbessert die Attraktivität des Unternehmens auf dem Arbeitsmarkt.
  • In Scrum ist das “Mikromanagement” Aufgabe des Entwicklerteams; der Projektleiter wird dadurch entlastet und ist dennoch sehr gut informiert.

Ich habe gute Erfahrungen mit so einer Darstellung gemacht: Budgetverantwortliche denken gerne strategisch und  wirtschaftlich, und von dort muss man sie abholen. Manchmal frage ich mich, was geschähe, wenn die Evangelisten mit solchen Argumenten bewaffnet ins Feld zögen.

Hinweis zum Autor:

Dies ist der erste (und hoffentlich nicht letzte) Artikel unseres Gastautors “Ludi”. Er arbeitet aktuell für ein mittelständisches Unternehmen im Bereich Projekt- und Qualitätsmanagement. Neben seiner Tätigkeit als Product Owner (erfolgreiche Entwicklung eines neuen Produktes) zeichnet er zudem verantwortlich für die Ausgestaltung der nun unternehmensweit geltenden PM-Richtlinien, die Ansätze aus den klassischen Phasenmodellen und den agilen Methoden miteinander verbinden.

9 thoughts on “Scrum für Schlipsträger – Nachhilfe in Sachen Change Management

  1. In der Tat, hoffentlich nicht der letzte Artikel von ‘Ludi’. Sehr gern und schmunzelnd gelesen ;-)

  2. Habe ich sehr gern gelesen!
    Der alte Wein scheint wieder mal zu reifen. Früher hat auch auch von Tugenden wie Führung, Wille zur Leistung, d.i. Fleiß, Wille zu Kooperation und freudliches Miteinander gesprochen. Die Argumente für Führungskräfte stimmen in der Zielsetzung, wenn der Kümmerer ein Führer – mit etwas Charisma – wirken kann. Das muss aber auch in die firmeneigene Welt der Ent-/ Be-Lohnung passen. usw.
    “Gut dem Dinge!”

  3. Endlich ein Blog Beitrag, den ich bis zum letzten Satz gelesen habe. Danke an den Autor.

  4. Danke für diesen wirklich lesenswerten Beitrag. Insbesondere “Alter Wein in neuen Schläuchen” trifft es ziehmlich exakt. Natürlich bringt jedes “neue” Modell auch neue gute Ideen und Komponenten mit, aber vieles wird einfach unter einem neuen Namen neu verkauft. Warum muss der “Project Manager” denn bei Scrum “Product Manager” heißen. Kann man nicht z.B. einfach die Rolle des Project Managers = Product Managers bei Scrum erläutern. Aus meiner Sicht wäre das auch viel besser in die Managementeben zu vermarkten. Aber das wäre wahrscheinlich viel zu einfach und nicht so revolutionär, oder vielleicht wußten die Erfinder auch nicht was ein Project Manager alles so macht.

  5. Na ja, es gilt dann logischerweise wohl auch die Formel:

    alter Wein = neuer Wein –> alte Probleme = neue Probleme.

    Wie immer man das alles auch nennen mag, für mich ist entscheidend, dass der ganze unnütze Ballast aus Projekthandbüchern (die keiner liest) entfernt wurde. Der Komplette SCRUM Prozess mit allem Drum-und-Dran passt auf eine A4 Seite. Gut, dass kann ich mir merken!

    Jeder der glaubt mit der richtigen Methode stelle ich sicher, dass mein Projekt ein erfolg wird, hat sein wahres Problem noch gar nicht erkannt: Schlechte Entwickler, Projektleiter, Mitarbeiter, Management.

    Und, dass ist sehr schön an SCRUM, diese Probleme werden sehr schnell transparent und können dann gezielt gelöst werden.

    Den Punkt “Scrum fördert das Arbeitsklima in der Entwicklung; dies verbessert die Attraktivität des Unternehmens auf dem Arbeitsmarkt.” halte ich für sehr weit hergeholt, da spielen sicher erheblich wichtigere Faktoren eine maßgebliche Rolle.

  6. Für viele Entwickler ist Scrum ein nicht zu unterschätzendes Motiv, in die Firma zu wechseln oder in der Firma zu bleiben. Nicht das einzige Motiv, nicht für jeden Entwicklertypus, aber man darf den Einfluss nicht unterschätzen – ich war selbst überrascht, welchen Stellenwert das Argument hat.

    Je nach Persönlichkeit sind Gehalt und Karrierechancen gar nicht so entscheidend – der typische (?) Ingenieur will geachtet und gewürdigt werden aufgrund seiner Leistungen und stolz sein können auf seine oder ihre Arbeit. Firmenpolitik für den Machterhalt und die Gesichtswahrung im Angesichts des totalen Versagens ist etwas, das sie gerne den Managern überlassen. Ein “scrummendes” Unternehmen gilt als aufgeschlossen für Neues, interessiert an den Ergebnissen (Sprint Review), lässt die Experten ihre Arbeit optimal machen (Planung mit dem Team, Entscheidungsbefugnis bei technischen Fragen, Feedbackmöglichkeiten in Retrospektiven) und dämmt das unausweichliche Chaos ein (durch geschlossene Sprints und den Scrum Master).

    Wer nicht glaubt, dass diese Kriterium entscheidend ist, frage ruhig in einer Kaffeepause Teammitglieder, oder Vertreter von Human Resources, oder Entwicklungsleiter. Ich kenne relativ konservative Firmen, die zu scrummen begannen, nicht weil sie sich inhaltlich viel davon erhoffen, sondern um gute Fachleute anzulocken.

  7. Sehr guter Beitrag!

    Bin auch irgendwie skeptisch. Manchmal kommt es mir so vor, als würden die “Jünger” SCRUM deshalb hypen, weil keine klare Auftragsklärung erfolgt (warum, wäre sicherlich ein eigener thread) und sie hoffen, durch das “Scheibchenschneiden” mit SCRUM dieses Problem zumindest “zeitlich verlagern” können. Ich stimme dem Autor zu: Egal ob ich es Fachkonzept / Backlog oder Schnitzel nenne: Bevor ich sinnvoll anfangen kann, muss ich mir ernsthaft Gedanken machen, was ich will und wie viel ich dafür (prinzipiell) ausgeben will!

  8. Sehr schöner Artikel :). Man muß Vorständen Scrum eben anders erklären als Entwicklern. Allerdings erschreckt mich in einigen der vorherigen Kommentare schon das Halbwissen bezüglich Scrum. Meiner Erfahrung nach ist genau dieses Halbwissen für den teilweise schlechten Ruf von Scrum verantwortlich. Am besten ist es, Ken Schwabers Rat zu folgen und den Begriff “Scrum” gar nicht zu vermarkten. Wer wirklich nach Scrum arbeitet, kann Taten sprechen lassen – show, don’t tell.

  9. Pingback: Sky is limit » Blog Archiv » Agile Softwareprozesse mit Hilfe von Scrum – Wirklich nur altes aufgewärmt? Nein!

Comments are closed.