Was ist Scrum und warum sollte Ihr Team es nutzen?

Teilen!

Scrum liegt im Trend und sein Einfluss auf alle Management- und Teamarbeitsmodelle ist nicht zu leugnen. Dieses "Modell" ist der Protagonist eines globalen Wandels. Wenn die Pandemie den organisatorischen Wandel beschleunigt hat, dann ist Scrum der Treibstoff, der Hunderttausende von Remote- und virtuellen Teams weltweit antreibt.

Aber was ist Scrum und warum ist es so berühmt?

Im Managementkontext wurde Scrum in den frühen 1990er Jahren entwickelt. Es dauerte jedoch fast zwei Jahrzehnte, bis die erste Version des offiziellen Leitfadens veröffentlicht wurde, was, wie wir Geeks sagen würden, die kanonisches Modell von heute.

Die Eltern von Scrum sind Jeff Sutherland und Ken Schwaber. Und ihre Vision hat sich im Laufe der Jahre weiterentwickelt. Für viele ist es daher schwierig zu definieren, was Scrum ist - eine Methode? ein Modell? ein Prozess? oder eine Methodik?

Scrum-Methodik oder Prozess?

Lego-Farbchips
Haben Sie Lieblingsmünzen, und gibt es welche, die Sie immer verwenden? Dies ist Ihr Rahmen

Scrum ist ein Rahmenwerk - ein RahmenwerkUnd was bedeutet es, ein Rahmen zu sein? Nehmen wir ein Beispiel dafür, was ein Rahmenwerk ist. Eines der Beispiele, die ich mag.

Stell dir vor, du bist ein LEGO® Fan und hast eine Schachtel mit LEGO® Spielsteinen gekauft. Sie beschließen jedoch, nicht der Anleitung zu folgen, sondern Ihr eigenes Modell zu entwerfen. Kreativmodus, wie die Minecraft-Spieler sagen würden.

Wenn Sie im kreativen Modus mit Ihren Spielsteinen arbeiten, haben Sie vielleicht eine Vorliebe für einige wenige Spielsteine, die immer als Basis für Ihre Modelle dienen. Diese grundlegenden Token, die die Basis für komplexere Modelle bilden, könnte man als solche bezeichnen: Arbeitsrahmen o Rahmenwerk.

Scrum: ein Basis-Set

Scrum ist eine Reihe von "Grundregeln", die Folgendes beinhalten:

  • Veranstaltungen - eine Reihe von Aktivitäten, die einige "Erneuerer des Wortes" als Zeremonien oder Rituale bezeichnen.
  • Artefakte - Werkzeuge und Instrumente wie die Rückstand Product Backlog und Iteration Backlog, oder die Completion Definition - die Definition von erledigt
  • Rollen - wo der berühmte Scrum Master und Product Owner beschrieben werden.

Dieser Grundstock ist ein fruchtbarer Boden für die Aufnahme neuer Praktiken oder die Skalierung des Modells. Darin liegt der Erfolg von Scrum und der Grund, warum es so berühmt ist. Scrum ist einfach, geradlinig und leichtgewichtig. Das ist ihr größter Vorteil - und ihre größte Schwäche.

Wenn Ihr Team das, was es auf der Grundlage von Scrum aufbaut, gut strukturiert, wird es erfolgreich sein. Wenn Ihr Team nicht gut strukturiert ist, wie der Rahmen zu erweitern ist, wird es sicherlich viele Probleme erleiden, die Sie darüber nachdenken lassen, den Weg aufzugeben.

Was sind Sprints?

Bevor wir über Scrum-Events sprechen, ist es gut, über das Konzept der Sprint. Und obwohl Scrum kein vorgeschriebener Prozess ist, schlägt es ein auf Sprints basierendes Managementmodell vor.

Sprints sind kurze Zeiträume von fester Dauer - nicht länger als 4 Wochen. Diese Zyklen werden in anderen Managementmodellen als Iterationen bezeichnet. In vielen Fällen werden die Begriffe synonym verwendet.

