Czytaj książkę: «Scrum? Frag doch einfach!»

Fabian Kaiser / Arie van Bennekum

Scrum? Frag doch einfach!

Klare Antworten aus erster Hand

UVK Verlag · München

Fabian Kaiser ist Co-Gründer und Inhaber der Agile Heroes GmbH, einer der führenden Beratungen zum Thema Agiles Projektmanagement. Er ist Verfasser mehrerer Fachbücher zum Thema Agilität und Projektmanagement.

Arie van Bennekum ist einer der 17 Co-Autoren des Agilen Manifests. Er hat 1994 begonnen, auf die „sogenannte Agile Art und Weise“ zu arbeiten und ist seitdem nie wieder in alte Gewohnheiten zurückgefallen. Im Laufe der Jahre hat er sich zu einem Experten für Agile Transformationen entwickelt und ist bekannt für seine kraftvollen Vorträge auf Konferenzen, für Führungsteams und während (agilen) Transformationen.

© UVK Verlag 2021

‒ ein Unternehmen der Narr Francke Attempto Verlag GmbH + Co. KG

Dischingerweg 5 · D-72070 Tübingen

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Internet: www.narr.de

eMail: info@narr.de

Einbandgestaltung: Atelier Reichert, Stuttgart

Umschlagabbildung und Kapiteleinstiegsseiten: © bgblue – iStock

Autorenfoto: privat

ISBN 978-3-8252-5522-0 (Print)

ISBN 978-3-8463-5522-0 (ePub)

Inhalt

  Vorworte

  Was die verwendeten Symbole bedeuten

  Zahlen und Fakten zur Demokratie

  Scrum ist in aller Munde Für was steht der Begriff Scrum? Hat Scrum eine Geschichte? Wenn Scrum agil ist, was ist Agilität? Wieso wird Agilität aktuell gehypet? Ist Scrum so beliebt, weil Agilität gehypet ist? Wo wird Scrum eingesetzt? Ist Scrum überhaupt überall anzuwenden? Wer ist der Kunde und was ist das Produkt? Ersetzt Scrum das klassische Projektmanagement? Was versteht man unter dem Cynefin-Framework? Wie findet die Entscheidung für die richtige Vorgehensweise konkret statt? Heißt das, dass es bei Scrum keine Hierarchien gibt?

  Aufbau und Funktionsweise von Scrum Was sind die wesentlichen Bestandteile von Scrum? Wie funktioniert der Scrum-Prozess Welche Teammitglieder bzw. Verantwortlichkeiten gibt es in Scrum? Was ist ein Scrum Master? Wie finde ich einen Scrum Master? Können wir diese Lösungsmöglichkeiten detaillierter anschauen? Können wir gerade die Vorteile einer externen Besetzung detaillierter betrachten? Kann man hieraus eine einfache Entscheidungsregel ableiten? Was ist ein Product Owner? Wie finde ich einen Product Owner? Sind also externe Product Owner die beste Option? Was macht das Entwicklungsteam? Wie finde ich die perfekten Entwickler? Auch wenn diese Entscheidungshilfe nicht nur Scrum-Beteiligte betrifft; welche Überlegungen stecken hinter diesen Personalauswahlkriterien? Was bin ich, wenn man Projektmanager war? Welche Werte gibt es in Scrum? Welche Funktion haben Events in Scrum? Wer trägt die Verantwortung für die Timebox? Sind Meetings ein originärer Bestandteil von Scrum? Was ist ein Sprint? Wie lange dauert ein Sprint tatsächlich? Kann ein Sprint geändert oder angepasst werden? Was ist ein Sprint Planning? Wie lange darf ein Sprint Planning dauern? Was ist ein Daily Scrum? Ist das Daily Scrum sehr wichtig für die Praxis? Hat Daily Scrum etwas mit Daily Standup zu tun? Muss man sich beim Daily Scrum an einem Ort physisch treffen? Was ist ein Sprint Review? Warum ist das Sprint Review gerade in einem dynamischen Umfeld so wichtig? Gibt es auch für das Sprint Review eine Zeitvorgabe? War trägt die Verantwortung für das Sprint Review? Was ist eine Sprint Retrospektive? Wird Sprint Retrospektive nicht auch kritisch gesehen? Was ist das eigentliche Ziel der Sprint Retrospektive? Gibt es ein anschauliches Beispiel für eine praxistaugliche Retrospektive? Was ist ein Refinement? Wer ist für den Ablauf des Refinement verantwortlich und was ist sein Ziel? Welche Artefakte gibt es? Was sind die zu den Artefakten entsprechenden Commitments? Was versteht man unter einem Product Backlog genau? Was ist ein Sprint Backlog? Wann im Scrum-Prozess wird das Sprint Backlog von den Beteiligten eingesehen? Wer ist für das Sprint Backlog verantwortlich? Was ist ein Inkrement? Was ist ein Commitment? Was ist ein Product Goal? Welche Tools finden in Scrum Anwendung? Was macht Jira im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus? Was macht Confluence im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus? Wie funktioniert Confluence und was sind die Vorteile dieser Anwendung? Für wen eignet sich Confluence am besten? Was macht Miro im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus? Für wen eignet sich Miro? Was macht Scrumpanion im Hinblick auf die Nützlichkeit der Scrum-Anwendung aus?

  Die Praxisumsetzung von Scrum Kann Scrum auch teilweise in der Praxis umgesetzt werden? Was ist ein Sprint Goal? Was ist eine Definition of Done? Was ist eine Definition of Ready? Hat Scrum Grenzen in der Praxis? Gibt es dafür ein Beispiel? Wann funktioniert Scrum in der Praxis? Wie kommt man an die richtigen Mitarbeiter für Scrum-Projekte?

  Anerkennung des Scrum-Know-hows Gibt es vergleichbare Aus- und Weiterbildungen? Welche Zertifizierungsinstitute gibt es für Scrum? Welche Zertifizierungen gibt es? Wie kann ich mich auf die Zertifizierung vorbereiten? Habe ich als Leser dieses Buches einen Vorteil? Welche Fragen kommen in einer Scrum Muster-Prüfung auf mich zu? Wie lauten die Lösungen auf diese Prüfungsfragen?

  Glossar

  Register

