Scrum verständlich erklärt

Kai

Scrum, das beliebteste Agile Rahmenwerk schauen wir uns heute einmal an, und zwar einfach so zum Einstieg, damit du verstehen kannst, wofür eignet sich das überhaupt? Was steckt da so drin? Und was sind vielleicht auch Herausforderungen, die damit einher kommen? Wir freuen uns, wenn du dir in dieser Folge den Überblick verschaffts über Scrum.

Sprecher

Herzlich Willkommen zum Agile Growth Podcast, dem Podcast für alle Agile 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 wieder zuhörst zu einer Folge, die wir vielleicht ganz am Anfang mal hätten machen sollen. Und wir haben die ganze Zeit gedacht So, ach, wir stehen noch so oft im Seminarraum und erklären Menschen, was Scrum ist, dass wir diese Folge jetzt ganz, ganz spät eigentlich aufnehmen in unserem Podcast, nämlich die Frage stellen: Was ist eigentlich Scrum?

Jasmine

Und vielleicht auch Was hat das mit Agil zu tun?

Kai

Und das fühlt sich ein bisschen an wie die Endgegner Frage Weil ja gut, im Seminar haben wir so zwei, drei Tage, um das Ganze zu entpacken, was da alles so dranhängt und drinsteckt. Das heißt, heute werden wir auf jeden Fall mal in der Adler Perspektive unterwegs sein, was dazugehört und wieso überhaupt Scrum – wie sich das alles entwickelt hat, ist ja doch irgendwie ein sehr beliebtes Rahmenwerk geworden, was sehr viele Menschen einsetzen mittlerweile. Und da stellt sich schon auch die Frage, wie kam es eigentlich dazu, dass das so viele Menschen benutzen?

Jasmine

Und da vielleicht. Warum reden wir über Scrum und nicht über irgendwas anderes? Warum reden wir nicht über allgemein agiles Arbeiten? Ganz ehrlich Weil ich nicht weiß, was agiles Arbeiten sein soll, wenn ich nicht irgendein Rahmenwerk dahinter einsetze. Und das ist immer so die erste Klärung, die ich ganz oft mache, wenn ein Kunde auf mich zukommt, wenn eine Person auf mich zukommt mit einer Frage und sagt, ich bin da so in einem Agilen Projekt, dann ist meine Gegenfrage oft: Was ist denn ein agiles Projekt für dich? Ja, wir machen das halt agil. Okay. Was heißt denn das für dich? Und da hilft es für mich, mal so ein bisschen in die Historie rein zu gucken. Was ist dieses Agil für mich in meiner Definition oder auch in der Definition des Agilen Manifests? Und was ist Scrum? Und was viele nicht wissen und auch erstaunt ist, dass Scrum eigentlich älter ist als das Agile Manifest. Bestimmt nicht älter als die Ideen des Agilen Manifests, aber älter als das Agile Manifest.

Kai

Genau. Denn Ende der 90er Jahre wurde Scrum zum Ersten Mal ausprobiert und da gab es das erste Scrum Team. Auch wenn das noch ein bisschen anders definiert war, vielleicht als das, wie es jetzt heutzutage ist. Denn auch Scrum ist natürlich gereift im Laufe der Zeit und erst 2001 war dann das Agile Manifest. Wir haben dazu ja auch schon mal eine Podcastfolge gemacht. Ich glaube Folge vier ist es zum Thema Was ist eigentlich Agilität? Und Scrum ist halt die beliebteste Agile Vorgehensweise und das beliebteste Agile Rahmenwerk, was die meisten Leute einsetzen. Ein Großteil der Leute, die agil arbeiten, nutzen das. Wie gut das ausgeprägt ist in der einzelnen Praxis, da würde ich sagen, das ist sehr durchmischt, also von Teams, die das so machen, wie das definiert ist. Bis Leuten, die sich so einzelne Konzepte irgendwie rausschneiden und das noch mit einer Prise von Missverständnissen obendrauf garnieren, gibt es da alle möglichen Facetten und du weißt wahrscheinlich besser als wir, was bei dir in deinem Umfeld Agiles Arbeiten ist, falls sie das schon macht.

Jasmine

