Seminar buchen

Schlagwort: weihnachtsbonus

Veröffentlicht am

Wie überzeuge ich mein Gegenüber?

Ich habe doch die besseren Argumente?

 

Die Konfrontation und Auseinandersetzung mit meinem Gegenüber ist meistens nicht so fruchtvoll, wie ich mir das erhofft habe.

 

Wir sezieren einen spannenden Artikel zum Thema und schauen hinter die psychologischen Gegebenheiten, wieso uns Fakten meistens nicht überzeugen und was das für uns als agile Coaches, Scrum Master, Manager und Teammitglieder heißt.

Jasmine

Herzlich willkommen zum Agile Growth Podcast! Schön, dass du mit dabei bist. Heute beschäftigen wir uns mit dem Thema, warum Menschen ihre Meinung einfach nicht ändern, obwohl ich die geilsten Argumente habe.

 

Sprecher

Herzlich Willkommen zum Agile Growth Podcast, dem Podcast für alle Agil Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.

 

Kai

Herzlich willkommen zum Agile Growth Podcast – Hier sind Jasmine und Kai und wir helfen Menschen dabei, die versprechen Agiler Vorgehensweisen in der Praxis einzulösen. Ohne IT-Wissen vorauszusetzen. Schön, dass du zuhörst zu dieser Folge.

 

Jasmine

Wir sind angekommen im Jahr 2022. Irgendwie zumindest für uns ist das Jahr 2021 irgendwie verflogen. Gar nicht so richtig präsent gewesen. Und deswegen freuen wir uns auf einen frischen, bewussteren Start ins Jahr 2022. Wir haben hier ganz, ganz viel vor, haben uns tolle Ziele gesetzt und ich hoffe, du auch. Und eins unserer Ziele ist wieder ganz, ganz regelmäßig zu podcasten, zu Themen, die uns gerade umtreiben und beschäftigen. Und vielleicht bist du auch schon in der Situation gewesen, du hast ein Gegenüber gehabt oder viele Gegenüber. Du hast dich vorbereitet. Du hast gute Argumente zur Hand, warum wir jetzt die eine oder die andere Entscheidung treffen können. Und dein Gegenüber hat einfach eine andere Meinung. Und es lässt sich auch nicht umstimmen, obwohl du ganz objektiv die besseren Argumente hast und vielleicht sogar recht hast.

 

Kai

Jetzt gibt es ja schon auch viel Debattenkultur oder Argumente oder auch Talkshows, wo man sieht, dass die Leute irgendwie Argumente vorbringen. Und das ist ja auch eine ganz alte Tradition, dass man um Dinge argumentiert, um seinen Punkt zu machen. Und da geht es ja darum, wenn dann zwei Menschen miteinander sprechen, wer gewinnt? Also eigentlich so der Austausch miteinander, darum wer hat jetzt Recht? Und irgendwie gibt es ja auch das Zuhören, wo es darum geht, den anderen zu verstehen, also beim Gegenüber zu sein, was irgendwie was anderes ist, als in diesen Wettstreit miteinander zu gehen.

 

Jasmine

Und wenn du dich jetzt fragst Was hat denn das jetzt so mit Agilität und so weiter zu tun? Wir finden, sehr, sehr viel, weil eine der Fragen, die uns ganz oft gestellt wird, sei es beim Kunden oder in öffentlichen Trainings, ist. Habt ihr eine Argumentationshilfe für uns, wie wir Führungskräfte, Vorstände, Geschäftsführer, füge ein, was du einfügen möchtest, Teams überzeugen können, warum Scrum gut ist. Warum Agil gut ist. Warum wir Kanban machen sollen. Und ja, natürlich haben wir das. Wir haben schlagende Argumente. Wir bauen im Training ja ganz viel Wissen auf, warum in gewissen Kontexten Agilität gut ist, warum sie uns hilft, warum die Werkzeuge, die wir in diesem ganzen Agile Space haben, uns helfen, der Komplexität in einer komplexen Domäne zu begegnen. Und nichtsdestotrotz helfen sie dir nichts, sobald du in diese Debatte einsteigt von – wer gewinnt. Darum soll diese Podcastfolge gehen.

 

Kai

Inspiriert hat uns ein Artikel dazu von James Clear. Und der heißt – Why Facts Don’t change our Minds. Und so die grundlegende Aussage daran ist, dass wir ja schon auch ein Interesse an Wahrheit haben, aber es unglaublich hilfreich ist, als Mensch auch einem sozialen Tribe anzugehören, also einer Gemeinschaft von anderen Menschen – und die Frage ist sozusagen, was nützt einem eine Information? Und manchmal tauschen wir deswegen ganz gerne die Wahrheit aus gegen etwas, was auch praktisch ist, zu glauben und zwar sozial praktisch zu glauben. Etwas, was uns einen gewissen Stellenwert innerhalb einer Gruppe bringt oder mit den Menschen, mit denen wir da zusammen sind. Da schludern wir dann so ein bisschen und verzichten dann auch mal darauf, vielleicht so das wirklich Wahre oder objektive Wahre zu glauben, sofern es das gibt. Da könnte man jetzt noch ein bisschen philosophisch zu werden, weil wir eben auch einen Vorteil davon haben, einer Gruppe zuzugehören. Und dieser Vorteil ist eben ein ganz alter, weil wir Menschen so lange schon aufeinander angewiesen sind und ja auch so geboren werden als Resonanzwesen,

 

Kai

Wesen, die schon von der ersten Minute an Mama oder Papa brauchen, um uns einen eigenen präfrontalen Cortex zusammenzubauen. Also dieses Zusammengehören gibt es schon ganz lange und das ist auch eine wichtige Triebfeder für uns, dass wir uns nicht explodieren von einem Tribe. Und weil das eben treibt, machen wir manchmal auch einen Kompromiss bei der Wahrheit.

 

Jasmine

Und das heißt jetzt nicht, dass wir uns dann selber belügen oder dass ein bewusster Prozess ist, sondern das ist ein sehr, sehr unbewusster Prozess. Ich habe meine Daten und Fakten, auf die ich meine Meinung beruhe, in meinem Kopf und wahrscheinlich entsprechen die nicht unbedingt der objektiven Wahrheit, insofern es die denn gibt, weil wir Menschen einfach und da gehen wir jetzt so in diese Informationsverarbeitung, etc., Kahnemann hat da ganz viel coole Sachen dazu gemacht, weil wir Menschen einfach auch nicht gut sind in der Informationsverarbeitung. Wir können große Datenmengen nicht gut verarbeiten. Wir glauben Geschichten eher, als dass wir Zahlen glauben etc. Wir sind nicht sehr rational in der Datenverarbeitung per se schon mal! Und dann habe ich meine Fakten, auf die meine Meinung beruht. Die ist in meiner Historie drin. Das ist unterbewusst. Darauf greift mein Gehirn zurück und die bindet mich natürlich auch an die Gruppe, der ich zugehöre. Zum Beispiel in meiner Firma. Also wenn du dieses Argument hörst von – das haben wir immer schon so gemacht. Für viele ist das ja so das – boah, das ist voll das Totschlagargument, oder

 