Die Sprints sollten immer gleich lang sein. Im Laufe der Jahre wurden die Empfehlungen für die Dauer von Sprints immer kürzer. Vor nicht allzu langer Zeit wurden noch Zyklen von 2 bis 8 Wochen empfohlen. Heute lautet die Empfehlung, dass ein Sprint 1 bis 4 Wochen dauern sollte.

Wenn Sie nach Scrum arbeiten, sollten Ihre Sprints immer die gleiche Länge haben. Das heißt, Sie sollten nicht Sprints von einer Woche und Sprints von 4 Wochen und Sprints von 2 Wochen haben.

Scrum-Zyklus

Scrum-Zyklus-Diagramm - von Alberto Dominguez

Das Modell definiert eine sich wiederholende Abfolge von Ereignissen. Sprint a Sprint. Dieser Zyklus umfasst:

  1. Planungmit dem die Fragen beantwortet werden sollen:
    1. Was ist das Ziel dieses Sprints?
    2. Wie wollen wir dieses Ziel erreichen?
  2. Tägliche ÜberwachungZiel ist es, das Team auf dem Laufenden zu halten und Fragen zu beantworten:
    1. Was haben wir erreicht?
    2. Worauf konzentrieren wir uns jetzt?
    3. Welche Probleme haben wir oder mit welchen Risiken rechnen wir als Team?
  3. Abschluss auf Produktebene. Versucht zu antworten:
    1. Was haben wir während des Sprints abgeschlossen?
    2. Entspricht das, was wir abgeschlossen haben, dem angegebenen Bedarf oder Ziel?
  4. Abschluss auf der Prozessebene. Beantworten Sie die Fragen:
    1. Was haben wir als Team gut gemacht?
    2. Was müssen oder können wir verbessern?
    3. Welche Maßnahmen werden wir ergreifen, um schlechte Gewohnheiten im Team zu verbessern oder zu korrigieren?

Verfeinerung des Produkt-Backlogs

Die Verfeinerung der Rückstand ist eine Aktivität, die in den letzten Jahren immer mehr an Bedeutung gewonnen hat. Die Verfeinerung des Backlogs wurde früher als Grooming bezeichnet.

Allerdings, und ich denke, dass diese Aktivität - die oft mit dem Begriff Scrum erwähnt wird - aus Sturheit nicht als offizielles Ereignis im Rahmenwerk erscheint.

Ich spreche mich offen dagegen aus, sie nicht ausdrücklich als Ereignis zu bezeichnen.

Scrum Beispiel: Zyklusereignisse als Agenda

Wie ich bereits sagte, wiederholt sich der Scrum-Zyklus in jedem Sprint. Wenn also die Dauer Ihrer Iterationen eine Woche beträgt, wiederholt sich dieser Ereigniszyklus jede Woche. Wenn Ihre Iterationen zwei Wochen dauern, könnten Sie einen ähnlichen Zeitplan erstellen - dies ist ein Beispiel, das Sie nicht für alle Ihre Teams und Projekte kopieren und einfügen sollten. Ich bin sicher, dass es Ihnen helfen wird, ein Gefühl dafür zu bekommen, was vor sich geht.

Beispiel einer Agenda mit Scrum-Events für einen 2-Wochen-Sprint - von Alberto Dominguez

Scrum-Typen

Obwohl es nur ein kanonisches Scrum gibt, gibt es definitiv mehrere Versionen oder Visionen des Frameworks. Der am meisten akzeptierte und respektierte ist natürlich der Scrum Guide.

Aber hier präsentiere ich Ihnen einen Großteil der verfügbaren Literatur - jede mit ihrer eigenen, an Scrum angepassten Version - was ich mit diesem Artikel auch ein wenig tue. Fügen Sie ein wenig Kontext und Erfahrung hinzu und versuchen Sie dabei, die Grundregeln - die Säulen und Werte - nicht zu verletzen.

Offizieller Leitfaden: Kanonisches Modell