Genau. Und da beginnen wir schon. Scrum ist ein Rahmenwerk. Das heißt, Scrum hat für mich fest definierte Regeln, die ich befolgen darf, wenn ich Scrum mache. Der Scrum Guide sagt auch ich darf da nichts weglassen. Also wenn Kunden zu uns kommen, die direkt sagen, ja, wir wollen ja mal lernen, was das Scrum ist, damit wir es direkt auf uns adaptieren können. Dann kriege ich schon bissle Bauchschmerzen, weil dieses Rahmenwerk ist eigentlich ziemlich leichtgewichtig. Und wenn du schon mit dem Gedanken rein gehst mit ich guck da mal rein, damit ich gucken kann, wie ich es adaptieren kann, was ich alles weglassen kann. Dann würde ich an einer anderen Stelle anfangen, nämlich gucken, was kannst du in deiner täglichen Arbeit denn alles weglassen? Was ist denn alles Waste in deiner täglichen Arbeit, damit ich Scrum gut implementieren kann, wenn ich denn das möchte und das für meinen Kontext passt? Wir gehen später noch mal drauf ein, was denn in diesem Rahmenwerk alles drin ist. Aber mir ist der Kontext ganz, ganz wichtig.

Jasmine

Also Scrum ist ein Rahmenwerk zur Produktentwicklung. Das heißt, wenn ich meine Dienstleistung, mein IT Produkt, mein vielleicht ist es sogar ein ein Hardware Produkt, vielleicht ist es ein Auto etc. Aber wenn ich das als Produkt umpacken kann, dann hilf mir Scrum, wenn ich Multi Projektmanagement mache, dafür Scrum nicht gedacht. Es war noch nicht gedacht. Ich kann versuchen irgendwie Scrum Rahmenwerk da drüber zu legen. Das braucht aber dann relativ viel Gehirnschmalz, wie das irgendwie für uns funktioniert. Ich habe das schon mit Kunden gemacht. Wir kamen zu ganz befriedigenden Lösungen und es hat auch viele ihre Probleme aufgedeckt und wir haben sie dann lösen können. Das war toll. Aber ganz wichtig  – Es ist ein Rahmenwerk zur Produktentwicklung.

Kai

Und ja, jetzt hörst du uns hier sagen man, man sollte das so machen, wie das definiert ist und so, das kommt immer so rüber, als ob das so hier so zwei Certified Scrum Trainer, die sind die Hardliner sagen Du musst das so machen, du kannst das nicht anders machen. Wir machen das jetzt auch schon eine Weile und da vielleicht so ein bisschen im Hintergrund, damit du verstehst, wo wir herkommen. Diese ganzen Muster in Scrum, die einem dabei helfen, bessere Produkte zu entwickeln und anders zusammenzuarbeiten, nach anderen Spielregeln zu arbeiten. Die gibt es jetzt ja einfach schon eine Weile auf diesem Planeten. Die haben schon ihre Jahre auf dem Buckel und in der Zeit hat man einfach ausprobiert, was hilft einem konkret und was braucht man nicht. Und das hat sich so zusammengestellt zu dem Muster Katalog der Sammlung, die Scrum eben jetzt aktuell ist in der aktuellen Definition von den Dingen, die tatsächlich hilfreich sind, wenn man gemeinschaftlich Produktentwicklung betreiben will. Da ist jetzt also nicht mehr viel Schmuck am Nachthemd dran. Man hat das, der  Scrum Guide.

Kai

Die Definition von Scrum ist auch immer kürzer geworden. Da sind immer mehr Sachen rausgefallen. Das ist immer auch IT-agnostischer geworden. Da steht gar nichts mehr drin in Bezug auf IT-Vorgehen, sondern es ist mittlerweile ein Wissensmanagement Rahmenwerk. Und wenn man das aus der Brille heraus betrachtet, dass das schon quasi immer weiter bereinigt worden ist, immer einfacher geworden ist, dann sind halt eben nur noch ein paar Dinge da und die sind wirklich, wirklich wichtig, weil wenn die fehlen, dann stimmt meistens was dahinter nicht. Also man lässt diese Sachen dann weg, weil etwas in der Firmenkultur nicht stimmt. Multi Projektmanagement hat Jasmine gerade genannt oder andere Faktoren dazu beitragen, dass man Dinge weglässt. Deswegen ist so das Plädoyer für uns für den Anfang – Lasst uns mal starten, so wie das gedacht ist, weil die Dinge haben alle eine Funktion da drin. Und wenn Dinge nicht funktionieren, dann haben wir Gott sei Dank noch so’n Scrum Master da drin, der sich damit auseinandersetzen kann, wieso die Dinge nicht funktionieren und wie man das als Zielbild dann nehmen kann, um da mal hinzukommen, so zu arbeiten.

Kai

Denn eigentlich ist dieses nach Scrum Arbeiten ein total natürliches Vorgehen von Menschen, die ein Problem an der Backe haben, könnte man sagen.

Jasmine