Vorworte

„Survival of the fittest“ – Ein Ausdruck, der in der Evolutionstheorie beschreibt, was passiert, wenn man nicht anpassungsfähig war. Heute beschreiben wir dies als agil. Und gerade das Jahr 2020 zeigt sehr eindrucksvoll, wie anpassungsfähig und agile Menschen und Unternehmen sein müssen und auch sein können. Auch dieses Buch entstand während der Coronakrise. Einer Krise, die uns wirtschaftlich und psychisch vor völlig neue Herausforderungen gestellt hat. Auf einmal tragen wir alle eine Maske. Unternehmen, die vorher völlig analog arbeiteten, müssen plötzlich sich und ihre Geschäftsmodelle völlig neu denken. Andererseits erleben Unternehmen wie Amazon und Zoom, die früher schon digital waren, einen wahrlichen Boom.

Fernab dem gesundheitlichen Aspekt dieser Krise, zeigt sie auf sehr eindrucksvolle Weise, dass das Evolutionsgesetz „Survival of the fittest“ auch in unserem Wirtschaftssystem weiterhin Gültigkeit besitzt.

Aus diesem Grund wird das Thema Agilität für jedes Unternehmen und jeden Menschen noch wichtiger als bislang. Die Herausforderung ist größer als dass „nur“ eine digitale Disruption zu bewältigen gilt.

Einer der elementarsten Bestandteile von Agilität ist das Prozessrahmenwerk Scrum. Eine Möglichkeit mit einer Auswahl an Prozessen und Techniken, auf schlanke Weise Produkte zu entwickeln und kontinuierlich weiterzuentwickeln.

Wer sich heute im Jahre 2021 betroffen von aufstrebenden Tech-Startups oder Corona bedingten Veränderungen sieht, der kommt an den Themen Agilität und Scrum – und damit an diesem Buch – nicht vorbei.

Fabian Kaiser

Frankfurt, im Juli 2021

Agile ist nicht länger ein Trend, Agile ist der Standard. Gleichzeitig ist Agile immer noch voller Legenden, Mythen, offen für viele Interpretationen und oft haben die Menschen Schwierigkeiten, die Vorteile von Agile wirklich zu verstehen. Um ein tieferes Verständnis für das WARUM von Agilität und einer (beliebigen) Agile-Methode zu bekommen, ist es hilfreich, gemeinsam mit den jenigen, mit denen man später zusammenarbeitet, sich am Anfang zu alignen und zu besprechen, wie die agile Transformation ablaufen soll.

Diesem Zweck dient dieses Buch. Fabian und ich haben gemeinsam Antworten gefunden, die Ihnen und Ihrem Team weiterhelfen. Der Blickwinkel, der dafür gewählt wurde, war einfach, indem wir sehr prominente Fragen auswählten und uns gemeinsam darauf stürzten. Das Endergebnis ist dieses praktische Buch, das Ihnen als Leser eine wichtige Agile Methode, Scrum näher bringt.

Lesen Sie es zu Ihrem Nutzen und wenn Sie den Nutzen sehen, teilen Sie die Antworten dieses Buches mit den Menschen um Sie herum, mit genau dem gleichen Zweck, sich gegenseitig voran zu bringen.

Arie van Bennekum

Hardinxveld-Giessendam, im Juli 2021

Was die verwendeten Symbole bedeuten

		Toni verrät dir spannende Literaturtipps, YouTube-Seiten und Blogs im World Wide Web.
		Die Glühbirne zeigt eine Schlüsselfrage an. Das ist eine der Fragen zum Thema, deren Antwort du unbedingt lesen solltest.
		Die Lupe weist dich auf eine Expertenfrage hin. Hier geht die Antwort ziemlich in die Tiefe. Sie richtet sich an alle, die es ganz genau wissen wollen.
→		Wichtige Begriffe sind mit einem Pfeil gekennzeichnet und werden im Glossar erklärt.

Scrum ist in aller Munde

Dieses einführende Kapitel beschreibt die Ursachen der Popularität von Scrum und vergleicht es mit dem klassischen Projektmanagement.

Für was steht der Begriff Scrum?

Der Begriff „Scrum“ ist keine Abkürzung. Vielmehr ist Scrum metaphorisch zu sehen. Denn die Begrifflichkeit findet man neben dem hier gemeinten Prozessrahmenwerk auch im Rugby Sport. Hierbei beschreibt Scrum den Spielzug, bei dem alle Spieler auf einem dichtgedrängt stehen und durch eine Teamleistung versuchen den Ball zu ergattern.

Abb. 1

In der Metapher gesprochen ist hiermit gemeint, dass nur durch eine enge Teamleistung ein Ziel erreicht werden kann. Scrum, als Begriff beschreibt damit sehr eindrucksvoll die Grundhaltung hinter dem Scrum-Framework.

Videotipp:

Ein Beispiel für den Rugby-Spielzug:

► https://youtu.be/VIfD0nuocVo

Hat Scrum eine Geschichte?