Ich habe bereits über den Scrum Guide gesprochen. Hier sind seine Merkmale:

  1. Sie wird von den "Eltern" von Scrum gepflegt und aktualisiert.
  2. Es wurde ursprünglich für die Softwareentwicklung konzipiert.
  3. Sie ist die beliebteste und am weitesten verbreitete Version.
  4. Sie ist auch die mehrdeutigste und am wenigsten restriktive Version. Dies kann dazu führen, dass unerfahrene Teams ohne angemessene Begleitung die Orientierung verlieren.

Scrum Body of Knowledge: der meistgehasste

Wenn der offizielle Leitfaden die umfassendste und flexibelste Vision hat, dann ist der SBOK ist das genaue Gegenteil. Das Unternehmen, das hinter diesem (monströsen) Dokument steht, wollte das PMBOK von PMI nachahmen. Vor einigen Jahren war es sehr erfolgreich und seine Zertifizierungen waren sehr verbreitet. Heute, mit dem Aufkommen anderer, noch fragwürdigerer und weniger strenger Akteure, hat sie stark an Boden verloren. Obwohl mir ihr Ansatz nicht gefällt, gebe ich zu, dass die Bemühungen, die gesamte Arbeit zu strukturieren, wertvoll sind und einige interessante Lösungen für die Herausforderungen bei der Übernahme der Methodik bieten.

Scrum im Scaled Agile Framework (SAFe)

SAFe ist ein Rahmenwerk für Agilität in großem Maßstab. Der Vorschlag versucht, der Tatsache Rechnung zu tragen, dass der Rahmen keine Entscheidungen über organisatorische Bemühungen oder Strukturen anderer Größenordnungen - 50, 70 oder 150 Personen - trifft.

Obwohl SAFe das Rahmenwerk nicht beschreibt, ist klar, dass es deutliche Änderungen am kanonischen Modell vornimmt.

Scrum @Scale

Ein weiterer - für meinen Geschmack etwas vereinfachter - Versuch, Scrum auf der Organisationsebene zu fördern. Einer der Hauptkritikpunkte ist, dass es auf dem aufbaut, was das skalenfreie Modell zu diskreditieren versuchte. Größe erfordert zwangsläufig Struktur und eine gewisse Bürokratie.

Andere Versionen: Zertifizierungen ohne konzeptionellen Input

Ich könnte behaupten, dass es 1000 Versionen des Frameworks gibt. Fast alle von ihnen sind mit einer "Zertifizierung" in einer der Rollen verbunden. Aber ich kann Ihnen getrost versichern, dass hinter diesen Bemühungen mehr die Absicht steht, mit Kursen und Zertifizierungen Geld zu verdienen, als einen wirklichen Beitrag zum Beruf oder zur Übung selbst der Teams zu leisten, die Scrum anwenden.

Scrum Artefakte

Der Scrum-Rahmen hat nur sehr wenige Artefakte. Das macht es schwierig, zu "landen". Und ohne das Wissen und die Erfahrung kann es zu Frustration im Team führen, wenn man nicht weiß, wie man das Beste aus ihnen herausholen kann.

Hier finden Sie eine Liste der "offiziellen" Artefakte und anderer Artefakte, die zusätzlich zum "Basis-Set" verwendet werden und sehr beliebt sind.

Rückstand

Das Backlog ist eine nach Prioritäten geordnete Liste von Anforderungen. Im Gegensatz zu anderen Dekompositionsstrukturen ist das Backlog so konzipiert, dass es Bewegung und Dynamik in den Anforderungen unterstützt. Änderungen, neue Anforderungen und sogar unterschiedliche Detaillierungsgrade lassen sich leicht verwalten.

Es gibt zwei Arten von Rückständen:

  1. Produktrückstand. Eine geschäftswertorientierte Version.
  2. Sprint Backlog. Eine Art Kind des Product Backlogs, das zwar geschäftsorientiert ist, aber fast immer viel mehr Details und sogar Elemente enthält, die auf die Produktentwicklung oder -wartung ausgerichtet sind - bekannt als Enabler oder Aufgaben und Teilaufgaben.

Erhöhung