Und vielleicht, um dir noch so eine Analogie zu geben, ich bin überhaupt kein Verfechter von jetzt, zum Beispiel einer Low Carb Diät oder so, aber dieses Dinge weglassen hört sich für mich immer so an wie ja, ich will eine Diät machen, ich möchte abnehmen. Ich weiß sehr genau mein Ziel. Ich habe mir jetzt eine Low Carb Diät rausgesucht, möchte mein Ernährungsverhalten entsprechend umstellen, aber morgens brauche ich mein Marmeladen-Brötchen. Dass es sich dann trotzdem aber irgendwie nehme ich nicht ab. Ja. Okay, kannst du so machen. Ist dann halt doof. Das heißt  da hinter zu gucken, zu gucken. Okay, warum brauche ich mein Marmeladenbrot morgens trotzdem.

Kai

Emotionales essen.

Jasmine

Zum Beispiel? Also für mich. Mein Marmeladenbrötchen ist mir übrigens heilig. Einfach. Das ist für mich das totale ankommen, morgens Marmeladenbrot essen zu dürfen. Das heißt ich würde mir diese Diät auch nicht raussuchen. Aber. Das hilft auch beim Scrum Rahmenwerk zu gucken. Wenn wir Dinge nicht tun können, wenn die nicht funktionieren, statt sie weg zu lassen, den härteren Weg zu gehen und zu gucken Hey, wie können wir es vielleicht doch hinkriegen? Oder warum geht das gerade nicht? Hilft. So, jetzt hat Kai gesagt, es ist ein Rahmenwerk zu Wissensarbeit. Das heißt, es ist ein Rahmenwerk, das ich in einem bestimmten Umfeld einsetze. Und wir nennen es ganz oft dieses komplexe Umfeld, das heißt das Umfeld, wo Anforderung und Umsetzung unklar sind. Also da, wo mir vielleicht mein Endkunde nicht genau sagen kann, was er möchte. Das heißt nicht, dass mein Kunde nicht denkt, dass er weiß, was er genau möchte. Das begegnet mir ganz, ganz oft, dass der Endkunde, der Stakeholder, der Key User wer auch immer sehr, sehr genaue Vorstellungen hat, was er möchte.

Jasmine

Und wenn es dann umgesetzt ist, merkt er so – Nö, das wollte ich gar nicht. Und dann beginnt das Hickhack. So. Also wenn ich in diesen Umfeldern bin, wo der Anwender, der Endkunde etc. gar nicht richtig Versprachlichen kann, was er möchte. Vielleicht, weil’s einfach hoch innovativ ist. Und vielleicht ändern sich aber auch die Arten der Umsetzung sehr schnell. Und das ist halt in der IT der Fall. Also neue Technologien kommen dazu etc. Die Art der Umsetzung kann sich da auch sehr, sehr schnell ändern. Ist sehr volatil. Wenn ich in diesem Umfeld bin und oder die Anforderung sich schnell ändern kann und nicht genau versprachlicht ich werden kann oder die und die Umsetzung noch unklar ist, dann bin ich in einem komplexen Umfeld. Das ist bei Wissensarbeit ganz oft der Fall. Das ist in der IT ganz oft der Fall. Das ist bei Innovationsarbeit der Fall. Das ist im Prinzip in allen Veränderungsprojekten der Fall.

Kai

Ich vergleiche das ganz gerne mal mit Autofahren im Nebel. Das heißt dichter Nebel. So eine richtige Suppe. Und dann fahre ich ein paar Meter und muss dann schauen, dass ich nicht von der Straße abkomm, sagen wir mal es ist eine Landstraße, auf der ich gerade unterwegs bin. Natürlich, alle fahren langsam, weil es ist eine dichte Suppe. Und dann fahre ich ein Stück und dann muss ich wieder schauen, wo ist denn der Randstreifen, wenn ich den da sehe, dass ich da nicht vom Bordstein runterkommen kann? Ich bin ein Stück fahren und dann muss ich wieder ein bisschen nachsteuern, damit, falls da gerade eine Kurve ist, ich nicht von der Fahrbahn runter komme. Manchmal kann es sogar passieren, das rechte Reifen dann, wenn ich gerade irgendwie die Straße nach links abgeknickt, dass der dann auch wirklich runterkommt. Und da muss ich ihn wieder draufsetzen. Also da passieren dann regelmäßig so kleinere Fehler. Auch könnte man das nennen. Und die brauche ich aber, um meine Richtung zu korrigieren. Und so ist das dann auch mit so einem Scrum, was ja Sprints besitzt.

Kai

