Home Artikel Nachrichten Heft Suche Termine

SCRUM

von Gedrängel unterm Wasserfall, Unternehmen besser machen

von Jens Pittasch, Buch

Als den Studenten und der Uni nahes Kulturmagazin gehen methodische und Fachthemen nicht an uns vorbei. Besonders dann nicht, wenn es sich ebenfalls um kulturelle handelt, unternehmenskulturelle in diesem Falle. Natürlich ist da ständig Vieles in Bewegung und wird gern Selbstverständliches in neue Schläuche gekippt, aus denen man mit der Weisheit Löffeln fressen soll.
In einigen Punkten ist das auch bei SCRUM so - erscheinen einem Erkenntnisse der Methodenentwickler weder als neu, noch als Errungenschaft - doch ist es wohl gerade daher notwendig, näher darauf einzugehen.
SCRUM - wer auch seltene Worte des Englischen kennt (oder Rugby-Fan ist), kann das möglicherweise übersetzten. Scrum steht für Gedränge. Als Methodenbegriff wurde das Wort gewählt um, eben im Vergleich mit Rugby, zu beschreiben, dass hier starke, eigenverantwortliche Teams nach wenigen, doch strengen Regeln arbeiten.
Die Redaktion wurde auf SCRUM aufmerksam gemacht, verbunden mit der Anregung, darüber zu schreiben und speziell auch einige Bücher zu vergleichen und zu empfehlen.
Bald stellte sich heraus: Das war sehr viel schneller gesagt, als getan. Denn nachdem die ersten Recherchen ergaben, dass das Thema tatsächlich interessant ist, stand - angesichts einer Materialfülle - die Herausforderung, es sinnvoll einzugrenzen.
Wir wählten den Weg der Konkretisierung auf ein Scrum-Thema, das (nicht nur) unsere uni-nahen Leser vermutlich recht gut nachvollziehen können: Die Software-Entwicklung.
Denn hat sich nicht jeder schon über die sprichwörtliche „Bananen-Software“ geärgert? Die kennen Sie nicht? - Nun, .... sie reift beim Kunden. Es sind Programme, bei denen man sich zwischen jedem zweiten Klick und jedem dritten Blick fragt, ob denn die Entwickler jemals eine ihrer Funktionen getestet haben, bei denen man nur mit dem Affengriff aus einer Endlosschleife diffuser Reaktionen oder Abstürze gerät und bei denen man vergeblich nach internen oder externen Erklärungen für vermeintlich Einfaches sucht.
Sie sagen, das trifft auf fast alle Programme zu? Da liegen sie nicht so falsch. In der Tat spricht eine Untersuchung der Standish Group davon, dass 86% herkömmlich betriebener Software-Projekte scheitern.
Denn die konventionelle Software-Entwicklung beruht auf dem Denkfehler, Programme als komplett planbare Produkte anzusehen. Und da dieser Denkfehler ursprünglich von Koryphäen begangen wurde, denen man einfach nicht widerspricht, kultivierte er sich in Form industrialisierter Methoden, manifestierter Fachgebiete und starrer Hierarchien.
Ausgehend von zunächst realen Erfolgen maximaler Top-Down-Vorausplanung unter minimalen Abweichungen griff der Taylorismus um sich - übrigens in der gesamten Industrie und Unternehmensorganisation - genannt Wissenschaftliche Betriebsführung - und wer wollte schon der Wissenschaft widersprechen. Alles galt als (voraus-)berechenbar und planbar - und gilt es in weiten Teilen der Wirtschaft (sowie Politik und Gesellschaft) weiterhin.
Obgleich hier auch andere Einflussfaktoren zu beachten sind, gelten Extreme, wie die 5-Jahr-Pläne der DDR oder ständige Arbeitsnormerhöhungen, die zum 53-er Arbeiteraufstand beitrugen, als Musterbeispiele des Scheiterns der Planbarkeit und der rücksichtslosen Rationalisierung. Dass die genannten nun ausgerechnet im angeblich menschlicheren System des Sozialismus stattfanden ist ein anderer - real existierender - Aspekt der Geschichte. - Zurück zur Software.
Hier entstand Anfang der 1990iger Jahre eine Gegenbewegung. Alles begann damit, dass Jeff Sutherland den Mut hatte, aus der Erkenntnis, dass die „Wasserfall“-Methode (abgeleitet vom Aussehen einer typischen Balkenplanung) für ein aktuelles Vorhaben nicht funktionieren würde, auch Schlussfolgerungen zu ziehen.
Er schaffte das konventionelle Projektmanagement für seine Teams ab, machte die Projektmanager zu Teambetreuern und führte eine zyklische Abfolge von Planung- und (Weiter-)Entwicklung ein. Es musste nun nicht mehr genau geplant werden, was irgendwann von wem in welcher Zeit unter Nutzung welcher Ressourcen in möglicherweise 14 Monaten getan werden würde - sondern genau geplant wurde mit einem Ausblick von wenigen Wochen und die Planung vervollständigt und verfeinert mit jedem Zyklus.
Damit das funktionieren konnte, bekamen die Entwicklungsteams zur Erledigung ihrer Arbeit weitreichende Kompetenzen übertragen, einen Störungsbeseitiger an die Seite gestellt, dazu einen, der die Vision des zu erzeugenden Produktes stets im Blick hat und während der Durchläufe die Planung vorantreibt und neue Anforderungen einarbeitet. All das bekam wenige, diszipliniert einzuhaltende Regeln und einige gut funktionierende Kontroll- und Arbeitsmittel. Ganz wie beim Rugby, wo aus Scrum = Gedränge auf kurzem Weg Erfolg wird.
An sich geht es also darum, das zu erledigen, worüber man Bescheid weiß und was man überschauen kann. Und das dann konsequent zu tun und aus Fehlern schnell zu lernen.
Klingt selbstverständlich und einfach - ist es aber nicht. Ist es vor allem deshalb nicht, da durch die kurz angerissene tayloristische Denkweise mit all ihren Wissenschaftler-Gurus die Fehllehre der Planbarkeit aller Prozesse, ja des ganzen Lebens, tief verwurzelt ist - und von ihren Vertreten mit Klauen und Zähnen verteidigt wird.
Womit wir zu den Büchern kommen.
In einem werden Klauen und Zähne ganz wörtlich genommen, um dem geneigten, jedoch geistig ja vollkommen prozessplanungsgestörten Leser Scrum nahe zu bringen. Bei Holger Koschek, „Geschichten vom Scrum“, kämpft ein Team aus Ritter, Aschenputtel, Gespenst, Großväterchen, Hexe und Prinz - im Auftrag des Königs - gegen Drachen. Es gilt eine ganz neue Generation von Drachenfallen zu bauen und so das Wieimmerland zu retten. Einfach eine Falle von vorn bis hinten zu planen und dann nach zwei Jahren einsatzbereit zu haben erwies sich gegen schlaue Drachen, die während dessen immer neue Tricks und Kniffe erfinden, um die Menschen zu ärgern, deren Felder kahl oder deren Vieh auf zu fressen, als ungeeignet. Doch der normale Drachenbau funktionierte so und normale Drachenbauer dachten so - daher dann das neue Team in der seltsamen Konstellation.
Was sich so verkürzt recht putzig liest, ist durchaus gut geschrieben und könnte als Lehridee auch Sinn ergeben, ist jedoch nach einiger Zeit einfach nur noch anstrengend.
Es braucht nun also Kraft, „Die Kraft von Scrum“ und von gleich drei Autoren: Henning Wolf, Rini van Solingen und Eelco Rustenburg. Und in der Tat, der Untertitel ihres Buches ist Programm, eine: „Inspiration zur revolutionärsten Projektmanagementmethode“.
Auch dieses Werk setzt auf eine Geschichte. Jedoch auf eine aus dem wirklichen (Arbeits-)Leben. Womit man nicht nur sofort jedes Verständnis für´s Geschehen hat, sondern nicht aufhören kann zu lesen, bis man erfahren hat, wie sich der Chef dieser Entwicklungsfirma aus der Affäre gezogen hat, in die er gerade - nicht zum ersten Mal - beim Kundentermin geraten war. An der Hotelbar nach verpasstem Flieger beginnt seine Begegnung mit Scrum. Eine Begegnung die - soviel sei vorweggenommen - dazu führt, dass es keine Kundentermine dieser schlimmen Art mehr geben wird. Denn Manager Mark trifft auf Scrum-Coach Stefan, starres Vorgehen trifft auf agile Methode - und Schritt für Schritt ändert sich alles in Marks Firma. Dieser Weg zum erfolgreichen Umbau nicht nur der Entwicklung, sondern der Unternehmenskultur wird in dieser Erzählung selbst in einer Art Scrum gezeigt. Jeder Handlungsstrang ist ein eigener Zyklus mit Essenz und Ausblick. Und so macht das Buch durch Inhalt und durch Aufbau Scrum beim Lesen erlebbar.
Unser Tipp als Einstiegswerk!
Sehr gut zu untersetzen im Anschluss mit einem Lehrbuch der Erfinder von Scrum - Jeff Sutherland und Ken Schwaber: „Software in 30 Tagen“. Übersetzt übrigens von Stefan Roock, selbst langjähriger Scrum-Verfechter und Scrum-Berater. Vielleicht der Stefan aus der Hotelbar?
„Software in 30 Tagen“ ist eines einer ganzen Zahl von Büchern, die Sutherland und Schwaber über Scrum geschrieben haben. Interessant an diesem jedoch ist - dem Titel etwas zuwiderlaufend, dass es sich an Menschen richtet, die nicht selbst Software entwickeln. Ideal ist das Buch für diejenigen, die in Unternehmen Verantwortung tragen - und auf funktionierende und bedarfsgerechte Software angewiesen sind, um ihre Betriebe lebensfähig zu halten. Und es gibt kaum noch ein Unternehmen und wohl auch sonst kaum eine Organisation oder Verwaltung, auf die das nicht zutrifft.
Es geht nicht nur um den ROI, wenngleich bereits Scrum selbst nachweisbar bis zu zehnmal produktiver ist, als herkömmliche Methoden. Davon abgesehen einmal, dass (siehe oben) 86% ganz erfolglos bleiben. Doch Erfolg definiert sich nicht nur in Kennzahlen, beziehungsweise können gute Zahlen dauerhaft nur dort entstehen, wo die Motivation stimmt. Und Scrum führt zu Motivation, führt zur Freude an der Arbeit, führt zum Gerne-noch-besser-Werden, zum Erfolgserlebnis - und zum Unternehmenserfolg.
„Software in 30 Tagen“ liefert nicht nur eine an deutlichen Beispielen hergeleitete Begründung für Scrum und fundierte Einblicke in die Methode, sondern vermittelt Wissen, um tatsächlich damit starten zu können. Eingegangen wird auf alle wichtigen Ebenen, auf die Anliegen alle denkbaren Beteiligten, immer wieder wird das Vorgehen durch Erlebnisse aus realen Unternehmenssituationen illustriert - und all das ist überhaupt nicht fachbüchlich trocken oder abstrakt geschrieben, sondern sehr nah am Menschen - um den es ja eigentlich auch geht. Eine sehr gute Zusammenfassung hilft beim späteren direkten Finden von Kernaussagen und - als i-Punkt - gibt es Spielzüge für die Einführung von Scrum-Prinzipien im gesamten Unternehmen.
Was dann zugleich der Punkt ist, an dem man noch mehr wissen will, denn Spielzüge sind noch nicht das Spiel und das Spiel ist zunächst ergebnisoffen. Damit ein Sieg näher rückt, ist das vierte Buch empfohlen.
Ken Schwaber selbst schrieb das Geleitwort zu „Scrum“ von Boris Gloger. Und da zu diesem Buch das eBook mitgeliefert wird, ist es auch leicht, hier eine seiner Aussagen einzufügen: „Unternehmen, die versuchen, Scrum einzusetzen, ohne sich zu verändern, sich intelligent zu analysieren und sich anzupassen, stehen schlechter da als zuvor. Die Produktqualität sinkt schneller. Der „Death March“ am Ende herkömmlicher Projekte wird ein „Death March“, der in jeder Iteration auftritt.“ - eben damit es dazu nicht kommt, gibt es dieses Werk.
Es ist die umfassendste Wissenssammlung der betrachteten vier Bücher und in dieser Form einerseits unverzichtbar, andererseits auch alleinstehend als vollständig zu betrachten. Wobei klar ist, dass es „vollständig“ beim Wissen und im Leben nicht gibt - und bei Scrum als agiler, eben lebendiger, Methode, schon garnicht. Die besten Worte, um zu erklären, was anders wird durch das Lesen und die spätere Beachtung dieses Buches, findet Boris Gloger selbst: „Ich sehe jeden Tag, wie intelligente und gut ausgebildete Menschen zur Arbeit gehen und an ihrer Arbeit keine Freude mehr empfinden. ... Ich sehe Menschen, die ihr Leben im privaten Alltag meistern. Aber wenn sie morgens in ihre Firma gehen, werden sie dort zu ängstlichen Wesen. Menschen, die genau wissen, was sie können, trauen sich nicht, ihren Chefs zu sagen, dass die Anweisungen, die sie erhalten, sinnlos und unproduktiv sind. ... Ich sehe Chefs .. resignieren, weil ihre Mitarbeiter nicht motiviert sind, nicht tun, was getan werden müsste, und abends lieber fluchtartig nach Hause gehen, als fünf Minuten länger in der Firma zu sitzen. Das Resultat sind Chefs, die in ihrer Verzweiflung beginnen, Kontrollmechanismen aufzubauen, die die begonnene „Abwärtsspirale“ verstärken. - Das machte mich unzufrieden, und ich wollte das ändern.“
Was Boris Gloger fand, um das zu ändern, war Scrum. Kein Allheilmittel, keinen Zaubertrank, keine Hexerei - nicht einmal lieferte Scrum sofort Antworten auf alle Fragen: Doch Scrum erwies sich als die Methode, um diese Antworten selbst zu finden.
Gloger schreibt dabei nicht einfach von anderen ab, er verdichtet das Wissen sehr vieler anderer und aus sehr vielen eigenen Projekten. Besonders die nun vorliegende vierte Auflage des Buches bietet eine Sicht aus zehn Jahren Scrum-Praxis. Mit diesem Werk kann man wirklich starten, man möchte es derart motiviert auch tun. Und beim Start hilfreich ist dann die Agilität der virtuellen Welt - im Boris-Gloger-Blog: www.borisgloger.com/blog.


Boris Gloger
Scrum - Produkte zuverlässig und schnell entwickeln
Carl Hanser Verlag - ISBN: 978-3-446-43338-0

Henning Wolf / Rini Van Solingen / Eelco Rustenburg
Die Kraft von Scrum
dpunkt.verlag - ISBN: 978-3-86490-164-5

Holger Koschek
Geschichten vom Scrum
dpunkt.verlag - ISBN: 978-3-86490-140-9

Ken Schwaber / Jeff Sutherland
Software in 30 Tagen
dpunkt.verlag - ISBN: 978-3-86490-074-7
home - artikel - heftarchiv - nachrichten - impressum - datenschutz
folge uns: Facebook - Twitter
Blicklicht, www.kultur-cottbus.de © 2018 Blattwerk e.V. Cottbus