Inkrementalismus ist ein einfaches Konzept, das in der Praxis sehr schwer umzusetzen ist. Inkrementalismus ist ein "entscheidender Schritt" oder ein "konkreter Sieg" auf dem Weg zur Erreichung des Produktziels.

Wenn wir also von Software sprechen, handelt es sich um eine Version des Produkts, die innerhalb des Sprints entwickelt oder "weiterentwickelt" wird und einen klaren und testbaren Wertbeitrag liefert - vergessen wir nicht die Säulen von Scrum.

Aber was ist ein Inkrement, wenn mein Team keine Software entwickelt? Tja, da liegt der Hase im Pfeffer. Wie man einen hochrangigen, auf frühe Gewinne ausgerichteten Fahrplan strukturiert. Nicht einfach.

Definition von Abgeschlossen - Definition von Erledigt

Dabei handelt es sich um eine Art Checkliste, die das Entwicklungsteam mit dem Product Owner abstimmt. Der Zweck dieser Checkliste ist vergleichbar mit dem, wenn Sie Ihr Auto zum Händler - oder in die offizielle Werkstatt - bringen. Bevor Sie Ihr Auto abholen können, wird man Ihnen sicherlich eine Checkliste geben, auf der alle Schritte als erledigt markiert sein sollten. Auf diese Weise wissen sie, dass sie bereit sind, von Ihnen "genehmigt" zu werden.

Definition des Begriffs Ready to Work - Definition von Bereit

Dies ist ein beliebtes Artefakt, aber inoffiziell.

Wenn es eine Liste gibt, um zu überprüfen, ob ein Auftrag abgeschlossen wurde. Es ist auch möglich, eine Liste zu definieren, um zu überprüfen, ob ein Produkt-Backlog-Element bereit ist, vom Team bei der Planung eines Sprints bewertet zu werden.

Anwendergeschichten - Anwendergeschichten

Anwenderberichte Sie sind KEIN Scrum-Artefakt. Außerdem gibt es KEINE Verpflichtung, diese Art von Tool als Backlog-Element zu verwenden - obwohl viele darauf bestehen, dass man nicht agil ist, wenn man keine User Stories verwendet.

Entgegen der landläufigen Meinung haben User Stories und Scrum nicht denselben Ursprung. US, wie sie im Volksmund genannt werden, sind keine Voraussetzung für die Entwicklung einer User Story. Conditio sine qua non ein Backlog zu haben oder Scrum einzuführen. Das heißt, Sie können Scrum übernehmen und NIEMALS User Stories verwenden.

User Stories sind ein wertvolles Artefakt, wenn das Team versucht, neue Produkte zu entwickeln. User Stories konzentrieren sich auf den Wert dessen, was ich erreichen möchte, und nicht auf den Umfang dessen, was ich erreichen möchte.

Lassen Sie uns mit einem Beispiel beginnen. Beginnen wir mit dem Kontext.

Alberto ist ein engagierter und engagierter Mitarbeiter. Es ist schon eine Weile her, dass Alberto Urlaub gemacht hat. Deshalb hat er beschlossen, sich ein paar Tage im Kreise seiner Familie zu erholen.

Bereichsorientierte Anforderung - Bereichsorientierte Anforderung - Bereichsorientierte Anforderung - Bereichsorientierte Anforderung - Bereichsorientierte Anforderung - Bereichsorientierte Anforderung Umfang

Wir haben einen Kontext, der eine Notwendigkeit darstellt. Das ist von grundlegender Bedeutung, und ich werde eine Anforderung schreiben, die darauf abzielt, dieses Bedürfnis mit einem bestimmten Umfang zu lösen - das heißt, die Lösung für das Bedürfnis im Vorübergehen festzulegen.

Buchen Sie Tickets, All-inclusive-Unterkunft und Transfers für ein ganzes Wochenende - Freitag bis Sonntag - in der Ferienstadt Punta Cana in der Dominikanischen Republik für Alberto und seine Familie.