Also so Iterationen, Schleifen, die mir immer mal wieder den Kopf hochheben und schauen, wo stehen wir denn eigentlich gerade? Und eben checken – Ist das das, was wir eigentlich bauen wollten? Hilft das den Leuten wirklich weiter? Wir drücken aus denen in die Hand und lernen mit denen. Ist das hier hilfreich für das Problem, was wir haben und was wir zu lösen versuchen?

Jasmine

Das heißt Scrum hilft dir da, wo du im Nebel fährst. Ich sage auch ganz gerne dieses wo wir nicht wissen, was wir nicht wissen. Da wo wir wissen, was wir nicht wissen, können wir es analysieren, können unseren Plan machen, gehen vorwärts. Da hilft uns klassisches Projektmanagement total gut und da würde ich auch nicht Scrum einsetzen wollen. Aber da, wo noch relativ viel unklar ist, da wo ich nicht weiß, wie mein meine Zuhörerschaft irgendwas akzeptiert, da hilft mir Scrum, weil da ist das einzige was ich tun kann, ist lernen. Und lernen tue ich über Feedback und Scrum ist ein Rahmenwerk, das diese Feedback Zyklen extrem kurz hält. Also sagt mach’s nicht länger als ein Monat, wenn du kannst, am besten noch kürzer. Und worüber sammeln wir Feedback? Wir sammeln Feedback über unser Produkt. Das tun wir im Review nennt sich das also ein Workshop, wo ich mit Endkunden, mit Anwendern, wenn es geht, mit aber auch allen Stakeholdern auf das Produkt drauf gucke und Feedback sammle.

Jasmine

Das ist mir ganz wichtig. Das Review ist wirklich ein Workshop, kein Abnahme Meeting, sondern es geht darum zu lernen. Abnahme klingt so wie – Haste gut gemacht, haste nicht gut gemacht. Und schimpfe schimpfe, wenn nicht gut. Sondern es geht darum zu lernen. Es ist ein Workshop, wo wir gemeinsam lernen. Das heißt, ich habe einmal eine Feedback Schleife auf mein Produkt. Ich habe aber in der Retrospektive, wo wir in die Introspektion gehen, als gesamtes Team auch eine Feedback Schleife auf unsere Arbeitsweise, unserem Prozess, der Umgebung, in der wir sind, wie könnten wir das alles verbessern? Das heißt auch da das komplexe menschliche System, das ich baue, wenn ich als Team zusammenarbeite und das ist immer komplex und nicht einfach, auch da habe ich eine Feedback Schleife drüber und ich hab täglich treffe ich mich mit meinem Team mindestens einmal für 15 Minuten, wo wir eine Feedback Schleife drüber haben. Hey, wie gut sind wir denn gerade unterwegs im Erreichen unseres Ziels, dass wir uns für diese Iteration gesetzt haben?

Kai

Und genau dieses Ziel setzen wir uns in der Sprint Planung. Das ist am Beginn von jedem Sprint, von dieser immer festen Zeiteinheit, die wir für uns gewählt haben, die maximal einen Monat lang ist, wie gerade sagte. Und da planen wir dann halt, was wir zu erreichen suchen. Und das Ganze ist ein bisschen ja angehaucht und inspiriert durch LEAN dieser LEAN Philosophie, also Verschwendungen zu vermeiden und uns darauf zu konzentrieren, dass wir wirklich die Dinge bauen, die Wert bringen und alles andere weglassen. Den Schmuck am Nachthemd und Gold Plating sagt man immer ganz gerne. Mal so eine goldene Schraube vorne dran sitzen. Das lassen wir weg, damit wir uns auf das Wesentliche konzentrieren. Und das hilft dann dabei, dass wir und deswegen auch diese Art des Arbeitens bei Startups ganz beliebt, dass wir einfach schlank und mit einer budgetfreundlichen Variante die Dinge bauen, die für den Anwender einen Unterschied machen.

Jasmine

Und da kommen wir schon zum Punkt von was braucht es denn überhaupt, wenn ich jetzt Scrum machen möchte? Und das erste, was es braucht, ist die Akzeptanz dessen, dass wir in einer komplexen Umgebung sind. In meiner Erfahrung ist das ganz schwierig für Firmen zu akzeptieren. Gerade für Firmen, die aus einer eher komplizierten Domäne rauskommen. Logistik oder Bahnverkehr oder.

Kai

Sachbearbeitung im Finanzbereich.

Jasmine

