Impressum
Bibliografische Information der Deutschen Nationalbibliothek:
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über www.dnb.de abrufbar.
© 2021 Paul C. Müller
Herstellung und Verlag: BoD – Books on Demand GmbH, Norderstedt
ISBN: 978-3-7526-5447-9
Scaled Professional ScrumTM (SPS) ist wie auch die weiteren im Buch genannten Scrum-Zertifizierungen Eigentum der Scrum.org. Das vorliegende Buch ist ohne Einflussnahme oder Auftrag der Scrum.org als Ausdruck der eigenen Auseinandersetzung des Autors mit den dargestellten Themen entstanden. Der einfacheren Lesbarkeit halber wurde im Text auf die Auszeichnung von Marken und Warenzeichen verzichtet. Diese sind aber jeweils mit gemeint und sollen so verstanden werden.
Grundsätzlich ist es sinnvoll, dass der Leser sich vor der Lektüre dieses Buches mit Scrum auseinandergesetzt hat. Dies muss nicht zwingend im Rahmen einer Zertifizierung sein; wer allerdings eine Scrum.org SBS-Zertifizierung anstrebt, dem sei eine vorgängige Ausbildung und Zertifizierung auf Ebene Product Owner oder Scrum-Master der Scrum.org ans Herz gelegt. Für all jene, welche diese Kenntnisse nicht besitzen, habe ich mich entschlossen, im Sinne eines Bonus das Kapitel “Das Scrum-Framework verstehen und anwenden” aus meinem Buch zum Agilen Leadership einzubinden.
Das bereits vorgelegte Buch wurde im Dezember 2020 basierend auf der Scrum Guide der Version 2020 (November 2020 erschienen) durchgesehen und wo notwendig angepasst.
Anmerkungen: Auch wenn die deutsche Übersetzung der Scrum-Guide die Rollen inzwischen mit Product Owner:innen etc. bezeichnet behalte ich der besseren Lesbarkeit die männliche Form bei.
Ich erlebe immer wieder Firmen, welche mit Scrum ganz erfolgreich Produktentwicklung betrieben haben und dann beim nächsten Schritt, der Skalierung von Scrum – also der Umsetzung von mehreren Entwicklungsteams, welche am selben Produkt arbeiten – kläglich scheitern.
Wenn mir solche Firmen ihr Leid klagen, stelle ich eigentlich fast immer fest, dass diese Firmen zwar irgendwann einmal entweder erfahrene Scrum-Master eingestellt oder eigene Leute zu Scrum-Mastern weitergebildet haben und Entsprechendes auch im Zusammenhang mit ihren Product Ownern getan haben1, dass aber keiner auf die Idee gekommen zu sein scheint, sich mit der Frage auseinanderzusetzen, wie denn die ganze Zusammenarbeit im Kontext einer skalierten Umgebung zu leisten sei.
Skaliertes Scrum ist, anders als viele dieser Firmen wohl meinen, nicht einfach eine Art von aufgeblasenem Scrum. Es ergibt sich durch die Veränderung des Settings ein erheblicher Komplexitätszuwachs.
Einerseits im Hinblick auf die Abhängigkeiten zwischen den Teams, andererseits auch im Hinblick auf Kommunikation und Abstimmung. Das gilt es zu organisieren. Dazu haben verschiedene Scrum-Fachleute Frameworks entwickelt, welche Themen wie Prozessanpassungen, Rollen, Events, Artefakte darstellen. Einer davon war Ken Schwaber, einer der Väter von Scrum, der mit dem Nexus-Guide eine Erweiterung zu Scrum geschaffen hat. Daneben gibt es etliche weitere und es ist natürlich nicht zwingend notwendig, eines der genannten Frameworks umzusetzen, um erfolgreich skalieren zu können. Was aber immer eine Voraussetzung für den Erfolg einer Skalierung ist, ist eine von den Werten von Scrum getragene Festlegung der genannten Aspekte und Interaktionen. Dies kann im Rahmen eines agilen Weiterentwicklungsprozesses basierend auf Transparenzüberprüfung und Anpassung geschehen, man kann dazu aber auch ein bestehendes Framework wie Nexus nehmen und das eigene Vorgehen entsprechend anpassen.
Das vorliegende Buch ist für Menschen geschrieben, welche gern basierend auf einem bestehenden, bei etlichen Firmen bewährten Framework arbeiten und sich einen Überblick über Nexus verschaffen möchten. Als Zusatznutzen ist das Buch so geschrieben, dass es auch für die Vorbereitung auf eine Scrum.org Scaled Scrum Professional-Zertifizierungsprüfung genutzt werden kann. Ich habe mich bemüht, das dafür benötigte Wissen auf den Punkt darzustellen, um damit eine effiziente Prüfungsvorbereitung zu ermöglichen.
Wenn Sie dann die Prüfung bestanden haben, dann haben Sie sozusagen den Führerschein für Nexus bekommen. Bitte verwechseln Sie das nicht mit der Zulassung als Formel-1-Fahrer. Bis dahin werden Sie (wie immer, wenn es um Wissen geht) noch jede Menge anwenden und Erfahrungen sammeln müssen. Hoffentlich haben Sie dabei einen erfahrenen Mentor oder Coach, der Sie bei diesem Prozess unterstützt.
Ich wünsche Ihnen bei Ihrer Auseinandersetzung mit Nexus viele interessante Erkenntnisse und – falls Sie zur Zertifizierungsprüfung antreten sollten – viel Erfolg!
Der Autor
1 es wird mir immer ein Rätsel bleiben, warum ausgerechnet die Menschen, die während der Sprints Scrum umsetzen sollen, in den allerwenigsten Fällen eine entsprechende, rollenbasierte Ausbildung erhalten haben. So gibt es alleine beim Zertifizierer Scrum.org aktuell (7/2020) über 320 000 zertifizierte Scrum-Master und über 70 000 zertifizierte Product Owner, aber nur gerade etwas über 11 000 Entwickler – und das in einer Situation, wo es in jedem einzelnen Team mehr Entwickler als Product Owner oder Scrum-Master gibt, welche Scrum betreiben und Produkte umsetzen.
Bevor wir uns mit der Frage beschäftigen, was Scrum ist und was agile Führung im Kontext von Scrum bedeutet, scheint es wichtig zu sein, sich zunächst damit auseinanderzusetzen, was Agilität eigentlich bedeutet. Welche Ideen stehen dahinter und welchen Nutzen soll uns Agilität bringen? Um das zu erkunden, ist es sinnvoll, sich zunächst mit dem agilen Manifest, sozusagen der Verfassung der Agilität, auseinanderzusetzen:
Im Februar 2001 trafen sich in den Wasatch-Bergen des amerikanischen Bundesstaates Utah in einer Ski-Lodge siebzehn Menschen, um gemeinsam zu reden, Ski zu fahren und zu entspannen. Sie alle waren mit der Art und Weise, wie Software-Entwicklung stattfand, nicht zufrieden und glaubten, dass Alternativen zu dokumentationsträchtigen, schwergewichtigen Software-Entwicklungsprozessen notwendig seien.
Diese Gruppe organisatorischer Anarchisten, die sich «The Agile Alliance» nannten, formulierten und unterschrieben gemeinsam das «Agile Manifest». Dabei ist zu beachten, dass die anwesenden Personen später ganz unterschiedliche Wege gegangen sind und unterschiedliche Methoden und Frameworks basierend auf der gemeinsamen Grundlage «Agiles Manifest» entwickelt haben. (Mit-) Entwickler von «Extreme Programming», «Scrum», «DSDM», «Adaptive Software Development», «Crystal» und anderen legten hier einen gemeinsamen Grundstein für die weitere Entwicklung von Software-Entwicklung und in vielen Fällen auch für weit über die Software-Entwicklung hinausgehende Fragestellungen.
Weitere Informationen zur Entstehungsgeschichte finden Sie unter: http://agilemanifesto.org/history.html
Manifest für agile Softwareentwicklung
„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“
In kurzen Worten beschreibt das Manifest damit die Grundlagen agilen Denkens.
Individuen und Interaktionen mehr als Prozesse und Werkzeuge