Jasmine

Oh, mit so Leuten kann ich nicht arbeiten. Da ist die Frage – was hilft mir, wenn ich dann so ein Ausruf mache? Oder was hilft mir diese diese Haltung dagegen? Ich arbeite gerne mit solchen Leuten zusammen. Triggert mich das? Ja, es triggert mich enorm. Nervt es mich, dass die Leute diese Einstellung haben? Ja, natürlich. Aber was mir diese Einstellung eigentlich sagt, ist – ich fühle mich gerade wohl, wo ich bin. Ich gehöre hier einer Gemeinschaft zu, die Dinge in einer gewissen Weise, geregelter Weise für mich tun. Und das gibt mir eine Einordnung. Das hilft mir, meinen Alltag zu bestreiten. Und jetzt kommst du und sagst: Wir tun’s anders oder wir sollen es anders tun oder das, was wir getan haben, ist schlecht. Das heißt, was ich dann mache, wenn ich komme und sage: Komm, lass jetzt mal Agile oder lass mal Scrum. Und der andere sagt nö, wir haben das immer schon so gemacht, ist zu sagen – Bitte verlass mal deine Gemeinschaft und komm zu meiner Gemeinschaft und mach Scrum.

 

Jasmine

Das ist ein Riesenschritt für einen Menschen.

 

Kai

Deswegen starten wir auch ganz oft bei der Einführung von Agilität, indem wir das dann ja einfach mal begreifbar machen in Simulationen und so weiter und dann einfach die Frage stellen – Wollt ihr das in diesem Team machen? Und mit der Entscheidung, es dann zu machen, sind wir natürlich auch in einer Form von neuer  „Schicksalsgemeinschaft“ dann, für dieses Experiment, diese Zeit, wo wir das mal ausprobieren wollen. Also da ergibt sich dann schon auch ein mitverändern. Das Team ist ja schon eine vielleicht vorher bestehende Gemeinschaft, wenn sich das jetzt nicht gerade für das Projekt neu formt und das dann da mitzugehen und auch wir, die sich als Agile Coaches da einfügen in diese Gemeinschaft, sind dann Menschen, die das beeinflussen. Und wahrscheinlich ist es am einfachsten zu lernen von den Leuten, die so 98 prozent ähnlich sind. Zu mir selbst – das ist auch was, was der James Clear da in seinem Artikel herausstellt. Weil wenn man eh schon so nah dran ist an dem anderen und spürt, wir schwingen gut miteinander, dann kann man auch mal eine Idee mehr auch noch mitnehmen.

 

Kai

Das ist dann gar nicht so schwierig, das dann noch für sich zu verinnerlichen. Das heißt so dieses direkte Umfeld und vielleicht hast du dieses Sprichwort auch schon mal gehört, ist so. Ja, du wirst im Durchschnitt zu dem Menschen, der so im Schnitt ist wie die fünf, sechs Leute, die ganz nah um dich herum sind. Deswegen prägt ja auch Familie so sehr, wenn man groß wird oder sonst in der Firma. Nur wenn du ein kleines Unternehmen das was eine sehr starke Startup ähnliche Kultur hat, dann prägt das gegenseitig sehr, sehr stark. Oder deine Team Kultur, die dich täglich mit beeinflusst. Das sind alles so Quellen, von denen du Neuigkeit, Innovation viel, viel leichter adaptieren kannst, wenn du dich dem zugehörig fühlst.

 

Jasmine

Also was machen wir jetzt mit dem Menschen, der sagt – das haben wir hier immer schon so gemacht? Wir versuchen zu ergründen, was sind denn die positiven Dinge, die für dich rausgesprungen sind oder rausspringen, wenn du Dinge so tust, wie du sie immer schon gemacht hast? Welcher Gemeinschaft gehörst du gerade an, die die Dinge so tut und warum tut ihr sie so? Und dann mache ich eben nicht das, was viele machen – ich hau mit Fakten dagegen und sage, warum das alles doof ist, was sie tun. Weil was ich dann ja tue ist zu sagen: Deine Gemeinschaft ist doof, deine Gruppe ist doof. Was du bis jetzt getan hast, ist doof. Sprich ich gehe direkt auf das Selbstkonzept des Menschen, auch wenn ich mir das Schönrede und das verrationalisiere und sage Boah, aber rational gesehen ist es ja alles doof. Also bin ich im Recht und dann bin ich wieder in diesem Streit drin. Wer hat jetzt recht? Aber beide, wie wir beide, haben subjektiv für uns Recht. In unserer Gemeinschaft macht das, was wir tun halt einfach mehr Sinn.

 

Jasmine

Also das zusammen zu suchen. Wo sind wir uns denn ähnlich? Wo haben wir gleiche Interessen? Wo können wir gemeinsam eine Interessengemeinschaft bilden, um dann zu gucken – wie tun wir die Dinge anders? Wo können wir im Sinne der Interessensgemeinschaft vielleicht Dinge loslassen, die wir immer schon so getan haben und neue Dinge dazunehmen? Weil dann macht es viel weniger Angst. Die Angst, die in unserem Gehirn entsteht, ist, wenn ich die Dinge jetzt nicht mehr so tue, wie wir sie immer getan haben, und meinen Kollegen, meinen Teamkollegen, meiner Abteilung, wem auch immer ich dazugehöre, den Rücken drehe, dann bin ich auf einmal alleine. Und was unser Gehirn dann damit macht, ist – dann bin ich nicht mehr überlebensfähig. Wir wissen natürlich rational, dass das Murks ist. Natürlich sind wir überlebensfähig. Ist vielleicht doch nicht mehr so schön, aber überlebensfähig bleiben wir. Aber unser Gehirn weiß es nicht.

 

Kai