Etc.. Also es ist eher eine komplizierte Domäne und vielleicht durch die Umwelt jetzt einfach komplex geworden. Und da braucht es erst mal die Akzeptanz dessen, dass ich nicht alles analysieren kann, also dass ich nicht mehr im Raum bin, wo ich weiß, was ich nicht weiß, es analysieren kann und dann einfach mit einem guten Plan zu einem guten Ergebnis komme. Sondern dass ich im Raum bin und ich nicht mehr weiß, was ich nicht weiß. Das heißt, dass ich Experimente machen muss, dass ich da Anführungszeichen, Fehler drin machen muss und daraus lernen kann, dass Lernen meine einzige Überlebensstrategie ist. Und da kommen wir zum nächsten Punkt – Es braucht die Akzeptanz, dass wir in einem komplexen Umfeld sind. Und der nächste Punkt ist dann – Es braucht eine gute Lernkultur dahinter. Weil wenn ich immer Schelte und Schimpfe kriege als Team, weil irgendwas noch nicht so perfekt ist, dann wird das nicht funktionieren. Dann wird das Team irgendwann mal die Dinge nicht mehr rausgeben oder diese Feedback Zyklen so groß machen dass wir wieder zu kurz dran sind.

Kai

Die gute Nachricht dabei – Scrum ist auch ein Wert-Katalysator. Also selbst wenn diese Werte noch nicht da sind, wenn man anfängt das zu tun, durch das Verhalten der Leute entsteht dann ja ein neues Denken und eine neue Handlungsweise, die dann so als Schatten der Kultur auf die Organisation fällt. Insofern, wenn du jetzt rauslässt, wir machen das gar nicht so und wir haben irgendwie eine schlechte Fehlerkultur. Das muss jetzt nicht unbedingt ein Grund sein, weswegen man das gar nicht anfängt. Aber es ist halt ein Thema, was einem auf jeden Fall dann unterwegs begegnet an der Stelle.

Jasmine

Was auch hilft oder wo wo Scrum auch ein Katalysator ist. Es braucht eine neue Kommunikationskultur. Wir hatten letztens einen ACSM und ich hatte da ein super spannendes Gespräch mit einem Scrum Master, der schon sehr, sehr lange unterwegs ist. Er meinte Ah, mir ist gerade aufgefallen, wir brauchen echt eine neue Kommunikationskultur, sowohl im Team wie auch außerhalb des Teams. Und das kann sehr fordernd sein. Da hilft einem Scrum. Aber es braucht die Bereitschaft, diese neue Kommunikationskultur zu etablieren. Weil da, wo wir die gemeinsame Intelligenz einer Gruppe benutzen wollen, führt es auch zu Reibung. Und diese Reibungen sind wichtig. Kai und ich hatten Gestern haben wir einen Workshop abgeschlossen und im Feedback kam ihr funktioniert total gut als Trainerpaar und ich haben ein bisschen geschmunzelt und meinten nur – Ja, ihr habt unsere Streits in der Pause ja nicht mitgekriegt. Also auch Kai und ich. Und das lernen wir jeden Tag noch ein bisschen besser, müssen eine völlig neue Kommunikationskultur für uns etablieren. Also das ist für mich Paradebeispiel von psychologischer Sicherheit.

Jasmine

Bei uns läuft es nicht rund. Wir zoffen uns richtig derbe. Aber wir wissen, wofür wir uns streiten. Und wir wissen, dass diese Reibung des Streits, diese Disharmonie zu einfach unglaublich viel besseren Ergebnissen führt, weil wir alles äußern können, was zum Zweck des besseren Ergebnisses dient. Und das ist manchmal nicht Harmonie und Friede, Freude, Eierkuchen und ja, ich stimme dir hier zu, sondern das ist ganz ehrlich, hast du einen an der Klatsche? Das können wir so nicht tun. Manchmal sage ich so und manchmal sage ich es auch ein bisschen netter.

Kai

Und auch da ist wieder die gute Nachricht – Diese psychologische Sicherheit, von der es gesprochen hat. Auch dazu haben wir schon mal eine Podcastfolge gemacht. Dazu gibt es jemanden, der da immer wieder rein investiert. Unsere Scrum Master, unsere Scrum Master hat diverse Funktionen in dem Rahmenwerk, das natürlich erst mal den anderen zu erklären und dafür zu sorgen, dass das auch so gelebt wird wie gedacht. Es gehört aber eben auch dazu, dieses Team zu entwickeln, denn da ist, da ist noch das ganze Scrum Team besteht aus drei Verantwortlichkeiten, nämlich Product Owner bzw Product Ownerin  Entwicklern und Entwicklerinnen und einer Scrum Master oder Scrum Masterinnen. Und diese drei Verantwortlichkeiten reichen aus, um ein Produkt zu bauen. Denn ja, unser Product Owner ist so der Visionär, der hat entsprechend das Bild davon, was für ein Problem in der Welt gelöst werden muss, kann das auch kommunizieren und sorgt dafür, Unterstützung zu gewinnen und mit den Stakeholdern zu arbeiten.