Und was für eine! Die beiden Erfinder von Scrum, Ken SchwagerKen Schwager und Jeff SutherlandJeff Sutherland, haben Scrum zum ersten Mal auf einer Software-Konferenz im Jahre 1995 in der heutigen Form vorgestellt. Das Besondere war, dass sie Scrum in einigen Jahren davor schon in Projekten angewendet haben und damit kontinuierlich verbessern konnten. Ihre Erfahrungen haben die beiden in einem offiziellen Dokument, dem →Scrum-Guide zusammengefasst.

Gestartet im Bereich der Software-Entwicklung schauen wir heute auf 90.000.000 Menschen, die Scrum kennen und anwenden – auch außerhalb der IT. Heute, gute 25 Jahre nach offizieller Bekanntmachung, erlebt Scrum einen echten Mainstream-Hype.

Abb. 2

Einerseits ist die Übertragbarkeit von Scrum auf andere Anwendungsbereiche ein Vorteil. Andererseits birgt es jedoch das Risiko, dass Scrum als Lösung für alles angesehen werden könnte, womit eine Enttäuschung vorprogrammiert ist.

Abb. 3

Umso wichtiger ist, die Beliebigkeit der Anwendung von Scrum entgegenzuwirken, um diese Methode weitere 25 Jahre in die richtige Richtung weiterzuentwickeln.

Videotipp:

Ein Interview mit Jeff Sutherland:

► https://youtu.be/P_6Orv3R9Mg

Wenn Scrum agil ist, was ist Agilität?

Scrum ist ein nicht zu verkennender Teilbereich der Agilität. Man kann sagen, Scrum ist agil, aber Agile (Agilität) ist nicht Scrum. Scrum ist demnach ein agiles Prozessmodell innerhalb der Welt der Agilität. Und genau diese Welt ist es, die aktuell die berufliche Welt so sehr verändert. Jeder möchte agil sein bzw. jedes Unternehmen möchte agil sein.

Abb. 4

Aber was genau bedeutet Agile im wirtschaftlichen Kontext wirklich? Ist es das neue krawattenlose Büro-Erscheinungsbild? Ist es das Duzen, das von der Vorstandsebene bis zu den Mitarbeiterinnen und Mitarbeitern durchgereicht wird? Ist es das, morgendliche Kurzmeeting, welches auf einmal im Stehen abgehalten wird? Vielleicht auch.

Vielleicht sind das aber auch nur die Rand-Erscheinungen oder sichtbaren Symptome einer neuen, modernen Arbeitswelt, die zum Teil durch Agilität entstanden sind.

Agilität bedeutet aber weitaus mehr. Es bedeutet einen Mindset-Change des gesamten Unternehmens. Auf allen Hierarchieebenen. Ein Mindset-Change, der nicht nur das oben beschriebene Offensichtliche meint, sondern das Vertrauen durch Transparenz schafft. Ein Mindset-Change, der Selbstorganisation fördert und Talente zu kreativen Umsetzern macht. Ein Mindset-Change, der schnell entlang der Bedürfnisse einen Mehrwert für das wichtigste eines jeden Unternehmen stiftet: den Kunden. Ein Mindset-Change, der es schafft, eine offene und wertschätzende Fehlerkultur in den Unternehmensalltag zu bringen.

Erst wenn diese Meta-Ebene in einer Organisation erkannt und verstanden und akzeptiert wird, dann wird Agilität gelebt. Und erst, wenn man es schafft, Agilität so zu leben, dass man es nicht mehr Agilität nennen muss, dann kann man als Unternehmen nicht mehr scheitern.

Oft werden in diesem Zusammenhang Erfolgsbeispiele wie Google, Tesla oder Amazon genannt. Diese Unternehmen sprechen aber nie wirklich davon, dass sie jetzt agil sind. Sie leben einfach damit.

Videotipp:

Hier erklärt der Autor in weniger als fünf Minuten Agilität:

► https://youtu.be/DAV5xGAVexw

Wieso wird Agilität aktuell gehypet?

Die Antwort hierauf verbirgt sich im letzten Absatz der vorangegangenen Antwort. Jeder möchte aktuell so werden, wie die oben genannten und vor allem am Aktienmarkt so beliebten Tech-Leader aus den USA. Aber so weit muss man noch nicht einmal fliegen, um Referenzunternehmen zu finden: Man kann sie auch in Marktnischen in Deutschland entdecken. Denn hier stellen etablierte, konventionelle Unternehmen fest, wie schnell und unvorhergesehen ein konkurrierendes, vielleicht sogar junges Startup-Unternehmen, einem doch den Rang ablaufen kann. Gute Beispiele sind hierfür:

 FreenowFreenow (früher MyTaxiMyTaxi), die mit einer App den gesamten Taximarkt innerhalb von fünf Jahren verändert haben.

 FlixbusFlixbus, eine günstige Plattform für Fernbusse, die nicht nur die Deutsche Bahn unter Druck setzen, sondern auch jeden privaten Busunternehmer in Deutschland dazu bringt sein Geschäftsmodell ohne Plattformteilnahme ernsthaft zu hinterfragen.

 N26N26, die als Mobil-Bank aktuell jeden Tag 10.000 neue Kunden gewinnt und bei diesem Wachstum DAX notierte Banken in den nächsten zwei Jahren kundenseitig überholen wird

Auch diese Unternehmen brauchen keine Weiterbildung darüber, wie Agilität funktioniert. Sie sind der Inbegriff dessen. Außerdem sind sie für viele Unternehmen der handelsregistermanifestierte Inbegriff von Angst.