Ich hatte mal in so einer Multi Teams Scrum Einführung das Vergnügen mit dem Team zu arbeiten, wo die letzten Mohikaner irgendwie drauf waren. Also die Leute die irgendwie so weg gesprungen waren immer die irgendwie absolut keine Lust hatten. Mohikaner kann man eigentlich noch sagen heutzutage? Ich weiß nicht wie man die, die noch übrig waren und die, die eigentlich gar keine Lust hatten auf Scrum. Und ja, da war dann irgendwie einer drin, der wirklich auch relativ offen kundgetan hat, dass er das ziemlich blöd findet, was hier gerade alles in der Firma passiert. Und ich hatte, das ist auch schon eine ganze Weile her, ich hatte. Ich hatte damals den Impuls, den muss ich irgendwie überzeugen, den muss ich irgendwie reinziehen, den muss ich irgendwie überreden und bin dann noch abends länger geblieben und habe immer geguckt, dass wir irgendeine Verbindung miteinander finden. Wir hatten nicht so eine unglaublich gute Chemie miteinander, aber das kam dann so mittelfristig und – lange Geschichte kurz. Das hat bis zum Ende nicht wirklich funktioniert. Und dazu gibt es auch einen spannenden Punkt in dem Artikel von James Clear, weil der sagt Na ja, die heißesten Debatten gibt es halt zwischen den Leuten, die an dem unterschiedlichen Ende des Spektrums sind, also Gegner von Agile und Agile Fans, könnte man sagen.

 

Kai

Aber das meiste Lernen passiert zwischen den Leuten, die sich ähnlich sind, also die eher nah beieinander sind in den Gedanken. Wenn man das mal weiterspinnt, ist halt so die Frage als Agile Coach oder jemand, der auf so einen Agilen Raum irgendwie einwirken will. Mit wem beschäftige ich mich vorwiegend? Wo stürze sich die meiste Energie drauf? Und auch wenn wir diesen Impuls immer wieder haben, dass wir Leute, die im Widerstand sind, reinziehen wollen, die einfach überzeugen wollen, noch ein bisschen länger mit ihnen reden, damit das irgendwie funktioniert, ist das Fruchtbarere doch mit denen zu arbeiten, die wollen oder zumindest mal bereit sind, etwas auszuprobieren und den anderen denen irgendwie zu begegnen in dieser Konfrontation. Aber da jetzt den Fokus darauf zu legen, das hat auch bei dem Team damals gar nichts gebracht, da die meiste Energie drauf zu setzen.

 

Jasmine

Und das hat auch wieder einen Hintergrund. Warum geschieht das meiste Lernen bei Menschen, die mir doch ähnlich sind oder? Oder die irgendwo in diesem Spektrum an Gegensätzlichkeit nicht ganz an den Außenquellen sind? Das ist, weil mein Selbstkonzept das gar nicht integrieren kann. Das ist so ein bisschen. Ich habe im Studium haben sie mir damals das Beispiel genannt, das für mich total plausibel ist. Ich weiß nicht, ob es für dich plausibel ist, aber wenn man einem Menschen ein Kompliment macht und dieser Mensch ein gewisses Selbstkonzept hat und dieses Kompliment sehr, sehr weit außerhalb dieses Selbstkonzept ist und das es übrigens auch mit jeglichem Feedback so dann entsteht eine kognitive Dissonanz in dem Menschen und etwas, was unser, unser Gehirn, unser Sein überhaupt nicht mag, sind kognitive Dissonanzen. Und damit können wir nicht gut umgehen, wenn die zu groß sind. Das heißt als ganz einfaches Beispiel – wenn ich mich als Mensch als eher dick empfinde oder als  fülliger empfinde und ich das Kompliment bekomme Oh, du siehst total schlank aus oder du siehst total gut aus.

 

Jasmine

Dann erzeugt das eine Dissonanz in mir drin. Und  das will mein Gehirn nicht und deswegen kann ich auf zwei Arten damit umgehen als Mensch. Entweder bin ich dann selbst abwertend dadrin. Ah, siehst du. Der oder die macht das nur, weil der oder die nicht will, dass du weißt, wie fett du eigentlich bist. Also wirklich, diese Selbstabwertungs-Spirale könnte ich gehen oder ich kann die andere Spirale gehen, das ich meinte, dass ich den Kompliment oder Feedback-Geber abwerte und sage, der hat ja überhaupt keine Ahnung. Jetzt wenn es darum geht, eine Meinung zu ändern, werde ich wahrscheinlich nicht selbst abwertend einhergehen. Wenn wir an einem ganz anderen Spektrum von einer Meinung sind, also Anti-Agilisten gegen Agilisten, sondern die werden anfangen die Agilisten abzuwerten. Und da kommen wir ja ganz schnell in diese Stereotypisierung von ähm, ich weiß nicht, das sind die Baumumarmer und die Hippies. Oder die haben ja von nichts eine Ahnung. Die wissen ja gar nicht, wie richtiges Business läuft, oder

 

Jasmine

Ist ja alles schön und gut, wenn man sich nur um Innovations Zeugs kümmern kann. Aber wir bringen halt das Geld rein hier. Was auch immer ihr in eurer Firma alles hört zu den Agilisten vs. die andere Stereotypisierung und das ist ja das ist eine ganz aktive Abwertung des Gegenübers, der äußeren Gruppe, die wir tun. Das sind die, die nie was verändern wollen. Die stehen der Innovation im Weg. Ja, die griesgrämigen alten weißen Männer und so weiter. Und wenn unser Gehirn das schon macht, das Gegenüber so abzuwerten, dann sind wir natürlich auch nicht offen dafür, dass wir vom Gegenüber lernen. Das heißt zwei Punkte hier – das eine ist Ich kann mich hinterfragen – wo, wo investiere ich meine Energie rein, von wem kann ich lernen, wer kann von mir lernen? Und das vielleicht für mich auch immer weiter auszuweiten und auch sehr, sehr achtsam als zweiter Punkt damit zu sein – wo werte ich andere Menschen ab? Und vielleicht mal ganz bewusst dahin zu gehen, wo ich Menschen abwerte und sage – Okay.

 

Jasmine

Wenn ich gerade weiß, dass ich das tue. Vielleicht kann ich da ins Gespräch gehen und einfach mal von diesem Menschen lernen. Und es geht nicht darum, dass ich die Meinung des Menschen ändere oder viel von mir preisgebe, sondern dass ich einfach mal lerne. Warum ist der an dem Punkt, wo er ist? Welcher Gemeinschaft gehört er an? Was für positive Effekte entstehen durch die Haltung, die dieser Mensch hat, also wirklich zu lernen – diesen Abwertungen ganz, ganz, ganz bewusst zu begegnen. Und dann mit dieser Information zurück zu gehen und zu gucken- und was müssten wir diesem Menschen bieten, damit er einen Schritt auf uns zukommen kann?

 

Kai