Jasmine

Und dafür erstellt der Product Owner ein sogenanntes Backlog und ein Backlog ist kein Lasten Pflichtenheft. Ein Backlog ist auch keine Abarbeitungs-Liste im ursprünglichen Sinn, sondern ich finde, es ist sehr viel einfacher, wenn wir uns das visualisieren. Also ein Backlog ist eine ganze Liste von Experimenten, die geordnet sind, die wir durchführen wollen, weil wir annehmen, dass es unser Produkt voranbringt. Und dafür ist der Product Owner verantwortlich, dass wir diese Liste von Experimenten haben und dass wir die auch immer wieder bereinigen. Das heißt, Experimente, wo wir sagen, wir haben Neues gelernt, brauchen wir gar nicht, schmeißen wir raus. Also nicht Lasten und Pflichtenheft bleibt da drin, für immer, bis es dann auch gemacht ist. Sondern wenn wir es nicht. Wenn es nichts taugt, schmeißen wir es raus und auch neue Sachen wieder reinkommen, weil wir ja Feedback generieren.

Kai

Und das ist also eine gute Quelle von Arbeit, aus der dann die Entwickler konkret sich dann Experimente aussuchen können für den Sprint, geführt durch die Priorisierung, also die Sortierung von Product Owner, der das in der Reihenfolge gebracht hat, damit klar ist, was ist eigentlich besonders wertvoll, denn unser Product Owner spricht ja ständig mit den Anwendern und den Kunden und den Stakeholdern, um zu wissen Was ist denn wertvoll für die? Welche Funktionalitäten brauchen die? Insofern ist das dann natürlich in dieser Liste des Backlogs ganz oben. Und wenn wir eine Sprint Planung reingehen, dann suchen sich die Entwickler so viel Arbeit aus von diesem ganz oben, also von den wichtigen Dingen, dass sie das in der guten Qualität machen können, entsprechend ihrer Definition von fertig, Definition Of Done dann genannt, also der Einigung darauf, was fertig heißt. Und ja, so haben sie dann vor allen Dingen nur so viel Arbeit genommen, wie sie auch machen können. Und vielleicht kennst du das von dir selbst, wenn du manchmal so gegen Deadlines gearbeitet hast, vielleicht der Ausbildung im Studium und das wird dann irgendwie knapp, dann mauschelt man ja doch schon mal ganz gerne an der Qualität und das ist nichts, was wir wollen an der Stelle, denn dazu haben wir ja auch schon mal eine Podcastfolge macht.

Kai

Technische Schulden wollen wir nicht aufbauen, sondern wir wollen immer die Teile, die wir dann zu den wir ja gesagt haben, auch in der vorgestellten Qualität liefern können. Und da sind wir dann wieder bei diesen Lean Gedanken, bei der Toyota Produktions Philosophie und bei dem Pull Prozess nämlich die Leute an der Arbeitsbank pullen sich nur so viel Arbeit, wie sie wollen, anstatt dass wir push ihnen noch was drauf satteln.

Jasmine

Dafür übergeben wir aber auch die gesamte Verantwortung der Qualität an die Entwickler und Entwicklerinnen. Und mit Entwickler und Entwicklerinnen meinen wir nicht Softwareentwickler. Wir meinen nicht die, die nur Code schreiben, sondern alle Leute, die es braucht, um dieses Produkt zu erstellen. Das heißt, könnte sein, dass du ein Business Analyst bist und es braucht  deine Business Analyse Skills, um Dinge genauer zu verstehen, damit wir sie danach, wenn wir ein Software Produkt machen, in Code gießen. Dann bist du genau so ein Entwickler, eine Entwicklerin wie jemand, der jetzt produktiven Code schreibt etc.. Also alle Leute, die wir brauchen, damit wir das Produkt erstellen können. Ich habe auch schon mal für eine Fitness App gearbeitet, da hatten wir Psychologen drin, wir hatten Sportwissenschaftler drin, wir hatten Marketing drin. Weil all das braucht es für eine Fitness App zudem, dass wir halt noch Softwareentwickler und Entwicklerinnen drin haben. Aber diese Verantwortungs-Übergabe der Qualität und des “Wie werden die Dinge umgesetzt” in das Entwicklerteam, das nicht mehr Entwicklerteam heißt im neuen Scrum Guide

Jasmine

Das ist noch nicht in meinem Kopf angekommen. Zu den Entwicklern und Entwicklerinnen ist ein ganz, ganz wichtiger Faktor. Also Scrum schiebt die Verantwortung dahin, wo sie auch getragen werden kann.