Zusammenfassend kann man sagen, dass Unternehmen heute alle agil werden wollen, weil sie durch viele bereits agile Unternehmen unter Druck gesetzt werden, weil sie von externen Umwelteinflüssen wie Corona unter Druck gesetzt werden oder weil sie durch die Erfolge der fabelhaften GAFA-Unternehmen (GoogleGoogle, AppleApple, FacebookFacebook, AmazonAmazon) motiviert werden.

Lesetipp:

Magazin „Warum Agilität kein Hype ist“, https://www.agile-heroes.de/magazine/agilitaet-kein-hype/

Abb. 5

Ist Scrum so beliebt, weil Agilität gehypet ist?

Diese Frage ist nicht einfach zu beantworten. Grundsätzlich gilt, dass Agilität aktuell ein echter Hype ist. Wenn man sich mit dem Thema Agilität näher beschäftigt, wird man über kurz oder lang nicht an Scrum vorbeikommen. Denn wer agil werden will, der fragt sich natürlich schon bald: Wie. Beziehungsweise welche Best Practise Frameworks kann ich anwenden, um agil bzw. agiler zu werden? Der Agilitätshype spielt dem Framework von Scrum demnach in die Karten. Aus diesem Grund könnte man dieser These nachkommen und sagen, dass Scrum gerade so beliebt ist, weil es auch Agilität ist.

Scrum ist in der Welt der Agilität allerdings nicht das einzige Framework. Jedoch das bekannteste bzw. das am häufigsten verwendete. Im Zuge dessen könnte man sich natürlich fragen, wieso es gerade Scrum war oder ist, das mit Abstand am meisten Verwendung findet?

Abb. 6

Die Antwort darauf könnte sein: Weil es das beste Framework ist. Eine andere Antwort könnte sein: Weil die Erfinder das beste Marketing gemacht haben. Welche Antwort man auch findet, eine echte Garantie, dass diese richtig ist, kann man nicht abgeben.

Fakt ist jedoch: Viele erfolgreiche Produkte und Projekte werden mit Scrum durchgeführt. Viele Unternehmen schwören darauf. Und last but not least ist Agilität ein Megatrend. Vielleicht ist es auch eine Mischung aus all diesen Faktoren, die dazu geführt haben, dass Scrum das mit Abstand bekannteste und scheinbar beliebteste Framework.

Wo wird Scrum eingesetzt?

Als im Jahr 1995 Ken Schwaber und Jeff Sutherland das Scrum-Framework in seiner heutigen Form vorstellten, waren die dort niedergeschriebenen Erfahrungswerte ausschließlich im Bereich der Software-Entwicklung gemacht worden. Heute, 25 Jahre später, ist es immer noch so, dass die Mehrzahl der Anwendungsfälle im Softwarebereich liegen. Ohne hier auf Statistiken zurückgreifen zu können, wären realistische Schätzung im 80 %-Bereich zu taxieren. Hintergrund ist hierbei, dass die Software der perfekte Use Case für Scrum ist. Denn (vereinfacht gesagt) ein Button in einer App ist in zwei Minuten angepasst. Ein Türgriff in einem Haus hingegen ist mit deutlich höherem Aufwand zu ändern. Hiermit stellt sich unmittelbar die nächste Frage:

Ist Scrum überhaupt überall anzuwenden?

Und die klare direkte Antwort zu der Frage ist: Nein. Scrum ist nicht überall anwendbar. Zumindest nicht in seiner vollständigen Form, die dann aber auch per Definition nicht mehr Scrum wäre. Es gilt jedoch zu beachten, dass fernab der in Scrum niedergeschriebenen Definition „Scrum ist nur in seiner Reinform wirklich Scrum“, natürlich Teile davon in komplett unterschiedlichen Branchen, Unternehmen und Projekten Anwendung finden kann und jene Menschen dann gerne auch publik machen, sie würden nach Scrum arbeiten.

Um aber hier die Frage, wo und wann Scrum eingesetzt wird, seriös beantworten zu können, muss die Frage gestellt werden, welchen Mehrwert eine Arbeit von Scrum bringt.

Der Mehrwert bezieht sich hierbei – ohne an dieser Stelle ins Detail zu gehen – neben den vielen team- und softskillbasierten Mehrwerten, vor allem auf die schnelle Entwicklung und Lieferung auf Produktkomponenten. „Schnell“ bedeutet hierbei frühestens alle 14 Tage.

Welchen Vorteil bietet es aber, eine neue Produkt-Komponente alle 14 Tage fertigzustellen oder gar auf den Markt zu bringen? Ganz einfach: Feedback von den Kunden. Hierdurch ermöglicht man eine Entwicklung, bei der der Kunde im Entwicklungsprozess sehr stark eingebunden ist. Der Kunde kann Feedback geben und man kann weiter an seinem Produkt arbeiten – und zwar so, wie es dem Kundenbedürfnis am ehesten entspricht. Der KundeKunde muss dann nicht wieder ein ganzes Jahr, sondern lediglich 14 Tage auf die Berücksichtigung oder Einarbeitungen des Feedbacks warten. Das bedeutet einerseits, dass man sehr schnell erkennt, ob die kundenseitige Anforderung in die Realität umgesetzt, wirklich das bringt, was man sich erhofft hat. Andererseits wird das Risiko reduziert etwas zu entwickeln, was vollkommen am Kundenbedarf vorbeigeht. In diesem Fall wäre eine Zeitverschwendung von 14 Tagen im Vergleich zu einem Jahr sehr viel kostengünstiger.

Wer ist der Kunde und was ist das Produkt?

Wer der Kunde ist, ist völlig frei zu definieren. Hierbei kann es sich um den klassischen Endkunden handeln, es kann aber auch ein unternehmensinterner Kunde sein – also beispielsweise eine Unternehmensabteilung.