Auf den ersten Blick ist eine Wochenendreise eine Voraussetzung, die meinen Wunsch nach Urlaub sicherlich erfüllen wird. Wenn Sie Punta Cana nicht kennen, sagen wir einfach, es ist ein Ort zum Entspannen und Genießen des Wetters, der Strände und eines guten Rums.

Die Erfüllung dieser Anforderung schränkt jedoch die Möglichkeiten zur Lösung des Problems auf eine (1) ein, d. h. ich kann nur nach Punta Cana reisen. Was geschieht, wenn die Flüge nach Punta Cana gestrichen werden oder die Hotels nicht verfügbar sind? Wir können die Anforderung nicht auflösen.

Geschäftswertorientierte Anforderung

Eine User Story - mehr oder weniger gut geschrieben und mit der festen Absicht, den akademischen Unterschied zu erklären - würde in etwa so aussehen:

Als engagierter Arbeitnehmer möchte ich ein paar Tage außerhalb von Arbeit und Familie verbringen, um mich auszuruhen und die Energie zu tanken, die ich brauche, um meine Arbeit gut zu machen.

In dieser Vorschrift ist nicht ausdrücklich festgelegt, was zu tun ist, um Alberto ein paar Tage Aufschub zu gewähren. Das kann eine schlechte Sache sein, wenn wir als Team keinerlei Erfahrung mit dem Angebot von Familienerholungsaufenthalten haben. Das kann gut sein, wenn wir als Teams gut darin sind, den Familien Alternativen zur Erholung zu bieten.

Scrum-Rollen

Der Rahmen ist ein "Basis-Set". Und nach dieser Philosophie sind auch die Rollen innerhalb von Scrum. Das heißt, es gibt einige Rollen innerhalb des Rahmens, aber das bedeutet nicht, dass er keine anderen Rollen haben kann, oder doch?

Einige Radikale, ScrumaniacsWenn es innerhalb eines Scrum-Teams keine anderen Rollen gibt, würde man sagen, es gibt keine weiteren Rollen, aber sagen wir, es können Spezialisierungen sein. Sagen wir, UI/UX-Spezialist oder Testspezialist, oder Datenbankspezialist - ich habe nur einige Beispiele genannt, um die Scrumaniacs zu quälen.

Diese Kernaufgaben sind:

Produkteigentümer - Produktverantwortlicher

Glas mit herauskommenden Münzen, die den Geschäftswertstrom darstellen

Nach meiner Erfahrung ist der Product Owner (PO) die wichtigste Rolle für den Erfolg von Scrum in Organisationen. Sie fragen sich sicher, aber ist der Scrum Master nicht der "Master" in Ihrer Rolle, wenn Sie nicht der Wichtigste sind? Nun, solche Dinge passieren manchmal.

Meiner Meinung nach ist der PO für den wichtigsten Beitrag zur Agilität zuständig, nämlich die Struktur, die eine inkrementelle Lieferung ermöglicht - oder die berühmten Produktinkremente.

Stellen Sie sich vor, Sie sind der Chef des besten Küchenteams der Welt und wissen nicht, was Sie mehr verlangen sollen als "Reis mit Ei".[1]Und ich meine, es ist ein Gericht, das wir alle schon einmal gegessen haben, und es ist ein Teil der Geschmacksatlas-Ranking.. Oder Sie fragen nach Rezepten, die nicht dem Geschmack Ihrer potenziellen Gäste entsprechen. Was für eine Verschwendung!

Der Product Owner ist für die Maximierung des Nutzens der Ergebnisse der Arbeit des (Entwicklungs-)Teams verantwortlich. Das heißt, der Product Owner ist derjenige, der die Anforderungen definiert, priorisiert und validiert - oder zumindest diese Prozesse steuert. Bei dieser Definition, Priorisierung und Validierung versucht er/sie, den "Wertstrom" zu maximieren. Das heißt, der Nutzen, der sich aus dem Testen, der Nutzung oder dem Erleben der Ergebnisse jeder Iteration ergibt.

Scrum-Meister

Silhouette mit Laserstrahlen im Hintergrund