Ja, Widerstand ist auch eine Information. Sagen die Systemiker ja gern dazu. Das ist natürlich manchmal emotional einfach herausfordernd, dann trotzdem mit der Konfrontation umzugehen. Da greift dann wieder das ganze Thema – wie bin ich sozialisiert in Konflikten? Wir hatten auch schon mal eine Podcastfolge über Konflikte, um dieses Störfeuer der Auseinandersetzung einfach auszuhalten und dann in diese konstruktive Phase reinzugehen, nachdem man es verarbeitet hat und zu schauen, wie es mir das gerade beschrieben hat. Wie kann ich da eine andere Form von Gemeinschaft schaffen? Wie kann ich mich an den gleichen Tisch setzen? Und ich glaube, das ist jetzt in der Corona-Zeit, mit dem an den gleichen Tisch setzen, mit digitalen Kaffees, ja, irgendwie funktioniert das auch. Das war noch so ein bisschen einfacher, als wir so in den gleichen Firmengebäuden rum gewandelt sind und uns tatsächlich vielleicht mal in der Cafeteria oder beim Essen hingesetzt haben. Jetzt muss man halt schauen, wie kriegt man das irgendwie hin, je nach aktueller Firmenkultur.

 

Jasmine

Wenn ich persönlich das mache, muss ich in einem sehr, sehr guten Zustand sein und da darf ich auch sehr achtsam mit mir selber sein. Kann ich das heute gerade oder kann ich das nicht? Weil wenn ich gerade nicht in einem guten Zustand bin, wenn unsere Tochter uns nachts aufgeweckt hat und ich nicht ausgeschlafen bin etc., dann ist es für mich sehr, sehr schwierig, mit Menschen umzugehen, die sehr anders sind als ich. Da habe ich gelernt, darf ich sehr ehrlich zu mir sein. Das kann bei jedem anders sein. Bei mir ist es so, das heißt, ich bin da sehr achtsam mit mir selber. Wann kann ich das leisten? Wann möchte ich das leisten und und wann kann ich das gerade nicht leisten? Also wann? Wann brauche ich auch einfach mal die heile Welt? Wann umgebe ich mich mal einfach mit meinen Agilisten? Und wir erträumen uns die Welt da draus nehm ich auch Kraft? Und das ist auch ein Teil dieses sich Gemeinschaften aufbauen und dann Leute in die Gemeinschaft einladen und dieses sich    zusammen an einen Tisch setzen.

 

Jasmine

Das ist in Corona sehr viel schwieriger geworden, aber das ist eine ganz, ganz, ganz einfache und gängige Methode, wie wir Gemeinschaft stiften können. Und das vielleicht jetzt schon zum Abschluss von diesem Podcast. Wenn wir wollen, dass Menschen ihre Meinung ändern, dann geht es oft nicht darum, ihnen Fakten vorzuführen, sondern es geht darum, eine neue Gemeinschaft für sie zu erschaffen. Und egal welche Meinung wir haben, wenn wir es schaffen, eine gemeinsame Mahlzeit einzunehmen, ein Spaziergang zusammen zu machen und da dürfen wir bestimmt einfach noch lernen. Wie funktioniert es Corona konform? Oder hoffentlich ist dann die lange nur Homeoffice Zeit auch irgendwie mal vorbei. Dass wir immer wieder so Gemeinschaftsstiftende Elemente integrieren können, weil dann wenn wir eine neue Gemeinschaft zusammen erschaffen, dann sind wir auch bereit unsere Meinung zu ändern und eine gemeinsame neue Wahrheit für uns zu finden.

 

Kai

So, damit hoffen wir, dass wir wieder ein weiteres Puzzlestück gegeben haben, was du für dich benutzen kannst. Zur Arbeit in agilen Umfeldern oder solche, die es noch werden dürfen. Und wenn du es lieber ein bisschen praktischer hättest und ein bisschen mehr Fleisch am Knochen oder Seitan am Reis, dann ist vielleicht die beste Variante dafür unsere liebevoll erdachte und konzipierte Agile Coach Ausbildung, die jetzt im Februar startet im Pilot. Gibt es ein zwei -Wochenend Seminar dazu. Von Freitag bis sonntags, wo wir sehr intensiv uns reinknien in die Themen, die einen Advanced Certified Scrum Master beschäftigen. Und wenn du dazu noch Fragen hast, guck einfach auf agilegrowth.de , da haben wir schon relativ viel dazu geschrieben und schreib uns an, so dass wir Fragen im direkten Dialog mit dir einfach klären können.

 

Jasmine

Wir wünschen dir eine ganz wunderbare Woche und freuen uns aufs nächste Mal.

 

Veröffentlicht am

(X-Mas-Bonus) – Der Scrum-Guide als AudioBook (Deutsche Version) – Gelesen von Kai H. Simons

Der Scrum Guide enthält die gültigen Spielregeln, nach denen das “kollaborative Spiel” der Scrum-Produktentwicklung gespielt wird. 


In der deutschen Fassung vom Oktober 2020 sind wieder einige Änderungen vorgenommen worden, um den Einsatz des beliebten Scrum-Management-Rahmenwerks zu optimieren. 

Hier klicken für die Text-Version des Scrum-Guides

Der Sinn des Scrum Guides

 

Wir haben Scrum in den frühen 1990er‐Jahren entwickelt. Wir haben die erste Version des Scrum Guides im Jahr 2010 geschrieben, um Menschen auf der ganzen Welt dabei zu helfen, Scrum zu verstehen. Wir haben den Guide seitdem durch kleine, funktionale Aktualisierungen weiterentwickelt. Wir stehen gemeinsam dahinter. Der Scrum Guide enthält die Definition von Scrum. Jedes Element von Scrum dient einem bestimmten Zweck, der für den Gesamtwert und die mit Scrum erzielten Ergebnisse wesentlich ist. Den Kern oder die Grundideen von Scrum zu verändern, Elemente wegzulassen oder den Regeln von Scrum nicht zu folgen, verdeckt Probleme, begrenzt den Nutzen und macht Scrum im Zweifel sogar nutzlos.    Wir verfolgen den zunehmenden Einsatz von Scrum in einer stetig komplexer werdenden Welt. Wir sehen demütig, wie Scrum in zahlreichen Bereichen komplexer Arbeit über die Softwareentwicklung hinaus ‐ wo Scrum seine Wurzeln hat ‐ eingesetzt wird. Während sich die Verwendung von Scrum weiter verbreitet, wird diese Arbeit von Entwickler:innen, Forscher:innen, Analyst:innen, Wissenschaftler:innen und anderen Spezialist:innen getan. Wir verwenden das Wort “Developer:innen” in Scrum nicht, um jemanden auszuschließen, sondern um zu vereinfachen. Wer auch immer vom Einsatz von Scrum profitiert, soll sich angesprochen fühlen. Beim Einsatz von Scrum können Muster, Prozesse und Erkenntnisse angewendet und entwickelt werden, die zum Scrum‐Rahmenwerk passen, wie es in diesem Dokument beschrieben ist. Ihre Beschreibung geht über den Zweck des Scrum Guides hinaus, da sie kontextabhängig sind und sich, je nachdem wie Scrum eingesetzt wird, stark unterscheiden. Solche Taktiken für die Anwendung innerhalb des Scrum‐ Rahmenwerks variieren stark und werden an anderer Stelle beschrieben.   

 