Kai

Also noch mal ganz wichtig :Mit Entwickler meinen wir alle Leute, die am Produkt bauen. Das ist wirklich so eine Umstellung im Kopf, ich weiß, dass es sprachlich nicht so ganz glücklich hier sind Produktentwickler gemeint, also nicht irgendwie Programmierer, sondern wirklich alle, die es braucht, um ein Stück Produkt zu bauen.

Jasmine

Genau. Und so sind wir eigentlich schon an dem Punkt, wo wir, glaube ich, ganz viele Dinge gesagt haben Was ist denn dieses Scrum? Man kann das auch wirklich in Zahlen runterbrechen. Also wenn man es in Zahlen herunterbricht, was ist dieses Scrum? Scrum basiert auf fünf Werten. Wir haben fünf Werte, nämlich Mut, Fokus, Offenheit, Respekt und Commitment. Das sind die fünf Werte, die im Scrum Team verkörpert werden, aber auch in der Organisation verkörpert werden sollten oder wir darauf hinarbeiten dürfen, damit die auch in der Organisation der verkörpert werden. Dann funktioniert Scrum relativ gut. Wir haben die jetzt sprachlich umrissen in unserer Podcastfolge bis jetzt. Aber im Prinzip sind es diese fünf Kernwerte und dann haben wir drei Verantwortlichkeiten.

Kai

Genau habe ich gerade schon genannt Product Owner, Entwickler, Scrum Master. Und die erwecken das Ganze zum Leben. Das ist also jemand, der konkret in eine gewisse Richtung zieht, könnte man auch sagen, in Richtung möglichst viel getan bekommen. Die Product Vision zum Leben bringen und deswegen auch der Wunsch danach viel getan zu bekommen, damit das halt ins Leben kommt. Dann die Entwickler, die sagen Ich möchte das in einer guten Qualität machen. Ich möchte, dass das auch noch wartbar ist in Zukunft. Ich möchte, dass die Lösung irgendwie gut ist. Und dann noch Scrum Master, die dafür sorgen, dass dieses Wechselspiel zwischen diesen Parteien hier gut funktioniert und dass die Konflikte aufgelöst werden und dass das ein hoch produktives Team wird.

Jasmine

Und dann habe ich fünf Events. Der Sprint ist einer dieser Events, also das Überspannende Event im Prinzip, unsere Iteration, die darf bis einen Monat lang sein. Man sollte die kürzeste Zeit, die man schafft, um ein Produktinkrement, also ein wertvoller. Produkt Abschnitt, wo ich Feedback drauf generieren kann, zu erstellen. Also der kürzeste Zeitabschnitt dafür sollte verwendet werden. Dann habe ich, wie wir schon gesagt haben, das Planning. Wo wir planen. Was werden wir in dieser Iteration machen? Wir treffen uns jeden Tag zu einem Daily Scrum. 15 Minuten kurz und knackig. Wie gut sind wir unterwegs im Hinblick auf unser Ziel, das wir uns gesetzt haben? Was müssen wir tun, damit wir das erreichen können? Im Sinn von Arbeit, aber auch im Sinn von Hindernisse aus dem Weg räumen. Nach der Iteration, also, wenn die zum Ende neigt, treffen wir uns zu einem Review. Das haben wir schon umrissen. Einen Workshop, wo wir mit Endkunden, Stakeholdern, CEOs etc. auf unser Produkt draufgucken, wirklich gucken, was funktioniert, was funktioniert noch nicht?

Jasmine

Wie können wir es besser machen? Neue Ideen generieren für unser Produkt Backlog. Danach zieht sich das Scrum Team, also Scrum Master, Product Owner, Entwickler und Entwicklerinnen zurück und gehen in die Introspektion. Gucken, was können wir besser mache, unsere Arbeitsweise an der Interaktion mit Stakeholdern, an der Qualität etc.. Und dann beginnt das Ganze wieder von vorne.

Kai