Auch das Produkt, das hier generisch beschrieben wird, ist frei wählbar. Jedoch fällt schnell auf, dass diese Produkte, die im besten Fall 14 Tage bis zur Auflieferung brauchen, eher Software basiert sind.

Hierbei ist TeslaTesla wieder einmal ein sehr gutes Beispiel. Ein Tesla Model 3 ist in seiner Hardware nach Auslieferung nur noch schwer, nämlich über Werkstattbesuche oder Rückrufaktionen, zu ändern oder gar weiterzuentwickeln. Darüber hinaus kann ein bestehendes analoges Produkt eher schwer umgebaut werden – im Vergleich zu einer Software. Es kann am Auto nicht mühelos ein Teil weggesägt werden und ein neues hinzugefügt werden. Dies würde jegliches Kosten-Nutzen-Verhältnis zerstören.

Anders sieht es bei der Software des Fahrzeugs aus: Ob der Software-Entwickler einen Button oder gar eine ganze Funktion ändert, ist im Verhältnis kein großer Aufwand. Hinzu kommt, dass diese Änderung nur ein einziges Mal durchgeführt werden muss und dann „per Knopfdruck“ über das Internet in jedes Tesla-Fahrzeug weltweit eingebunden werden kann. Und wenn es am Ende nicht den erhofften Mehrwert für den Kunden bringt, dann kann es auch wieder relativ einfach entfernt werden.

Das beschreibt einfach und gleichzeitig eindrucksvoll, wo Scrum wirklich seinen vollen Mehrwert im Produktbereich entfalten kann. Weitere Mehrwerte sind neben der schnelleren und bedarfsgerechten Produktentwicklung, vor allem im Team-Softskill-Bereich einzuordnen.

Ersetzt Scrum das klassische Projektmanagement?

Um dieser Frage gerecht zu werden, lohnt es sich etwas mehr im Bereich des Projektmanagements auszuholen. Grundsätzlich werden drei Projektmanagementansätze unterschieden:

 klassisch

 agil

 hybrid

Klassisch:

Klassisches ProjektmanagementProjektmanagement beschreibt demnach einen Ansatz, ein Projekt von Anfang bis Ende grob durchzuplanen und dabei lange, über mehrere Monate andauernde Phasen zu durchlaufen und am Ende mit einem „Big Bang“ das Produkt auf den Markt zu bringen. Wer sich jetzt an das Beispiel aus den vorherigen Kapiteln erinnert, dem wird auffallen, dass wir dort nie ein Produkt in einem „Big Bang“ auf den Markt gebracht haben, sondern dieses Produkt immer inkrementell, also Stück für Stück, mit dem Markt entwickelt haben.

Videotipp:

Was ist klassisches Projektmanagement; ► https://www.youtube.com/watch?v=FKCom8wziEk

Abb. 7

Agil:

Wirft man nun einen Blick auf das agile Vorgehen, so fällt auf, dass die Phasen aus dem klassischen Projektmanagement auch hier Anwendung finden, diese aber nicht einmalig über einen langen Zeitraum funktionieren, sondern innerhalb unserer beispielhaften 14 Tage. Also viel schneller. Das Produkt ist dann ebenfalls zur selben Zeit wie im klassischen Beriech im „finalen“ Zustand angekommen, jedoch in einer ganz anderen Ausprägung. Und: Teile des jetzt finalen Produkts waren bereits viel früher für den Kunden verfügbar. Dadurch ergeben sich schnelles Feedback vom Kunden und auch ein bereits generierter Umsatz.

Hybrid:

Hierbei wird über ein agiles Vorgehen auf Team-Ebene, ein klassisches Projektmanagement gestülpt. Hintergrund ist, dass Unternehmen, die aus dem Bereich des klassischen Projektmanagements ein Zwischenmodell fahren wollen, um keine erheblichen Veränderungen beispielsweise in der Unternehmensorganisation durchzuführen. Weitere Vorteile der hybriden Vorgehensweise sind, dass man Teams in den Genuss von agiler, selbstorganisierter Arbeit kommen lassen will, aber dennoch ein Projekt mit einem „Big Bang“ auf den Markt bringen will. Ein hybrides Vorgehen birgt neben der großen Chance, Vorteile aus beiden Welten zu vereinen, das große Risiko am Ende mit den Nachteilen aus beiden Welten zu arbeiten.

Nach Differenzierungsdarstellung wird klar, dass ein agiles Vorgehen – auch im Projektmanagement – mit Sicherheit grenzender Wahrscheinlichkeit nie ein klassisches Vorgehen komplett verdrängen wird. Vielmehr gilt es für jedes Vorhaben die Frage zu beantworten, wann wird welches Modell eingesetzt?

Diese Frage ist gewiss nicht das erste Mal gestellt worden. Hier hilft das Cynefin-Framework weiter.

Literaturtipp:

Ein Lehr- und Fachbuchklassiker: ist das ebenfalls bei utb erschienene Werk Projektmanagement von Franz Xaver Bea, Steffen Scheurer und Sabine Hesselmann:

https://www.utb.de/doi/book/10.36198/9783838587066

Was versteht man unter dem Cynefin-Framework?

Um dieser sich immer wieder wiederholenden Frage, wann geht man agil und wann klassisch an ein Projekt heran, mit einer soliden Antwort zu entgegnen, kommt man an dem CynefinCynefin-Framework nicht vorbei. Auch große und bekannte Projektmanagementmethoden wie PRINCE2PRINCE2 erwähnen es, um diese zentrale Frage zu beantworten.