Ken Schwaber & Jeff Sutherland, November 2020

 

Scrum‐Definition Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.   Kurz gesagt fordert Scrum, dass ein:e Scrum Master:in ein Umfeld fördert, in dem    1. ein:e Product Owner:in die Arbeit für ein komplexes Problem in ein Product Backlog einsortiert; 2. das Scrum Team aus einer Auswahl dieser Arbeit innerhalb eines Sprints ein wertvolles Increment erzeugt; 3. das Scrum Team und dessen Stakeholder:innen die Ergebnisse überprüfen und für den nächsten Sprint anpassen; 4. diese Schritte wiederholt werden. Scrum ist einfach. Probiere es so aus, wie es ist, und finde heraus, ob seine Philosophie, Theorie und Struktur dabei helfen, Ziele zu erreichen und Wert zu schaffen. Das Scrum‐Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum‐Theorie erforderlich sind. Scrum baut auf der kollektiven Intelligenz der Personen auf, die es anwenden. Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Regeln von Scrum ihre Beziehungen und Interaktionen. Innerhalb des Rahmenwerks können verschiedene Prozesse, Techniken und Methoden eingesetzt werden. Scrum umhüllt bestehende Praktiken oder macht sie überflüssig. Scrum macht die relative Wirksamkeit des aktuellen Managements, der Umgebung und der Arbeitstechniken sichtbar, so dass Verbesserungen vorgenommen werden können.

 

