SCRUM: Die Crux der Agilität

Schon im letzten Beitrag ging es zu einem Teil um unsere agile Arbeitsweise mit SCRUM. Da diese bei uns sowohl die kulturelle als auch technische Basis bildet und somit sowohl in der Team- als auch in der Software-DNA fest verankert ist, widme ich dem heutigen Blogeintrag eben jenem von uns so umfassend gelebten Vorgehensmodell und versuche die Gründe darzulegen, warum wir uns dafür entschieden haben.

Um in einem Satz den Sinn und Zweck von SCRUM zu umschreiben, kann ich es nicht besser als in Wikipedia beschrieben, ausdrücken:

„Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um durchgängig planvoll umgesetzt zu werden, und auf der Erkenntnis, dass allein ständig verfügbares Feedback den Erfolg sichert. Damit wird vermieden, die anfänglich gegebene Komplexität durch einen komplexeren Plan zu steigern.“

Soweit zur Theorie. Doch was veranlasste uns als langjährige Entwicklungsprofis von komplexen Projekten in komplexen Umfeldern auf ein solches System umzuschwenken? Einem rein agilen Vorgehensmodell im scheinbar vollkommenen Gegensatz zu den Wünschen und Forderungen unserer Kunden nach festen Milestones und dokumentierten Leistungsbeschreibungen? Nun, ich habe es einmal als Analogie versucht dem Kunden zu vermitteln:

Stellen Sie sich vor, sie haben ein schönes Haus im Rohbau und es geht um die Ausgestaltung der einzelnen Räume. Betroffen sind alle Gewerke: Vom Fenster, Farbe, Fußbodenleisten bis hin zum Fernseher. Im Wasserfallmodell würden man für alles Festlegungen treffen – sich am Anfang ärgern, weil die Spezifikationen so lange dauern durch Einbezug aller Gewerke und  sich möglicherweise nach Bauübergabe noch einmal ärgern. Vielleicht darüber, dass die Fußbodenleistenfarbe nicht mit den Gardinen harmoniert – und weder der Fußbodenleger noch der Innendekorateur dafür aufkommen will.

So viel Theorie, die für all die Pflichten- und Lastenhefte aufgewendet werden muss, macht darüber hinaus nicht wirklich Spaß und sie ist alles andere als real produktiv. Denn in dieser Zeit hätte man schon einige Räume fertig einrichten können. Und genau das macht SCRUM. Für einen Raum werden Anforderungen definiert – jedoch nicht als Manifest auf Basis von Anforderungslisten, sondern als nicht technikorientierte User Stories mit klaren Funktionalitäten. In dieser kann durchaus enthalten sein, dass eben die verwendeten Farben aufeinander abgestimmt werden müssen. Den Kunden freuts spätestens, wenn er in eben jenem Raum steht und nicht nur kleine Details ändern kann, welche dann in die weiteren Räume als “Standardvorgehen” übersetzt werden kann. Er freut sich weiterhin, weil er einen fertigen, im Zweifel sogar schon bewohnbaren Raum nutzen kann.

Doch jetzt denken Sie mal an die Handwerker, die mit diesem Vorgehen ganz andere Dinge können und tun müssen – durchaus ein Graus, insbesondere für einen rational denkenden 0/1-Menschen, wovon doch eine nicht ganz unerhebliche Schicht in den Weiten der Entwicklung unterwegs sind. Womit wir bei Herausforderung No 2 wären.

SCRUM hat viele Vorteile, die im ersten Augenblick für einen langjährigen Mitarbeiter sich manchmal wie Nachteile anfühlen werden:

  • Selbstorganisiertes Arbeiten
  • Eigenverantwortung
  • ein hoher Entscheidungsrahmen
  • absolute Transparenz
  • erzwungene Wissensweitergabe

Schlagworte, die eher in Einstellungsgesprächen fallen. Unser Team bestand bereits seit Jahren und war mit der Arbeit nach dem Wassefallodell vertraut. Und dennoch dauerte es nur wenige Gespräche lang, bis die Begeisterung für das agile Vorgehen bei fast allen Mitarbeitern geweckt war. Schließlich locken eben jene Begriffe sehr und stehen im klaren Gegensatz zur meist ungeliebten “Programmierung nach Plan”. Wir hielten uns am Anfang recht strikt an die Vorgaben von Ken Schwaber, da das Vorgehen für uns absolutes Neuland war. Eine Zertifizierung als Product Owner bei Boris Gloger als Vorbereitung halfen den Veränderungsprozess einzuleiten, erste Fragen auch seitens der Geschäftsführung oder des Kunden zu beantworten und erste (Team-)Strukturen aufzubauen.

Und seitdem ist viel passiert: Wir haben unser eigenes SCRUM entwickelt, welches sich weiterhin recht streng an die Vorgaben hält. Weil wir es so wollen. Wir haben unser Ticketingsystem abgeschafft, weil es nicht unserem Wunsch nach Auswertung unserer Leistungsfähigkeit nachkam und haben Jira installiert, welches die Transparenz zulässt, die unser tägliches Brot geworden ist  (probieren sie das mal von oben durchzusetzen! Pest und Mordio wird ihnen gewünscht!). Wir sind eine Demokratie mit einem Monarchen: dem (zahlenden) König. Der es sehr häufig noch immer nicht fassen kann, dass er viele Softwarefeatures innerhalb von zwei Wochen bekommen kann – genauso lang dauert bei uns eine Entwicklungseinheit. Früher wären das locker zwei bis vier Monate gewesen.

Und genau die letzten Sätze sind unser Totschlagargument für neue SocialCom-Kunden. Selbst wenn sie nicht einmal Fußleisten bekommen, sondern “nur” absolut auf ihre Bedürfnisse anpassbare Software – und zwar auf Dauer.

Meine Empfehlung für einen ersten Blick auf die Thematik – ein (überschaubares) und gut lesbares eBook von den HR pioneers.

Nie wieder einen Blogartikel verpassen >>> Zum Blog-Newsletter anmelden

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

fünf − 2 =