Hintergrund dieses Frameworks ist es, durch verschiedene Sachverhaltsbeispiele herauszufinden, welches Vorgehen zu welcher Herausforderung möglicherweise am besten passt. Wichtig dabei ist das Wort „möglicherweise“. Denn auch ein Cynefin-Framework oder eine Voreinschätzung der Ausgangssituation kann sich irren. Es gibt damit keine Garantie die richtige Wahl zu treffen. Es hilft allerdings dabei, das Risiko der falschen Vorgehensweise zu reduzieren.

Im Folgenden wird das Cynefin-Framework in der vollen Breite, jedoch nicht in der vollen Tiefe durchleuchtet.

Abb. 8

Schaut man sich nun das verbildlichte Cynefin-Framework an, so fällt auf, dass es hierbei 5 Bereiche gibt, welche als unterschiedliche Herausforderungslagen beschrieben werden:

 Obvious,

 Complicated,

 Complex,

 Disorder (mittleres, unbeschriftetes Feld) und

 Chaotic.

Quellenhinweis:

Die Grafik stammt von Wikipedia.

Wie findet die Entscheidung für die richtige Vorgehensweise konkret statt?

Dies erfolgt durch eine Zuordnung:

Obvious:

Hierbei handelt es sich um eine Ausgangslage, die sehr bekannt ist. Abläufe sind unzählige Male durchlaufen und Ergebnisse sind schon oft in derselben Art und Weise fertig gestellt worden. Hat man diese Ausgangslage vorliegen, stellt sich nicht die Frage, nach einer richtigen Projektvorgehensweise, da es sich um kein Projekt handelt. Es handelt sich um business as usual, um standardmäßige Linientätigkeiten.

Complicated:

Diese Ausgangslage beschreibt eine Situation, in der eine nicht standardmäßige Aufgabe erfüllt werden muss. Ähnliche Aufgaben wurden bereits öfter im Unternehmen oder von Kollegen erfüllt. Die Anforderungen sind sehr klar formuliert und das erwartete Ergebnis ist absolut bewusst. Hierbei handelt es sich um ein Projekt, das in der klassischen Projektmanagementvorgehensweise durchgeführt werden sollte. Typische Projekte hierfür wären bestandsablösende Systeme, bei denen alle Anforderungen aus dem alten System übernommen werden können und bei denen auch nicht eine schlanke, neue Version live genommen werden kann.

Complex:

Hat meine eine Ausgangslage, in der die Anforderungen nicht sehr klar, also Zusammenhänge und Abhängigkeiten schwer zu durchschauen sind, gleichzeitig das Endergebnis nur wage bekannt ist und der spätere Kunde zunächst nur mit Kernfunktionalitäten, statt einem umfangreichen Produkt leben kann, so haben wir die typische Ausgangssituation, welche sich für ein agiles Vorgehen bestens eignen würde. Typische Projekte sind neue Produkte oder Dienstleistungen, welche durch ein Feedback des Kunden schnell und zielgerichtet weiterentwickelt werden können oder müssen.

Exkurs:

Aus diesem Grund gründen große Konzerne oftmals kleine und schlanke Firmen außerhalb ihrer Konzernstruktur und bauen neue Lösungen für dieselbe Zielgruppe unter neuem (Marken-)Namen. Hierdurch müssen sie ihre bestehenden, oft manchmal noch gut funktionierenden Produkte nicht mit einem umfangreichen Re-Launch im klassischen Modell umsetzen, um am Ende herauszufinden, dass sie gar am Kunden vorbeientwickelt haben. Vielmehr können sie nun schnell und agil ein junges, frisches Produkt an den Markt bringen und testen. Der Wettbewerbsvorteil dieser Vorgehensweise im Vergleich zum typischen Startup ist die kapitalträchtige Mutter im Hintergrund, die neben Geld auch Kunden und Wissen zur Verfügung stellen kann.

Chaotic:

Hierbei ist eine Ausgangslage der völligen Überforderung gegeben. Keiner weiß, wo man anfangen soll und was man am Ende liefern soll. Hier starten die meisten Beteiligten mit blindem Aktionismus und müssen schnell versuchen der Lage, durch Strukturen und Prozesse Herr zu werden. Beispiel hierfür ist die Veränderung der Rahmenbedingungen durch die Corona-Pandemie, die Unternehmen binnen kürzester Zeit vor extreme Herausforderungen gestellt hat. Um diese Ausgangslage zu beherrschen, macht ein Weg in Richtung der agilen Vorgehensweise Sinn.

Disorder:

Hierbei handelt es sich um eine Ausgangslage des Nichts-Wissens. Ziel ist es hier, sich einen ersten Überblick über die Situation zu verschaffen, um möglichst viele Informationen zu sammeln auf Basis dessen dann entschieden werden kann, wie die richtige Vorgehensweise ist.

Videotipp:

Beispielhaft wird hier die Entscheidungshilfe Cynefin-Framework vorgestellt: ► https://youtu.be/hsKTIQR_UNA

Heißt das, dass es bei Scrum keine Hierarchien gibt?

Scrum gibt einen großen Teil der „Macht“ zum Managen und Organisieren an das Team zurück. Einen Projektmanager im klassischen Sinne gibt es nicht mehr. Die Annahme, die hierbei zugrunde liegt, ist, dass die Teams selbst ausreichende Motivation und genug Wissen haben, um sich selbst zu organisieren, und selbst am besten wissen, wie sie ein vorgegebenes Ziel erreichen. Und das ganz ohne detaillierten Projektplan und ganz ohne jemanden, der ihnen sagt, wann sie was genau zu tun haben. Es gibt in einem Scrum -Projektteam kein Hierarchiegefälle, sondern lediglich klar definierte Accountabilities. Jeder respektiert jeden als gleichwertig und kennt seine Rolle ganz genau. So funktioniert Scrum.