Scrum‐Theorie Scrum basiert auf Empirie und Lean Thinking. Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf der Grundlage von Beobachtungen getroffen werden. Lean Thinking reduziert Verschwendung und fokussiert auf das Wesentliche. Scrum verwendet einen iterativen, inkrementellen Ansatz zur Optimierung der Vorhersagbarkeit und zur Risikokontrolle. Scrum setzt auf Personengruppen, die gemeinsam über alle Fähigkeiten und Fachkenntnisse verfügen, um die Arbeit zu erledigen und solche Fähigkeiten im Bedarfsfall zu teilen oder zu erwerben. Scrum kombiniert vier formale Events zur Überprüfung und Anpassung innerhalb eines umspannenden Events, des Sprints. Diese Events funktionieren, weil sie die empirischen Scrum‐Säulen Transparenz, Überprüfung und Anpassung implementieren. 4 Transparenz Der sich entwickelnde Prozess und die entstehende Arbeit müssen sowohl für diejenigen sichtbar sein, die die Arbeit ausführen, als auch für diejenigen, die die Arbeit empfangen. Bei Scrum basieren wichtige Entscheidungen auf dem wahrgenommenen Zustand seiner drei formalen Artefakte. Artefakte, die wenig transparent sind, können zu Entscheidungen führen, die den Wert mindern und das Risiko erhöhen. Transparenz ermöglicht Überprüfung. Eine Überprüfung ohne Transparenz ist irreführend und verschwenderisch. Überprüfung Die Scrum‐Artefakte und der Fortschritt in Richtung der vereinbarten Ziele müssen häufig und sorgfältig überprüft werden, um potenziell unerwünschte Abweichungen oder Probleme aufzudecken. Um bei der Überprüfung zu helfen, bietet Scrum eine Kadenz in Form seiner fünf Events.    Überprüfung ermöglicht Anpassung. Überprüfung ohne Anpassung wird als unsinnig betrachtet. Scrum Events sind darauf ausgerichtet, Veränderungen zu bewirken. Anpassung Wenn einzelne Aspekte eines Prozesses von akzeptablen Grenzen abweichen oder wenn das resultierende Produkt nicht akzeptabel ist, müssen der angewandte Prozess oder die produzierten Ergebnisse angepasst werden. Die Anpassung muss so schnell wie möglich erfolgen, um weitere Abweichungen zu minimieren.    Die Anpassung wird schwieriger, wenn die beteiligten Personen nicht bevollmächtigt (empowered) sind oder sich nicht selbst managen können. Von einem Scrum Team wird erwartet, dass es sich in dem Moment anpasst, in dem es durch Überprüfung etwas Neues lernt. Scrum‐Werte Die erfolgreiche Anwendung von Scrum hängt davon ab, dass die Menschen immer besser in der Lage sind, fünf Werte zu leben: Commitment, Fokus, Offenheit, Respekt und Mut Das Scrum Team committet sich, seine Ziele zu erreichen und sich gegenseitig zu unterstützen. Sein primärer Fokus liegt auf der Arbeit des Sprints, um den bestmöglichen Fortschritt in Richtung dieser 5 Ziele zu bewirken. Das Scrum Team und dessen Stakeholder:innen sind offen in Bezug auf die Arbeit und die Herausforderungen. Die Mitglieder des Scrum Teams respektieren sich gegenseitig als fähige, unabhängige Personen und werden als solche auch von den Menschen, mit denen sie zusammenarbeiten, respektiert. Die Mitglieder des Scrum Teams haben den Mut, das Richtige zu tun: an schwierigen Problemen zu arbeiten. Diese Werte geben dem Scrum Team die Richtung vor, was seine Arbeit, seine Handlungen und sein Verhalten betrifft. Die Entscheidungen, die getroffen werden, die Schritte, die unternommen werden, und die Art und Weise, wie Scrum angewendet wird, sollten diese Werte stärken und nicht schmälern oder untergraben. Die Mitglieder des Scrum Teams lernen und erforschen die Werte, während sie in den Events und mit den Artefakten von Scrum arbeiten. Wenn diese Werte durch das Scrum Team und die Menschen, mit denen es arbeitet, verkörpert werden, werden die empirischen Scrum‐Säulen Transparenz, Überprüfung und Anpassung lebendig und bauen Vertrauen auf. Scrum Team Der zentrale Bestandteil von Scrum ist ein kleines Team von Menschen, ein Scrum Team. Das Scrum Team besteht aus einem:einer Scrum Master:in, einem:einer Product Owner:in und Developer:innen. Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien. Es handelt sich um eine geschlossene Einheit von Fachleuten, die sich auf ein Ziel konzentrieren, das Produkt‐Ziel. Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen. Sie managen sich außerdem selbst, d.h. sie entscheiden intern, wer was wann und wie macht. Das Scrum Team ist klein genug, um flink zu bleiben und groß genug, um innerhalb eines Sprints bedeutsame Arbeit fertigzustellen, üblicherweise 10 oder weniger Personen. Im Allgemeinen haben wir festgestellt, dass kleinere Teams besser kommunizieren und produktiver sind. Wenn Scrum Teams zu groß werden, sollten sie in Erwägung ziehen, sich in mehrere zusammengehörende Scrum Teams zu reorganisieren, die sich alle auf dasselbe Produkt konzentrieren. Daher sollten sie Produkt‐Ziel, Product Backlog und Product Owner:in teilen.   Das Scrum Team ist umsetzungsverantwortlich (responsible) für alle produktbezogenen Aktivitäten: Zusammenarbeit mit den Stakeholder:innen, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte. Es ist von der Organisation so aufgebaut und befähigt, dass es seine Arbeit selbst steuert. Das Arbeiten in Sprints mit einer nachhaltigen Geschwindigkeit verbessert den Fokus und die Kontinuität des Scrum Teams.   Das gesamte Scrum Team ist ergebnisverantwortlich (accountable), in jedem Sprint ein wertvolles, nützliches Increment zu schaffen. Scrum definiert drei spezifische Ergebnisverantwortlichkeiten innerhalb des Scrum Teams:  Developer:innen, Product Owner:in und Scrum Master:in 6 Developer:innen Developer:innen sind jene Personen im Scrum Team, die sich der Aufgabe verschrieben haben, jeden Sprint jeden Aspekt eines nutzbaren Increments zu schaffen. Die spezifischen Fähigkeiten, die von den Developer:innen benötigt werden, sind oft breit gefächert und variieren je nach Arbeitskontext. Die Developer:innen sind jedoch immer ergebnisverantwortlich dafür, ● einen Plan für den Sprint zu erstellen, das Sprint Backlog; ● Qualität durch die Einhaltung einer Definition of Done einzubringen; ● täglich ihren Plan zur Erreichung des Sprint‐Ziels anzupassen; und ● sich wechselseitig als Expert:innen zur Verantwortung zu ziehen. Product Owner:in Der:die Product Owner:in ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt. Wie dies geschieht, kann je nach Organisation, Scrum Team und Individuum sehr unterschiedlich sein.    Der:die Product Owner:in ist auch für ein effektives Product‐Backlog‐Management ergebnisverantwortlich, das Folgendes umfasst: ● das Produkt‐Ziel zu entwickeln und explizit zu kommunizieren; ● die Product‐Backlog‐Einträge zu erstellen und klar zu kommunizieren; ● die Reihenfolge der Product‐Backlog‐Einträge festzulegen; und ● sicherzustellen, dass das Product Backlog transparent, sichtbar und verstanden ist. Der:die Product Owner:in kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der:die Product Owner:in ergebnisverantwortlich.    Damit der:die Product Owner:in Erfolg haben kann, muss die gesamte Organisation seine:ihre Entscheidungen respektieren. Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs sowie durch das überprüfbare Increment beim Sprint Review, sichtbar.    Der:die Product Owner:in ist eine Person, kein Gremium. Der:die Product Owner:in kann die Bedürfnisse vieler Stakeholder:innen im Product Backlog berücksichtigen. Diejenigen, die das Product Backlog ändern möchten, können dies tun, indem sie versuchen, den:die Product Owner:in zu überzeugen. 7 Scrum Master:in Der:die Scrum Master:in ist ergebnisverantwortlich für die Einführung von Scrum, wie es im Scrum Guide definiert ist. Er:sie tut dies, indem er:sie allen dabei hilft, die Scrum‐Theorie und ‐Praxis zu verstehen, sowohl innerhalb des Scrum Teams als auch in der Organisation.    Der:die Scrum Master:in ist ergebnisverantwortlich für die Effektivität des Scrum Teams. Er:sie tut dies, indem er:sie das Scrum Team in die Lage versetzt, seine Praktiken innerhalb des Scrum‐Rahmenwerks zu verbessern.    Scrum Master:innen sind echte Führungskräfte, die dem Scrum Team und der Gesamtorganisation dienen. Der:die Scrum Master:in dient dem Scrum Team auf unterschiedliche Weise, unter anderem dadurch, ● die Teammitglieder in Selbstmanagement und interdisziplinärer Zusammenarbeit zu coachen; ● das Scrum Team bei der Fokussierung auf die Schaffung von hochwertigen Increments zu unterstützen, die der Definition of Done entsprechen; ● die Beseitigung von Hindernissen (impediments) für den Fortschritt des Scrum Teams zu bewirken; und ● sicherzustellen, dass alle Events von Scrum stattfinden, positiv und produktiv sind und innerhalb der Timebox bleiben. Der:die Scrum Master:in dient dem:der Product Owner:in auf unterschiedliche Weise, unter anderem dadurch, ● bei der Suche nach Techniken zur effektiven Definition des Produkt‐Ziels und zum Product‐ Backlog‐Management zu helfen; ● dem Scrum Team dabei zu helfen, die Notwendigkeit klarer und präziser Product‐Backlog‐ Einträge zu verstehen; ● bei der Etablierung einer empirischen Produktplanung für ein komplexes Umfeld zu helfen; und ● die Zusammenarbeit mit Stakeholder:innen nach Wunsch oder Bedarf zu fördern (facilitate). Der:die Scrum Master:in dient der Organisation auf unterschiedliche Weise, unter anderem dadurch,   ● die Organisation bei der Einführung von Scrum zu führen, zu schulen und zu coachen; ● Einführungen von Scrum in der Organisation zu planen und zu empfehlen; ● Mitarbeitende und Stakeholder:innen beim Verständnis und bei der Umsetzung eines empirischen Ansatzes für komplexe Arbeit zu unterstützen; und ● Barrieren zwischen Stakeholder:innen und Scrum Teams zu beseitigen. 8 Scrum Events Der Sprint ist ein Container für alle anderen Events. Jedes Event in Scrum ist eine formelle Gelegenheit, Scrum‐Artefakte zu überprüfen und anzupassen. Diese Events sind speziell darauf ausgelegt, die erforderliche Transparenz zu ermöglichen. Wenn ein Event nicht wie vorgeschrieben durchgeführt wird, verpasst man die Gelegenheit, zu überprüfen und anzupassen. Events werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Meetings, die in Scrum nicht definiert sind, zu minimieren. Optimalerweise werden alle Events zur selben Zeit und am selben Ort abgehalten, um die Komplexität zu reduzieren. Der Sprint Sprints sind der Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden.    Es sind Events mit fester Länge von einem Monat oder weniger, um Konsistenz zu schaffen. Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints.    Alle Arbeiten, die notwendig sind, um das Produkt‐Ziel zu erreichen, einschließlich Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective, finden innerhalb der Sprints statt.   Während des Sprints    ● werden keine Änderungen vorgenommen, die das Sprint‐Ziel gefährden würden; ● nimmt die Qualität nicht ab; ● wird das Product Backlog nach Bedarf verfeinert; und ● kann der Scope (Inhalt und Umfang) geklärt und mit dem:der Product Owner:in neu vereinbart werden, sobald mehr Erkenntnisse vorliegen. Sprints ermöglichen Vorhersagbarkeit, indem sie mindestens jeden Kalendermonat eine Überprüfung und Anpassung der Fortschritte in Richtung eines Produkt‐Ziels gewährleisten. Wenn der Horizont eines Sprints zu lang ist, kann das Sprint‐Ziel hinfällig werden, die Komplexität kann steigen und das Risiko kann zunehmen. Kürzere Sprints können eingesetzt werden, um mehr Lernzyklen zu generieren und das Risiko von Kosten und Aufwand auf einen kleineren Zeitrahmen zu begrenzen. Jeder Sprint kann als ein kurzes Projekt betrachtet werden. Es gibt verschiedene Vorgehensweisen, um den Fortschritt vorherzusagen, wie Burn‐Down‐Charts, Burn‐ Up‐Charts  oder Cumulative‐Flow‐Diagramme. Diese haben sich zwar als nützlich erwiesen, ersetzen jedoch nicht die Bedeutung der Empirie. In komplexen Umgebungen ist unbekannt, was passieren wird. Nur was bereits geschehen ist, kann für eine vorausschauende Entscheidungsfindung genutzt werden.   Ein Sprint könnte abgebrochen werden, wenn das Sprint‐Ziel obsolet wird. Nur der:die Product Owner:in hat die Befugnis, den Sprint abzubrechen. 9 Sprint Planning Das Sprint Planning initiiert den Sprint, indem es die für den Sprint auszuführenden Arbeiten darlegt. Dieser resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum Teams erstellt.    Der:die Product Owner:in stellt sicher, dass die Teilnehmenden vorbereitet sind, die wichtigsten Product‐Backlog‐Einträge zu besprechen, und wie sie dem Produkt‐Ziel zuzuordnen sind. Das Scrum Team kann zu Beratungszwecken auch andere Personen zur Teilnahme am Sprint Planning einladen.    Das Sprint Planning behandelt die folgenden Themen: Thema Eins: Warum ist dieser Sprint wertvoll?   Der:die Product Owner:in schlägt vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Das gesamte Scrum Team arbeitet dann zusammen, um ein Sprint‐Ziel zu definieren, das verdeutlicht, warum der Sprint für die Stakeholder:innen wertvoll ist. Das Sprint‐Ziel muss vor dem Ende des Sprint Plannings finalisiert sein. Thema Zwei: Was kann in diesem Sprint abgeschlossen (Done) werden?   Im Gespräch mit dem:der Product Owner:in wählen die Developer:innen Einträge aus dem Product Backlog aus, die in den aktuellen Sprint aufgenommen werden sollen. Das Scrum Team kann diese Einträge während dieses Prozesses verfeinern, was Verständnis und Vertrauen erhöht. Die Auswahl, wie viel innerhalb eines Sprints abgeschlossen werden kann, kann eine Herausforderung darstellen. Je mehr die Developer:innen jedoch über ihre bisherige Leistung, ihre zukünftige Kapazität und ihre Definition of Done wissen, desto sicherer werden sie in ihren Sprint‐Vorhersagen sein. Thema Drei: Wie wird die ausgewählte Arbeit erledigt?   Für jeden ausgewählten Product‐Backlog‐Eintrag planen die Developer:innen die notwendige Arbeit, um ein Increment zu erstellen, das der Definition of Done entspricht. Dies geschieht oft durch Zerlegung von Product‐Backlog‐Einträgen in kleinere Arbeitseinheiten von einem Tag oder weniger. Wie dies geschieht, liegt im alleinigen Ermessen der Developer:innen. Niemand sonst sagt ihnen, wie sie Product‐Backlog‐ Einträge in Increments von Wert umwandeln sollen. Das Sprint‐Ziel, die für den Sprint ausgewählten Product‐Backlog‐Einträge und der Plan für deren Lieferung werden zusammenfassend als Sprint Backlog bezeichnet.    Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist das Event in der Regel kürzer. 10 Daily Scrum Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung des Sprint‐Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren.    Das Daily Scrum ist ein 15‐minütiges Event für die Developer:innen des Scrum Teams. Um die Komplexität zu reduzieren, wird es an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichen Ort abgehalten. Falls der:die Product Owner:in oder der:die Scrum Master:in aktiv an Einträgen des Sprint Backlogs arbeitet, nimmt er:sie als Developer:in teil. Die Developer:innen können Struktur und Techniken beliebig wählen, solange ihr Daily Scrum sich auf den Fortschritt in Richtung des Sprint‐Ziels fokussiert und einen umsetzbaren Plan für den nächsten Arbeitstag erstellt. Das schafft Fokus und fördert Selbstmanagement. Daily Scrums verbessern die Kommunikation, identifizieren Hindernisse, fördern die schnelle Entscheidungsfindung und eliminieren konsequent die Notwendigkeit für andere Meetings.      Das Daily Scrum ist nicht die einzige Gelegenheit, bei der die Developer:innen ihren Plan anpassen dürfen. Sie treffen sich oftmals während des Tages für detailliertere Diskussionen zur Anpassung oder Neuplanung der restlichen Arbeit des Sprints. Sprint Review Zweck des Sprint Reviews ist es, das Ergebnis des Sprints zu überprüfen und künftige Anpassungen festzulegen. Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholder:innen vor, und die Fortschritte in Richtung des Produkt‐Ziels werden diskutiert.    Während des Events überprüfen das Scrum Team und die Stakeholder:innen, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat. Auf der Grundlage dieser Informationen arbeiten die Teilnehmenden gemeinsam daran, was als Nächstes zu tun ist. Auch kann das Product Backlog angepasst werden, um neue Möglichkeiten wahrzunehmen. Das Sprint Review ist ein Arbeitstermin, und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken. Das Sprint Review ist das vorletzte Event des Sprints und ist für einen einmonatigen Sprint auf maximal vier Stunden zeitlich beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer. Sprint Retrospective Der Zweck der Sprint Retrospective ist es, Wege zur Steigerung von Qualität und Effektivität zu planen. 11 Das Scrum Team überprüft, wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und seine Definition of Done verlief. Die überprüften Elemente variieren oft je nach Arbeitsdomäne. Annahmen, die das Team in die Irre geführt haben, werden identifiziert und ihre Ursprünge erforscht. Das Scrum Team bespricht, was während des Sprints gut gelaufen ist, auf welche Probleme es gestoßen ist und wie diese Probleme gelöst wurden (oder auch nicht). Das Scrum Team identifiziert die hilfreichsten Änderungen, um seine Effektivität zu verbessern. Die wirkungsvollsten Verbesserungen werden so schnell wie möglich in Angriff genommen. Sie können sogar in das Sprint Backlog für den nächsten Sprint aufgenommen werden.    Die Sprint Retrospective schließt den Sprint ab. Sie ist für einen einmonatigen Sprint auf maximal drei Stunden beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer. Scrum‐Artefakte Die Artefakte von Scrum repräsentieren Arbeit oder Wert.  Sie sind dafür ausgelegt, die Transparenz von Schlüsselinformationen zu maximieren. So haben alle, die sie überprüfen, die gleiche Grundlage für Anpassungen. Jedes Artefakt beinhaltet ein Commitment, um sicherzustellen, dass Informationen bereitgestellt werden, welche Transparenz und Fokus verbessern, um den Fortschritt messbar zu machen: ● Für das Product Backlog ist es das Produkt‐Ziel. ● Für das Sprint Backlog ist es das Sprint‐Ziel. ● Für das Increment ist es die Definition of Done. Diese Commitments dienen dazu, Empirie und die Scrum‐Werte für das Scrum Team und seine Stakeholder:innen zu verstärken. Product Backlog Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden. Es ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird. Product‐Backlog‐Einträge, die durch das Scrum Team innerhalb eines Sprints abgeschlossen (Done) werden können, gelten als bereit für die Auswahl in einem Sprint‐Planning‐Event. Diesen Transparenzgrad erlangen sie in der Regel durch Refinement‐Aktivitäten. Das Refinement des Product Backlogs ist der Vorgang, durch den Product‐Backlog‐Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld. 12 Die Developer:innen, die die Arbeit erledigen werden, sind für die Größenbestimmung umsetzungsverantwortlich. Der:die Product Owner:in kann die Developer:innen beeinflussen, indem er:sie dabei unterstützt, die Product‐Backlog‐Einträge zu verstehen und Kompromisse einzugehen. Commitment: Produkt‐Ziel Das Produkt‐Ziel beschreibt einen zukünftigen Zustand des Produkts, welches dem Scrum Team als Planungsziel dienen kann. Das Produkt‐Ziel befindet sich im Product Backlog. Der Rest des Product Backlogs entsteht, um zu definieren, „was“ das Produkt‐Ziel erfüllt. Ein Produkt ist ein Instrument, um Wert zu liefern. Es hat klare Grenzen, bekannte Stakeholder:innen, eindeutig definierte Benutzer:innen oder Kund:innen. Ein Produkt kann eine Dienstleistung, ein physisches Produkt oder etwas Abstrakteres sein. Das Produkt‐Ziel ist das langfristige Ziel für das Scrum Team. Das Scrum Team muss eine Zielvorgabe erfüllen (oder aufgeben), bevor es die nächste angeht. Sprint Backlog   Das Sprint Backlog besteht aus dem Sprint‐Ziel (Wofür), den für den Sprint ausgewählten Product‐ Backlog‐Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie). Das Sprint Backlog ist ein Plan von und für die Developer:innen. Es ist ein deutlich sichtbares Echtzeitbild der Arbeit, welche die Developer:innen während des Sprints zur Erreichung des Sprint‐Ziels ausführen wollen. Folglich wird das Sprint Backlog während des gesamten Sprints immer dann aktualisiert, wenn mehr gelernt wurde. Es sollte genügend Details beinhalten, damit sie ihren Fortschritt im Daily Scrum überprüfen können. Commitment: Sprint‐Ziel Das Sprint‐Ziel ist die einzige Zielsetzung für den Sprint. Obwohl das Sprint‐Ziel ein Commitment der Developer:innen ist, bietet es Flexibilität in Bezug auf die genaue Arbeit, die erforderlich ist, um es zu erreichen. Das Sprint‐Ziel schafft auch Kohärenz und Fokus und ermutigt somit das Scrum Team, zusammen statt in separaten Initiativen zu arbeiten. Das Sprint‐Ziel wird während des Sprint‐Planning‐Events erstellt und dann zum Sprint Backlog hinzugefügt. Während die Developer:innen  innerhalb des Sprints arbeiten, behalten sie das Sprint‐Ziel im Gedächtnis. Wenn sich herausstellt, dass die Arbeit von ihren Erwartungen abweicht, arbeiten sie mit dem:der Product Owner:in zusammen, um den Umfang des Sprint Backlogs innerhalb des Sprints zu verhandeln, ohne das Sprint‐Ziel zu beeinflussen. 13 Increment Ein Increment ist ein konkreter Schritt in Richtung des Produkt‐Ziels. Jedes Increment ist additiv zu allen vorherigen Increments und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren. Um einen Mehrwert zu erzielen, muss das Increment verwendbar sein. Innerhalb eines Sprints kann mehr als ein Increment erstellt werden. Deren Summe wird im Sprint Review vorgestellt, womit Empirie unterstützt wird. Ein Increment könnte jedoch auch schon vor Ende des Sprints an die Stakeholder:innen geliefert werden. Das Sprint Review sollte niemals als Barriere zur Lieferung von Wert angesehen werden. Arbeit kann nicht als Teil eines Increments betrachtet werden, solange sie nicht der Definition of Done entspricht. Commitment: Definition of Done Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt.    In dem Moment, in dem ein Product‐Backlog‐Eintrag die Definition of Done erfüllt, wird ein Increment geboren. Die Definition of Done schafft Transparenz, indem sie allen ein gemeinsames Verständnis darüber vermittelt, welche Arbeiten als Teil des Increments abgeschlossen wurden. Wenn ein Product‐Backlog‐ Eintrag nicht der Definition of Done entspricht, kann es weder released noch beim Sprint Review präsentiert werden. Stattdessen wandert es zur zukünftigen Berücksichtigung in das Product Backlog zurück. Wenn die Definition of Done für ein Increment Teil der Standards der Organisation ist, müssen alle Scrum Teams diese als Mindestmaß befolgen. Wenn sie kein Organisationsstandard ist, muss das Scrum Team eine für das Produkt geeignete Definition of Done erstellen. Die Developer:innen müssen sich an die Definition of Done halten. Wenn mehrere Scrum Teams an einem Produkt zusammenarbeiten, müssen sie eine gemeinsame Definition of Done definieren und sich alle daran halten.     14 Schlussbemerkung Scrum ist kostenlos und wird in diesem Guide angeboten. Das Scrum‐Rahmenwerk, wie es hier beschrieben wird, ist unveränderlich. Es ist zwar möglich, nur Teile von Scrum zu implementieren, aber das Ergebnis ist nicht Scrum. Scrum existiert nur in seiner Gesamtheit und funktioniert gut als Container für andere Techniken, Methodiken und Praktiken.