Die andere Rolle ist die des Scrum Masters, der eine Art Vermittler und Cheerleader ist - manche mehr letzteres als ersteres XD - der versucht, das Team (als Team) zu stärken und seine Mitglieder in ihrem Wachstum zu unterstützen.

Weit davon entfernt, direkte Verantwortung innerhalb des Teams zu übernehmen, ist der Scrum Master derjenige, der sich um die Ausübung der Methode "kümmert" - obwohl Scrum in der Theorie keine Methode ist. Und er/sie ist diejenige/derjenige, die/der das Team vor potenziellem Missbrauch der PO schützt und hilft, alle Hindernisse zu beseitigen, die während der Arbeit auftreten können - eine Art Skateboarder, wie wir hier in Kolumbien sagen würden.

Viele sehen im SM einen Retter oder ein erleuchtetes Wesen. Ich gebe zu, dass es nicht leicht ist, derjenige zu sein, der den Wandel anführt - und hilft, ihn zu verändern. Aber er oder sie ist definitiv eher ein Agent des Wandels als ein aktiver Akteur im produktiven Prozess.

Ist der Scrum Master der neue Projektmanager?

Meiner Meinung nach überhaupt nicht. Beide Rollen sind unterschiedlich und ergänzen sich. Sie können PM, SM oder SM haben, die auch PM sind, oder PM, die auch SM sind. Es hängt sehr stark von der Organisation und den mit der Funktion verbundenen Aufgaben ab.

Was niemals passieren darf, ist, dass der SM und der PO dieselbe Person sind. Es kann also ein PM/PO oder ein PM/SM sein, aber niemals ein einzelner PM - ich denke, das war der größte Fehler dessen, was wir heute traditionelles Management nennen, nämlich zu versuchen, den PM dazu zu bringen, beides zu tun. Ein Punkt für die Agilisten!

Vor nicht allzu langer Zeit habe ich einen Artikel über die Rolle von PM und SM geschrieben, der Sie interessieren könnte: Wenn Sie agil arbeiten, brauchen Sie keine Projektmanager.

Entwickler - Entwickler

Arbeiter auf einer Baustelle stellen Scrum-Entwickler dar.

Nun, obwohl Scrum nicht speziell von Entwicklung spricht, ist es nicht gelungen, einen anderen Begriff für das Team von Menschen zu finden, die die eigentliche Arbeit machen. Das heißt, wenn der PO derjenige ist, der anfordert, und der SM derjenige ist, der vermittelt, sind die Entwickler diejenigen, die tun.

Es handelt sich um ein multidisziplinäres und hoffentlich autonomes Team. Es sollten nicht zu viele Leute sein, aber auch nicht zu wenige - sagen wir mal so etwas wie 3 bis 9, oder 5 bis 7, oder... nun, Sie verstehen schon. Wenn es zu viele sind, können sie sich nicht als Team koordinieren, wenn es zu wenige sind, können sie in kurzer Zeit keine Ergebnisse erzielen.

Abschließende Überlegungen

Wie Sie sehen, ist Scrum kein komplexer oder schwer zu verstehender Rahmen. Es ist relativ unkompliziert und basiert auf einem sehr einfachen Modell der Teamleitung und Rollentrennung. Es erinnert mich sehr an das Buch Tod durch Begegnung. Im Scrum Guide, dem kanonischen Leitfaden für Scrum, heißt es dazu:

Scrum ist kostenlos... Das Scrum-Framework ist unveränderlich. Es ist zwar möglich, nur Teile von Scrum zu implementieren, aber die daraus resultierenden ist nicht Scrum. Scrum existiert nur in seiner Gesamtheit und funktioniert gut als Container für andere Techniken, Methoden und Praktiken.

Scrum-Leitfaden 2020

Teilen!

Kommentare und Anmerkungen des Autors[+]

Standardbild
Alberto Dominguez
Führung von Teams von der Theorie bis zur tatsächlichen und nachhaltigen Bereitstellung innovativer IT-Produkte und -Dienstleistungen.
Artikel: 33

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

de_DE