Und nicht nur dass – Scrum ist auch außerordentlich pragmatisch: Scrum kommt mit so wenig Administration wie möglich aus. Denkt man daran, wie viel Energie bei nach der klassischen Wasserfall-Methode gemanagten Projekten in Projektplanung, Budgetmanagement und Statusreports anstatt in das eigentliche Management des Projekts geht, wird schnell klar, warum Scrum so erfolgreich ist. All dieser Aufwand entfällt bei Scrum nahezu gänzlich. Scrum ist einfach pragmatischer und effizienter als andere Methoden. Kommunikation findet nicht mehr in Form von langen E-Mails, E-Mail-Ketten und Powerpoint-Präsentationen statt, sondern direkt von Angesicht zu Angesicht, ohne Medien-brüche, von Mensch zu Mensch. Probleme werden nicht über Ampeln kommuniziert, sondern direkt mit dem Betroffenen besprochen. Scrum ist also sehr effizient und verzichtet auf fast alles, was nicht direkt mit dem Projektziel bzw. dem Endprodukt zu tun hat, auf ein Minimum. Und was effizient ist, setzt sich in Zeiten knapper Budgets und immer schneller zu liefernder Ergebnisse einfach durch.

Aufbau und Funktionsweise von Scrum

In diesem Kapitel erfahren Sie, welche Scrum-Mitglieder welche Verantwortlichkeiten haben und welche Elemente relevant sind.

Was sind die wesentlichen Bestandteile von Scrum?

Scrum ist als FrameworkFramework im Vergleich so anderen Frameworks wirklich ein Leichtgewicht. Spricht man in der Welt von PRINCE2, von einem offiziellen Manuel von rund 300 Seiten, so erhält man mit dem →Scrum-GuideScrum-Guide, also dem eigentlich niedergeschriebenen Dokument von Scrum, lediglich 17 Seiten. Die Bestandteile von Scrum sind daher in geringe Menge vorhanden und im Scrum-Guide auch wenig tiefgehend beschrieben. Die tiefgehenden Gedanken von Scrum, sind nicht niedergeschrieben, sondern ergeben sich vielmehr durch das Mindset von Scrum.

Die niedergeschriebenen Bestandteile gliedern sich wie folgt:

 Scrum-Theorie

 Scrum-Werte

 Scrum-Team

 Scrum-Events

 Scrum-Artefakte

 Scrum-Commitments

Abb. 9

Wie funktioniert der Scrum-Prozess

Der Scrum-Prozess orientiert sich an der Theorie des Empirismus. Die Theorie des Empirismus besagt, dass eine Entscheidung nur auf der Basis von Informationen getroffen werden kann. Schauen wir uns jetzt die drei Schritte der Theorie des Empirismus an, fällt auf, dass Diese dem Grundgedanken von Scrum sehr ähnlich sind und deswegen die Scrum-Theorie danach angelehnt ist. Wir unterteilen die Theorie des Empirismus und damit auch die Scrum-Theorie in drei Schritte:

 Schritt 1: TransparencyTransparency

 Schritt 2: InspectionInspection

 Schritt 3: AdaptionAdaption

Schritt 1: Transparency: Alle Mitglieder eines Scrum-Teams legen transparent ihre Arbeit dar. Durch diese neue Transparenz können in den folgenden Schritten Entscheidungen getroffen werden. Diese Transparenz stellt also eine valide Informationsquelle dar.

Schritt 2: Inspection: Hier werden die Informationen, die durch den ersten Schritt offengelegt wurden, verwertet. Wir besprechen innerhalb der Teams, wie wir mit den neuen Informationen umgehen und auf Basis dessen Entscheidungen treffen können, die uns im weiteren Scrum-Verlauf helfen können.

Schritt 3: Adaption: Hier werden die Informationen aus Schritt 1 mit den Entscheidungen aus Schritt 2 umgesetzt. Dieser dritte Schritt Adaption ist demnach der Schritt, wo es um die exekutive Umsetzung der Maßnahmen geht.

Fassen wir diese drei Schritte noch einmal anhand eines Praxisbeispiels zusammen. Das Scrum-Team bemerkt, dass das entwickelte Produkt sehr viele Fehler vorweist und stellt dies in einem ersten Schritt der Transparenz in einem Meeting dar. Wie dieses Meeting heißt, dazu kommen wir noch in einem späteren Kapitel. Im nächsten Schritt erkennen wir als Produktverantwortliche mit dem Schritt 2 Inspection, dass wir viele Fehler mit dem Produkt haben, und kommen dann zu dem Entschluss, dass sich die Zeit um vier Wochen verzögern wird. Daraufhin kommen wir zum Schritt 3, das ist der Schritt der Adaption, der Umsetzung auf Basis der neuen Erkenntnisse. Und auf der Basis der Erkenntnisse Treffen wir die Entscheidung, wir reduzieren den Umfang des Produkts, um weiterhin innerhalb des festgelegten Zeitrahmens zu bleiben. Dadurch haben wir Agilität im perfekten Maße ausgelebt. Wir haben den Umfang reduziert, um die Zeit einzuhalten. Und Dies auf Basis der Scrum-Theorie bzw. der Theorie des Empirismus.

Lesetipp:

Der Scrum-Prozess; https://www.agile-heroes.de/magazine/der-scrum-prozess/

Welche Teammitglieder bzw. Verantwortlichkeiten gibt es in Scrum?