So, dann gibt es drei Artefakte, eines hat Jasmine gerade schon genannt. Das ist also ja sozusagen der aktuelle Zustand des Produktes, der da entstanden ist. Inkrementell, also in einzelnen Schritten wird das Produkt aufgebaut, nicht so als eine riesen Lieferung, sondern zwei Jahren. So hier, lieber Kunde, ist das Produkt, sondern wir bauen das schrittweise auf, über das wir Feedback sammeln. Es gibt das Produkt Backlog, das ist die Liste der Anforderungen, die wir zusammengetragen haben, die Dinge, die noch fehlen in unserem Produkt. Und es gibt das Sprint Backlog, was dann eben die konkrete Auswahl durch unser Entwickler ist, was wir in einem Sprint umgesetzt bekommen, inklusive noch ein bisschen Schlachtplan dahinter kann man sich vorstellen, wie so eine kollektive To Do Liste, wo dann noch Tätigkeiten dranhängen? Wer macht denn eigentlich was? Und darüber organisieren die sich häufig über so ein visuelles Management Board wie zum Beispiel ein Task Board wird sowas abgebildet, ganz gern mit Klebezettel. Das ist auch das, was man so häufig sieht in der physikalischen Zeit, oder

Kai

Heutzutage gibt es ja viele digitale Werkzeuge, die sowas auch abbilden können.

Jasmine

Du siehst, es ist relativ schlank, da ist nicht so viel dran. Aber vielleicht, wenn du deine bestehende Arbeits-Realität hast, dann könnte es sein, dass das zu viel ist. Das heißt Scrum einfach on top von bestehender Arbeits-Realität einzusetzen ist immer relativ schwierig. Mir hilft es oder unseren Kunden hilft es ganz oft, wenn wir sagen – Hey, wenn wir alles weglassen, was wir tun und nur Scrum anwenden und danach die Dinge, die wir merken, dass wir sie doch brauchen, wieder hinzunehmen, dann hilft dieser Weg oft mehr, als zu sagen: Wir machen alles genauso weiter, wie wir es tun und machen Scrum on top. Dann kommt ganz, ganz schnell die Aussage von – es ist es zu viel Arbeit mit Meetings? Wenn wir es aber mal ausrechnen, wie viel diese Events auch wirklich in Anspruch nehmen, dann verbringen wir 20 % unserer Arbeitszeit in diesen Events. Meine Erfahrung ist, dass wir ganz viele Termine, die wir sonst noch so haben, eigentlich in diesen Events abgebildet bekommen. Das heißt dann gar nicht so viele Meetings, eigentlich mehr haben drumherum, weil wir diese  in die Events reinpacken können.

Kai

So 10 bis 15 Millionen Menschen machen das weltweit, dieses Scrum Rahmenwerk. Das ist also tatsächlich sehr beliebt geworden in letzter Zeit immer mehr. Ich glaube, es ist auch nach wie vor ein Thema, das wichtig ist, denn vielleicht merkst du das selbst. Unsere Welt ist zunehmend volatiler geworden. Wir haben viele Doppeldeutigkeiten da draußen, viele Unsicherheiten, mit denen wir umgehen müssen. Und dazu hilft es halt, durch Komplexität, durch navigieren zu können. Und das lernen Menschen, die in diesem Rahmenwerk arbeiten. Und was auch noch gut tut, ist, dass durch die Art und Weise, dass wir regelmäßig reflektieren über unsere Arbeit auch ein Unternehmenslernen. Ein Lernprozess, da ist für die Menschen innerhalb der Organisation und vielleicht kennen du das selbst nur so im Persönlichkeits und Bildungsmarkt sagt jeder, schreibt Tagebuch, mache Praktiken, die dir dabei helfen, dass du selber reflektieren kannst. Und das machen wir auf der Organisations ebene dann auch. Also verschiedene Gründe, warum das so beliebt geworden ist und in der Umsetzung ja durchaus herausfordernd. Ich glaube, das hat man so vielleicht auch schon mitbekommen.

Kai

Weswegen hat eine Begleitung auch total Sinn macht und der Scrum Master ist die eingebaute Begleitung, die dann dazu da ist. Und wir hoffen, wir konnten uns einen guten Überblick geben über das Rahmenwerk, die fünf Werte, die fünf Ereignisse, drei Verantwortlichkeiten und drei Artefakte. Also so viel ist das nicht. Deswegen auch so was kann ich davon weglassen? Wie kann ich das verbiegen? Es ist ja fast nichts dran. Würde ich ja fast so ein bisschen überspitzt sagen wollen. Und wenn du dich da tiefer reinknien willst – wir haben regelmäßig Certified Scrum Master Schulungen. Die sind nicht unbedingt eine Rollen Schulung. Also nur in dieser Verantwortung. Da kannst du auch dieses ganze Rahmenwerk noch mal im Detail mit uns zusammen durchgehen und verstehen. Da herzliche Einladung. Wenn du oder tiefer rein willst, freuen wir uns, wenn wir dich im Seminar wiedersehen.

Jasmine

Und damit wünschen wir dir eine wunderbare Woche. Genießt das Frühlingswetter, genießt die Sonne und wir hören uns hoffentlich nächste Woche.