Scrum unterscheidet grundsätzlich zwischen drei Rollen. Wobei das Wort Rolle bis 2020 das Wort der Wahl war. Seit November 2020 haben die Gründer Jeff Sutherland und Kent Schwaber das Wort Rollen in Verantwortlichkeiten in Scrum unbenannt. Demnach gibt es in Scrum drei Verantwortlichkeiten:

 Verantwortlichkeit 1: Der →Scrum MasterScrum Master. Der Scrum Master ist kurzgesagt das methodische Lead des Scrum-Teams. Er hat die Verantwortung für Scrum-Methode.

 Verantwortlichkeit 2: Der Scrum-Product OwnerProduct Owner. Der →Product Owner hat die Produktverantwortung. Also die Verantwortung für das entwickelnde Produkt, das von dem Entwicklungsteam umgesetzt wird, also entwickelt wird.

 Verantwortlichkeit 3: Das Scrum-Entwicklungsteam. Das Scrum-Entwicklungsteam – oder wie es seit 2020 heißt: Developers bzw. auf Deutsch Entwickler – hat die Verantwortung, dass in jedem Sprint vereinbarte Sprint Backlog abzuarbeiten. Oder anders gesagt, es hat die Verantwortung, die versprochenen Aufgaben für den Zyklus, für den aktuellen Zyklus, abzuarbeiten.

Was ist ein Scrum Master?

Die Verantwortung eines →Scrum Masters innerhalb eines Scrum-Teams umfasst viele Tätigkeiten: Grundlegend geht es darum die methodische Obacht von Scrum in einem Scrum-Umfeld zu gewährleisten. Der Scrum Master ist außerdem für die Einführung von Scrum, wenn man sich in einem neuen Scrum-Umfeld bewegt, wie es im Scrum-Guide definiert wurde, verantwortlich. Die Verantwortungsbereiche gliedern sich dabei wie folgt: Der Scrum Master unterstützt das Team, er unterstützt den Product Owner und er unterstützt die Organisation.

 Punkt 1: Der Scrum Master unterstützt das Team beinhaltet: CoachingCoaching der Teammitglieder im Selbstmanagement (Selbstorganisation) und in der funktionsübergreifenden Zusammenarbeit. Das Ziel ist es hierbei, das Team so gut wie möglich in Selbstmanagement zu üben.

 Punkt 2: Des Weiteren unterstützt der Scrum Master die Scrum-Teams bei der Konzentration, also bei dem Fokus, von der Entwicklung von hochwertigen →InkrementenInkrementen (hierauf gehen wir im späteren Teil des Buchs genauer ein) entsprechend der →Definition of Done (auch hier gehen wir später nochmal genauer darauf ein). Ein Inkrement ist im Grunde genommen ein Teilprodukt des Gesamtprodukts und die Definition of DoneDefinition of Done entspricht dabei der Qualitätsstrategie.

 Punkt 3: Der Scrum Master unterstützt die Entwickler bei der Beseitigung von Hindernissen, die den Fortschritt des Teams behindern oder verlangsamen.

 Punkt 4: Er stellt sicher, dass alle Veranstaltungen (Events) stattfinden und erfolgreich, produktiv und innerhalb der definierten Timebox abgehalten werden. Die Timebox ist eine Technik, welche besagt, dass ein Meeting immer zur vorgegebenen Zeit beginnt und maximal zur vorgegebenen Zeit endet. Es kann jedoch jederzeit früher beendet werden.

Zu Punkt 2: Der Scrum Master unterstützt den →Product Owner

Der Product Owner wird bei der Verantwortung der Produktziele unterstütz und bei der Verantwortung des Product Backlogmanagements. Hierbei geht es darum, dass er den Product Owner mit Coaching und Scrum-Best-Practices unterstützt, seiner Verantwortung als Product Owner nachzukommen. Der Scrum Master hilft dem Product Owner dabei die Product Backlog-Items, also den in der To-Do-Liste niedergeschriebenen Anforderungen so zu formulieren, dass sie für das Scrum-Team verständlich sind. Der Scrum Master hilft dem Product Owner dabei, die Produktplanung entlang des empirischen Scrum-Prozesses zu vollziehen. Dabei ist gemeint, dass er das Produkt entlang kontinuierlicher Verbesserungsmaßnahmen planen könnte.

Als Beispiel ist hier zu sehen, dass ein Produkt in Zyklen auf den Markt gebracht wird, um es von den Kunden validieren zu lassen um so der bereits bekannten Transparency, Inspection und Adaption, also dann auf Kundenbasis Feedback einzuarbeiten, nachgekommen werden kann. Der Scrum Master unterstützt den Product Owner des Weiteren dabei, die Zusammenarbeit mit anderen Stakeholdern zu fördern. Stakeholder sind Menschen, die an dem Produkt oder Projekterfolg interessiert sind und so Informationen seitens des Product Owner erhalten wollen.

Zu Punkt 3: Der Scrum Master unterstützt die Organisation

Der Scrum Master unterstützt die Organisation, indem er das Thema Scrum innerhalb der Organisation verantwortet. Schulungen und Coachings innerhalb der Organisation durchführt und hilft wie Scrum eingeführt werden könnte oder eingeführt wird. Der Scrum Master unterstützt die Organisation bei der Planung und Beratung von der Einführung von Scrum innerhalb der Organisation. Darüber hinaus unterstützt der Scrum Master, den Mitarbeitern und Stakeholdern das Verständnis von Scrum und den empirischen Ansatz von Scrum zu folgen. Eine weitere Aufgabe eines Scrum Masters innerhalb der Organisation ist es, Barrieren, welche es im klassischen Projektmanagement des Öfteren gab, zwischen Stakeholdern und den Scrum-Teams zu reduzieren und so einen noch größeren Erfolg von Scrum, sicher zu stellen.