WIe immer interessiert mich, wie Ihr zu dem Thema Scrum steht und besonders "Was ist für Euch das wichtigste bei Scrum?" Die Verlosung des DWX Tickets geht bis zum 21.6. - Viel Erfolg. Und das *Abo* nicht vergessen, zu Scrum machen wir noch mehr in der Zukunft :)
Vorab. Ich halt nichts von Scrum. Mein Background: Fast 10 Jahre Erfahrung als Softwareentwickler und jetzt bald 2 Jahre Product Owner in einem Unternehmen mit > 5000 MA das eigene Produkte entwickelt, fertigt und vertreibt. Wie fast in jedem Unternehmen das SW entwickelt, strauchelt es im SW Bereich. Backlog ist laut Jira für die nächsten 10 Jahr randvoll, ca. 50% der täglichen Arbeit wird mit Bugfixen verbracht und das Management schimpft weil die Zeitpläne nicht eingehalten werden. Ich geh mal in die Vergangenheit. Vor ca. 8 Jahren haben bei uns einige Teams mit Scrum angefangen. Sie hatten das Problem, dass sie ständig während der Entwicklung von Sachen unterbrochen wurden und nichts fertig machen konnten, weil sie wieder wo anderes was neues implementieren sollten. Idee: Wir führen Scrum ein, damit transparent festgehalten wird, an was die nächsten 2 Wochen (fokussiert) gearbeitet wird. Ein Entwickler aus einem anderen Team wurde Scrum Master und ein Projektleiter wurde PO. Aber so richtig funktioniert hat das nicht. Hier muss ich noch anmerken, dass das Team Scrum eingeführt hat, ohne dem Wissen des Top Managements. Die wussten zum dem Zeitpunkt vermutlich nicht mal was Scrum und Agil bedeutet. Wenig überraschend ist es immer wieder dazugekommen, dass Sprints von der Geschäftsleitung gecrasht wurden. OK das kann passieren, dass man mal was sehr wichtiges vorziehen muss, aber es kam irgendwie zu oft vor. Natürlich war der Frust bei den Entwicklern dementsprechend groß und das Team hat schon darüber nachgedacht das mit Scrum wieder zu lassen. Aber das Top Management wurde rund um die Probleme in der SW Entwicklung „aktiv“. Angefangen wurde damit einen Softwareentwicklungsprozess auszuarbeiten. Weil hier wurde vermutlich ein bisschen die Idee von Lean aufgeschnappt. Entwicklung ist ein Prozess der immer die gleichen Schritte hat und somit kann man Features wie am Fließband produzieren. „Haha“ Dieser Prozess wurde in ein PDF mit ca. 50 Seiten gegossen und in Form von Schulungen ausgerollt. Dieses Dokument enthält Definitionen für Rollen, Artefakte (wie Lasten- und Pflichtenheft ;-) ) usw., basierend auf dem V-Modell XT, Arc 42, Scrum, Kanban, SAFe usw. An dieser Stelle könnte man mal Bingo sagen. In dem Zusammenhang wurde dann noch Jira eingeführt, damit der Prozess mit über 20 Issue Typen und 100 Zuständen transparent ist. Währendes wurden auch noch andere Prozesse wie Anforderungs, Ideen, Änderungsmanagements ausgearbeitet und eingeführt. Mein Fazit: Klingt toll, aber diese Dokumente haben eigentlich mehr Fragen aufgeworfen als sie beantworten hätte sollen. Ist auch klar. Diese Dokumente wurden zum Teil von Leuten geschrieben die vielleicht mal in der Schule ein „Hello World“ programmiert haben. Natürlich wurde für diese ganzen Themen externe Hilfe herbei gezogen, Aber zum Ende dieser Phase wurde die Zusammenarbeit mit dem ersten externen Beratungsunternehmen beendet. Vor ca. 3 Jahren hat das Top Management hat Wort „Agil“ (in einer Buchstabensuppe) entdeckt. Vermutlich in dem Zusammenhang - Mit agil werden die Software Entwickler schneller. Nein. Ein weiteres großes Beratungsunternehmen wurde engagiert mit dem Ziel eine agile Transformation im Unternehmen einzuläuten. Eine große Veranstaltung wurde gemacht wo alle vom agilen Arbeiten überzeugt werden sollen. Gefolgt von 100erten super teuren Beratungsstunden. Dieses Beratungsunternehmen hat es aber glaube ich geschafft dem Top Management klar zu machen, dass wenn man eine agile Transformation durchführt werden soll, das Top Management auch agil sein muss. Wenn man eine agile Transformation macht will wird natürlich gerne Scrum eingeführt - ist ja (gerade) modern. Darum wurden ca. 5 Vollzeit Scrum Master eingestellt und Product Owner installiert. Jedoch hat dieses Beratungsunternehmen einen Zwist in das Unternehmen gebracht. Dieses Beratungsunternehmen hat ihr eigenes agiles Framework entwickelt und dieses wollte bzw. hat es zum Teil mittels Musterprojekten eingeführt. Jedoch ist dieses nicht mit firmeneigenem Softwareentwicklungsstandard konform, mit dem der Großteil entwickelt wurde. Schlussendlich haben einige interne Leute gesagt: „Wie sollen wir jetzt arbeiten?“ und das Management hat sich dazu entschieden die Zusammenarbeit mit diesem Beratungsunternehmen zu beenden bzw. nicht weiter verlängert und diese eingeführten Sachen wurden über Bord geworfen. Man kann sich jetzt Fragen wieso schreib ich das jetzt alles? Naja vielleicht habe ich einen Schaden von dem ganzen agilen Zeugs davon getragen und bin deswegen kein Fan von Scrum. Aber vielleicht kommt (bzw. kam) auch der Schaden von diesen hardcore Scrum Mastern, die versucht haben in jedem kleinen Fleck im Unternehmen Scrum zu machen. Angefangen von der Softwareentwicklung bis hin zum Support. Kein Scherz. Auch im Support soll ein Mitarbeitern schätzen, wie langer er für die Lösung von einem Problem braucht. Naja ich halte davon nichts. Hier muss ich mal festhalten, dass ich vom agilen Arbeiten natürlich schon was halte. Aber ich verdrehe halt die Augen wenn man dazu „agil“ sagt. Für mich ist das intuitiv wenn Software in kleine funktionale Teile runter bricht. Wer will schon ein Jahr Anforderungen schreiben ohne eine echte Funktionalität zu sehen? Also ich würde das nicht aushalten. Zurück zu Scrum. Ich habe da jetzt zwei Sichtweisen drauf. Ich fange mal von der Sicht des Dev Teams an. Würde ich in einem Scrum Team sein, würde mich das Schätzen von User Stories stören. Man bekommt ja oft Sachen vorgelegt die man machen soll, zum Teil nicht klar ist was gemacht werden soll, die User Story sehr groß ist, bzw. man keine Expertise auf dem Gebiet hat. Und dann soll man das Schätzen und ein commitment machen. *bäh* Wenn man jetzt eine Person ist, die gut SW schreiben will, immer sein Wort halten möchte und kein Zeit gefühlt hat, dann kommt da bei mir ein innerlicher Stress auf, dass sich negativ auf die Arbeitsleistung auswirkt. Hier kann man einhacken. Ja aber man schätzt ja eh im Team. Sollte so sein, ist aber oft nicht so. Weil oft ist es so, dass sich nur einer in der Software auskennt. Bei uns im Unternehmen kommt mir vor, dass Scrum Master überall dort eingesetzt werden, wo „Babysitter“ benötigt werden. Ich schlage oft innerlich die Hände über dem Kopf zusammen, was mir die Scrum Master von ihrer täglichen Arbeit erzählen. Beispiel: Mitarbeiter A kennst sich wo nicht aus und weiß das Mitarbeiter B ihm da weiterhelfen kann. Jedoch will Mitarbeiter A nicht Mitarbeiter B bei seiner Arbeit stören und kommt deswegen bei seiner Arbeit weiter und das obwohl sie Tisch an Tisch sitzen. Und um solche Fälle müssen sich bei uns Scrum Master kümmern. Ich nenne das „betreutes programmieren“. Anderes gesagt es ist traurig wenn ein Scrum Master benötigt wird das ein Daily gemacht wird oder man sich kontinuierlich verbessern will. Sicher immer weiter zu verbessern sollte ja selbstverständlich sein. Aus der Sicht des Product Owners sehe ich da wieder andere Herausforderungen. Ziel von agiler Softwareentwicklung ist ja „Value“ dem Kunden zu liefern. In Scrum soll ja nach jedem Sprint ein „potentielles“ Release geliefert werden können. Sprich in Scrum müssen die Stories dementsprechend klein sein, dass sie innerhalb von z.B. 2 Wochen implementiert werden kann. Und wenn zu groß dann muss man sich kleiner bekommen. Und dieses „zermahlen“ von Sachen ist echt schwierig und würde mich nerven. Zum Beispiel habe ich jetzt gerade ein Software Projekt. Drei Entwickler sollen eine Datenbank aufsetzen, mit einem Webfrontend bestehend aus einer Seite. Diese Seite enthält ca 5 Suchfelder und die Suchergebenisse werden beim Drücken einer Schaltfläche aufgelistet (sehr einfache Anwendung). Das ganze habe ich in eine User Stories gepackt, weil es den Stakeholder einen Mehrwert bietet. Ich dachte auch, würden wir Scrum machen würde sich das durchaus in 2 Wochen ausgehen. Angefangen wurde damit Anfang 2021 und nach 6 Monaten sind die 3 Entwickler damit fertig geworden. Warum? Weil diese drei Entwickler eigentlich immer Embedded Software in C++ entwickelt haben und dieses Mal zum ersten Mal in C#.
Hallo Franz, alleine Dein erster Absatz zeigt ganz hervorragend genau die Auswirkungen des ersten Profi Tipps am Ende: Wenn das Management nicht mitzieht und diese Agilen Werte vorlebt, dann kann das gar nicht funktionieren. Agile nur in einem kleinen Team zu sein ist sehr sehr schwer wenn das Umfeld nicht mitspielt und oft geht es schief. Der neu aufgesetzte Prozess klingt schon vom Start weg (in meinen Augen) viel zu kompliziert. Ich würde sagen Deine Vorgesetzten haben agilität und kontinuierliche Verbesserung nicht verstanden und die Chance und das Potenzial überhaupt nicht genutzt. Ihr hättet mit Scrum und einem richtig guten Scrum Master starten sollen und dann diese Transition von Sprint zu Sprint machen sollen. Dann hätte das Ergebnis zu 100% gepasst und ihr hättet es schrittweise adaptieren können ohne alle zu überfordern. Und auch das engagierte Unternehmen hat Euer Problem nicht gelöst, auch wenn der Ansatz super war. Agilität ist nichts was man einkauft sondern ist eine Denk- und Handlungsweise die schrittweise in ein Unternehmen getragen werden muss, das dauert sehr lange und erfordert viel Arbeit. Und warum das Beratungsunternehmen ausgerechnet ein eigenes Agiles Modell gebraucht hat, verstehe ich schon - die Standardmodelle da draußen sind sehr gut für sehr viele Situationen geeignet. Aber wenn Ihr deren Modell nutzt besteht natürlich eine gewisse Abhängigkeit zu dem Unternehmen was Folgeaufträge sichtert. Zu Deinen restlichen Aussagen: - PBI ungenau / zu groß: dann macht ihr das Refinement nicht richtig, genau solche Dinge sollten da geklärt werden und in der Definition of Ready hinterlegt werden - In der Tat verkommen Scrum Master manchmal zu Babysittern: Dann hat man aber meist in anderen Bereichen massive Defizite, welche in der Retro angesprochen und gelöst werden sollten. Dein Beispiel klingt nach einem klassischen Kommunikationsproblem und hätte z.B. über das Daily geklärt werden sollen. - KVP sollte selbstverständlich sein: JA, JA und JA! Das Problem ist nur, dass sich meist niemand bei KVP für den Prozess zuständig fühlt, daher gibt es den Scrum Master. - PBI zermalen ist nervig: Ja, genau das ist aber die große Herausforderung und auch ein Stück weit die Kunst von einem guten PO. Manche mögen das, manche finden das nervig - aber es kann halt auch nicht jeder Programmieren :) Das Problem mit Deinem Beispielprojekt habe ich nicht verstanden: die Probleme sind doch offenslichtlich? Gruß David
Hallo David, danke für deinen Überblick über den Prozess und die Tipps am Ende. Die sind meiner Meinung nach sehr wertvoll. Ich finde gerade zu Beginn ist es sehr wichtig, dass man so startet wie es Scrum vorgibt. Einfach Teile / Rollen / Events davon im voraus bereits wegzulassen, ohne dem ganzen die Chance zu geben sich zu entwickeln, halte ich für sehr kritisch. Man braucht Menschen, die sich darauf einlassen und daran gefallen finden. Zusätzlich muss man sich wirklich bewusst sein, dass Scrum immer Probleme hochkochen lässt. Jeder kann Probleme lösen, wenn z.B der Buildprozess nicht läuft oder Anforderung verbessert werden müssen. Der, der es aber schafft eine Athmosphäre zu schaffen, wo man ehrlich, kritisch und offen über alles reden kann, egal was es ist, hat meiner Meinung nach schon gewonnen, denn dann kannst du alles aus der Welt schaffen.
Guter Punkt mit der Atmosphäre - da hat Du Recht. Das ist ja das schöne an agilen Manifest, das regelt unter der Haube viele dieser Dinge. Klappt das bei Euch? Gruß David
@@DavidTielke Vieles funktioniert, bei einigen Punkten gibt es aber viel Potenzial. Was uns u.a Probleme bereitet ist der Wechsel zwischen Projekten die weiterentwickelt werden und welche die erst in der Neuentwicklung stecken
Wir haben auch (leider erst vor ca 1 Jahr) angefangen, unsere Projektplanung agil mit Scrum zu gestalten. Am Anfang klingt alles so einfach, aber die Umsetzung hat an vielen Ecken dann doch seine Herausforderungen. Besonders die Rollen des Product Owners und Scrum Masters gut zu besetzen hat sehr lange gedauert. Es ist leider nicht jeder dazu geschaffen. Ich finde auch die Daily Meetings mit am wichtigsten. Sie geben jedem einen klaren Überblick was getan wurde und was getan werden soll. Allerdings machen wir dieses aktuell Corona bedingt in Microsoft Teams als Chat - was finde ich, eine geniale Lösung ist. So können auch Kollegen die Urlaub haben oder krank sind, später nachschauen, was getan wurde und wo es vielleicht Probleme gab. Ich danke dir David für dieses wirklich gute Video was eigentlich den perfekten Überblick zu dem Thema liefert. Und die Folien sind ebenfalls sehr passend und auf den Punkt gebracht. Liebe Grüße aus Bremen und bis zum nächsten Video!
Vielen Dank für den Upload. Bin gerade dabei mich für meine Scrum-Master Zerti vorzubereiten und deine Erfahrung ist hilfreich um noch mal über meine eigenen Ansätze und Vorgehensweisen zu reflektieren.
Vielen Dank für das tolle Video und der tollen Erklärungen. Ein "Like" hätte es vielleicht auch getan, aber in meinen Augen bräuchte es dafür eine gesonderte Erwähnung mit Kommentar 😊
Hi David, dieses Video ist sooo geil! Alles passt. Ich bin auch enorm am verzweifeln und komme kaum noch weiter. Ich bin PO und soll in meinem Unternehmen als PO agieren. Ich nutze SCRUM in der Tat als Rahmen für die Projekte, jedoch stelle ich SCRUM nicht als "Gottes-Gesetzte" über alles. Mein Problem ist, dass KEINER in meinem Unternehmen kapiert was ein PO macht, sie verstehen SCRUM als Anfeindung und sie verstehen es nicht on-point Anforderungen zu erstellen (selbst das Wort "Userstory" ist mir verboten worden...) Dabei geht es mir nur darum, dass die Anforderungen so geschrieben werden, dass alle beteiligten genau wissen und verstehen a) welchen Prozess sie beschreiben, b) welche Herausforderungen die Userstorys ausmachen usw. Ich will das Entwicklerteam mit gezielten Infos versorgen und mit ihnen agil arbeiten, denn wenn sie keine sauberen Infos bekommen, dann kommt am Ende nur Kacke raus. Aber mein Kollegenteam boykottiert einfach alles. Kannst Du mir irgendwie helfen oder nen Tipp geben. Grüße
Hey Chrishh, ja, bin total bei Dir - wenn das Video hier gut ankommt, machen wir dazu als nächstes eins - Retrospektive ist mein Lieblingsthema bei Scrum :) Funktioniert es denn bei Euch? Gruß David
kommt drauf an wie lange das team zusammenarbeitet aber in den ersten 6 Sprints ist es eigentlich immer ein Tag, danach selten weniger als 3h. Wie lange hattet ihr Scrum in dem Team schon? Gruß David
Danke für Erklärung. Für mich eine Auffrischung, weil wir vor Jahren mal ein Scrum-Training hatten, mit der Zeit und Betriebsblindheit sich Scrum dann vielleicht auch mal verselbstständigt und man so manche Regeln nicht mehr eingehalten werden, weil sie nervig sind oder zu viel Zeit in Anspruch nehmen. Dann macht man doch wieder sein eigenes Scrum, was nach gewisser Zeit kein wirkliches Scrum mehr ist, wie du ja im Video sagst.
Hallo Julian, sehr gerne, schön das es Dir gefällt. Ja, das ist leider so ein Problem mit Scrum - wenn diese "Verselbstständigung" getrieben durch den Scrum-Master passiert, ist ja alles gut. Aber leider passiert die oft implizit und ungesteuert und damit ist das Ergebnis später nicht selten totaler Murks... Gruß David
Ich habe Scrum noch nicht korrekt umgesetzt gesehen. Die Teams die es bei uns machen verschwenden Zeit mit Daily Scrum das zu Status-Reports verkommt und 10 Leute stehen da und warten nur drauf, dass sie endlich weiterarbeiten können, nachdem sie ihre 2 Sätze gesagt haben. Und da wir Komponenten oft wegen Komplexität auf Owner aufteilen und nicht 10 Leute an 1 Feature oder Bug arbeiten (auch keine 5 oder 3), interessiert es uns nur periphär was die Kollegen gestern getan haben, heute tun, oder morgen tun wollen. Trotzdem verschwendet man mindestens 15 Minuten * 5 Tage * 10 Leute * 20 Tage = 13 Stunden pro Monat mit nutzlosem verbalen Status-Report, obwohl jeder selber im Bug- und Anforderungs-Management System bei Bedarf sehen kann, wer was macht oder gemacht hat oder machen wird. Abstimmung läuft also bei Bedarf und 15 Minuten Händchenhalten in der Kaffeeküche nützt keinem was. Sicher toll wenn man Scrum korrekt einsetzt. Wir tun's nicht... "Agil" geht auch ohne Scrum mit weniger Overhead.
Eine inhaltliche Frage: Du hast Scrum jetzt allgemein beschrieben, aber ich frage mich - wo findet die Planung für Architektur/Design Platz? Ganz besonders, wenn es um ein Grüne-Wiese-Projekt geht. Wo ist der Anfang, arbeitet der Architekt vorher allein und schafft einen Rahmen? Wie wird die Umsetzung der einzelnen Aufgaben geplant, damit man sie verteilen kann und nicht jeder qualitätsrelevante Entscheidungen allein trifft? Meine ersten Gedanken dazu: Man bezieht die Detail-Planung mit in den Scrum-Prozess ein, aber nicht als Software-Projekt, sondern als reines Planungs-Projekt. Vor dem Architektur-Entwurf entwirft der Architekt einen groben Rahmen, dann bekommt jeder Mitarbeiter einen Teil des Rahmens und baut einen kleinen Prototypen, um mögliche Probleme zu finden und Lösungen zu finden. Anstelle des Reviews werden die Erkenntnisse gesammelt und mögliche Lösungen diskutiert, die der Architekt dann mit in den Entwurf einbaut. Steht der Architektur-Entwurf, muss die Struktur auf Assembly/Klassen-Ebene geplant werden, das könnten in dem Fall je zwei Mitarbeiter machen, die für einen Teilbereich die Struktur entwerfen. Anstelle des Reviews werden die Ergebnisse gesammelt und zu einem großen Konzept zusammengeführt, der Architekt überwacht, begleitet und behält die Hoheit. Das geht dann so lange, bis jeder klar vor Augen hat, wie das Projekt am Ende strukturiert sein soll und es können für die Sprints konkrete Entwicklungsaufgaben definiert und verteilt werden. Danach geht dann die normale Entwicklungsarbeit los. Ändern sich zwischen den Sprints Teile der Anforderungen, dann wird das zumindest teilweise so für die geänderten Anforderungen wiederholt, der Rest des Teams arbeitet an den unveränderten Anforderungen weiter, sofern die Änderungen nicht zu großflächig sind. Meinen wichtigsten Punkt zu Scrum schreibe ich als eigenen Kommentar, Ordnung muss sein ^^
Ja, das Thema agile Architektur machen wir definitiv auch noch - Scrum ist ein allgemeiner Produktentwicklungsprozess, deshalb gibt es keinen speziellen Architekturpart weil den brauchen nur wir in der Softwareentwicklung. Packe es mal auf die Liste :) Wie läuft das denn bei Euch?
@@DavidTielke Gar nicht. Sowas wie "SOLID" kennt man nicht (hab das mal angesprochen und verwirrte Blicke geerntet) und Architektur- und Struktur-Entscheidungen trifft jeder selbst oder es wird im Daily zwishen zwei/drei Kollegen ausdiskutiert. Und Scrum wurde versucht und ist gescheitert, also gibt's keinen passenden Prozess dafür. Effektiv gibt also der Chef irgendwelche Vorgaben, die oft nicht mal zu den Anforderungen passen - aber die werden ja auch erst im Laufe des Projektes klar. Der einzige rote Faden durch alle Projekte sind ein paar wenige DLL-Projekt, in dem irgendwelches zusammengewürfeltes Zeug steht und regelmäßig für Probleme sorgt, alles wegen der Vorgabe: Kein doppelter Code. Zu dem Thema hattest Du auch mal ein Video gemacht und den Gedanken in den Raum gestelt, dass doppelter Code in manchen Fällen auch besser sein kann.
@@DavidTielke Ich habe nur mit zwei von den anderen vier .NET-Entwicklern darüber gesprochen und die sehen das ähnlich. Und unter den C++-Entwicklern herrscht auch Frust, aber damit habe ich zu wenig Erfahrung, um wirklich etwas sagen zu können.
Die Entscheidungsträger verstehen in der Regel nicht die Aufteilung der Im Backlog befindlichen Themen in Sprints nach deren Komplexität und Priorität. Meistens kommt nur ist morgen das Thema schon implementiert? Das ist doch nur eine kleine Änderung.
Hallo Danny, ja das mag vorkommen, zeigt aber dann einfach das es bei Euch kein agiles Mindset gibt und der Prozess nicht ernst genommen wird. Da kann man leider ohne eine Änderung nicht viel machen. Gruß David
Hi David, macht es sinn als Softwareentwicklung-Student Scrum Zertifikat zu machen? z.B Master Scrum Zert. bei TÜV; Die Studienskripten decken die Themen so oberflächlich ab, dass ich mich immer intensiv mit den Modulen durch weiteren Bücher befassen muss.🤷🏻
In meinem Projekt wird gerade Scrum eingeführt. Da sehe ich, dass ein falscher Product Owner, der von dir erwähnten Eigenschaften nicht besitzt, den ganzen Scrum Process schwer gängig werden lässt.
Tolles Video David! Hat mir als ausgebildetem Scrum-Master auch weitergeholfen. Meine Frage aber, planst du Videos zu den einzelnen Rollen? Ich glaube das würde vielen Personen (mich eingeschlossen) helfen ihre Rolle und die damit einhergehenden Aufgaben besser zu verstehen. Liebe Grüße Jonathan
Hallo Jona. Hab Deinen Beitrag erst gesehen, als ich meinen schon geschrieben hatte. In meinem Beitrag beschreibe ich, wie ich die Rolle des SM ausfülle. Vielleicht hilft Dir das, bei der Selbsteinschätzung. Du darfst meine Auslegung des Scrum Guide gerne auch kritisieren. Alles Gute!
Den für mich wichtigsten Punkt in Scrum erwähnst Du erst ganz am Ende oder indirekt durch andere Punkte: "Das Team - eine Gruppe [...] die gemeinsam Sprint für Sprint auf ein Ziel hinarbeiten" Das wichtige sind die zwei Worte "EIN Ziel". Ich denke, ein sehr großes Problem, warum bei uns eigentlich nichts wirklich funktioniert, ist, dass wir nicht ein Ziel haben, sondern ungefähr so viele völlig verschiedene Ziele wie Mitarbeiter. Obwohl wir uns Team nennen und jeden Morgen ein sog. „Daily“ machen, arbeitet am Ende wieder jeder für sich, weil jeder sein komplett eigenes Projekt hat. Wenn mal zwei zusammenarbeiten, dann heißt das meistens „Person XY entlasten“ und sieht meist so aus, dass der Kollege irgendeine Aufgabe von Person XY übernimmt, während der etwas Anderes mit hoher Prio abarbeitet und ggf. Fragen beantwortet. So kann Scrum mMn. nicht funktionieren, man muss erst dafür sorgen, dass sich ein Team bilden kann, was in unserem Fall bedeutet: Nur ein Projekt gleichzeitig für ein Team.
Hey, da hast Du recht, so kann es nicht funktionieren - Ihr seid in einem Team aber alle haben eigene Projekte?!?!? Verstehe ich nicht, erklär mal :) Gruß David
@@DavidTielke Es gibt viele Programme, die meisten klein, ein paar etwas größer. Viele sind quasi ausgelagerte Funktionalität für das große C++-Programm, da das nicht mehr wirklich wartbar ist. Die Projekte sind dann neue Features oder neue Mini-Programme, vom Umfang her durchaus von einer Person in einigen Tagen bis wenigen Wochen realisierbar. Und genau so wird auch geplant - jemand hat Zeit, dann bekommt er ein Projekt. Hat der seine Arbeit erledigt, dann geht das in das Test-Team zum testen. In der Zeit hat besagte Person wieder Zeit, ergo: Das das nächste Projekt kann begonnen werden. Danach springt er dann ständig zum alten Projekt zurück, wenn beim Test oder dem Kunden ein Problem auffällt, behebt das, organisiert, etc. Manche Mitarbeiter, die viel fachliches KnowHow tragen, haben auf diese Weise meist mehrere parallel laufende Projekte, die sie irgendwie stämmen müssen, oder sie geben eins an einen Kollegen ab. Und solange dieses Chaos nicht beseitigt wird, braucht man mMn. gar nicht mit Scrum anfangen. Oder man fängt damit an, muss dann aber auch die zwei Leute (Scrum Master und Product Owner) entsprechend besetzen (nicht der Chef!) und denen entsprechende Möglichkeiten einräumen, den Prozess zu ändern.
Wir praktizieren in unserem Unternehmen leider keine "Daily Standups" und ich vermute aus diesem Grund blähen sich dann die Retrospektiven ziemlich auf. Das resultiert dann in einer Sitzung in der teilweise 6 parallel laufenden Projekte in kürzester Zeit abgehandelt werden müssen. Die Aufmerksamkeit der Mitarbeiter ist meistens schon nach einer Stunde im Keller. Noch mehr Meetings sind bei geringer Personalstärke allerdings auch wirklich schwer einzuführen und der Chef hält diese Treffen sowieso für "Labersülze".
Hey, genau solche Situationen meinte ich - da wird es schwierig mit Scrum. Wie lange macht ihr das schon?? Wie lange dauert so eine Retrospektive denn bei Euch? Gruß Davi
@@DavidTielke Wir sind kein reines Softwareunternehmen sondern entwickeln Produkte in der Medizintechnik. Daher hat man vorher auf das Wasserfallmodell gesetzt, allerdings auch hier mit nur mäßigen Erfolg (in Sachen Tranzparenz und Prioriesierung war das ein Blindflug). Scrum machen wir ungefähr ein Jahr. Ziel war es ehrlich gesagt überhaupt erstmal einen klaren Überblick über die Aufgaben der einzelnen Mitarbeiter zu bekommen und in regelmäßigen Abständen sich die Ergebnisse vor Augen führen zu können! Die Retrospektive dauert im Schnitt 2h für ca. 6-8 parallel laufende Projekte. Sie besteht im Wesentlichen aus der Präsentation der Ergebnisse (z.B. Laboruntersuchungen oder Herstelleranfragen) und Planung des nächsten Sprints. Ich bin der einzige Softwareentwickler und leider musste ich festellen, dass sich meine Themen für nicht-Coder sehr schwer darstellen lassen..Vielen ist einfach nicht klar welcher Rattenschwanz an einem "simplen" Feature/Ticket hängt ;) LG!
Meine persönliche Meinung zu dem Thema ist, dass man auch nicht nur als Team-Mitglied, PO oder SM, sondern die Abteilung(en) und vor allem das Unternehmen das "Mindset" dafür haben muss. Es muss von allen gewollt und dann auch umgesetzt werden, konsequent. Leider klingt das alles sehr einfach, scheitert aber am Ende genau an diesem wichtigen Element. Scrum selbst konfrontiert einem dann auch noch mit alten Prozessen und Kulturen (bei Einführung), die irgendwie nicht zu Scrum zusammen passen wollen 😉 und man an verschiedenen Stellen nicht in der Lage ist, sich dann entsprechend anzupassen oder aufzustellen. Das kann man auf verschiedene Dinge übertragen. Das finde ich persönlich schade, denn einfach "agil" (weil buzzword, klingt cool und so) zu sein reicht nicht. Innerhalb eines Scrum-Projektes konnte ich bisher mitwirken und empfand es als super. Alle anderen und bisherigen Projekte habe ich "agil umgesetzt, nur nicht nach dem Schema F (Scrum, Kanban oder ähnlichem). Wasserfall und co habe ich mich schon vor ca. einem Jahrzehnt verabschiedet. Grundsätzlich finde ich Scrum und andere Frameworks wichtig und sollten konsequent umgesetzt werden, auch wenn es am Anfang ein "Hindernis" ist, profitiert man mittel- und langfristig durch die Verbesserung der Gesamtstruktur.
Beim Thema "Mindset" stimme ich dir voll zu. Jeder im Team muss ein wirkliches Interesse haben das Produkt zu verbessern bzw. die wie auch immer definierte Vision zu erreichen. Falls die Leute nur "Dienst nach Vorschrift" machen helfen auch irgendwelche agilen Rituale nicht, die Situation zu verbessern.
hey, stimmt die total zu, leider ist es sexier Scrum zu machen als nur agil zu sein - und wenn man es dann halbherzig macht... gibt es noch mehr Probleme. Agilität kann man nicht kaufen, nur leben. Gruß David
Die "Definition of Ready" ist meiner Meinung nach das Wichtigste. Essentieller Bestandteil dieser Definition ist meiner Meinung nach, dass jeder im verstanden hat, worum es in dieser Anforderung geht. So lange das nicht gewährleistet ist, kann man die Anforderung weder schätzen noch irgendwie planen. Leider wird dies in der Praxis meiner Erfahrung zu oft nicht beachtet und es landen aus verschiedenen Gründen sehr vage Anforderungen im Sprint. Dies ist aber ganz klar eine Aufgabe des Teams. Leider werden zu oft unklare Anforderungen "irgendwie geschätzt" weil sie aufgrund von Zeitbeschränkungen dringend in den nächsten Sprint müssen. Hier sind vor allem wir erfahrenere Entwickler in der Pflicht, den Finger in die Wunde zu legen, Unklarheiten anzusprechen und eine Klärung dieser einzufordern und Notfalls auch mal eine Schätzung oder Planning zu blockieren wenn es nicht anders geht. Das hat nichts mit unkooperativem Arbeiten zu tun - im Gegenteil - es zeigt die Probleme bereits beim Planning auf, die später in der Implementierung sowieso aufgetreten wären. Auch wenn das Team 100% zu Scrum committed ist, kommt es hin und wieder mal zu solchen Situationen und dann ist es natürlich gut, wenn man das trotzdem "irgendwie schaukelt". Das ist dann aber definitiv ein Thema für die nächste Retrospetkive wo man analysieren muss warum es zu dieser Situation kam und wie man dies in Zukunft vermeiden kann.
Hey Alex, total richtig - bin absolut bei dir. Das Thema Rückgrad ist sehr wichtig bei Scrum, leider sehr ich das auch bei den wenigsten Teams. Machst Du das denn als Entwickler? Gruß David
Scrum braucht auf jeden Fall das Daily, denn nichts finde ich schlimmer, als Teamkollegen, die nicht informiert sind. Das geht sprachlich im Daily am besten. Besser als im Chat
Irgendwie hat eben meine App nicht funktioniert: Wollte noch anfügen, dass es mit dem Daily zu Zeiten von Corona nur etwas schwierig ist. Über Teams ist zwar ok, aber auch kein wirklicher Ersatz. Wie macht Ihr das? Gruß David
Richtig, ein gutes Daily ist extrem wichtig. Leider hat das Daily oft den Anschein eines "Reporting Meetings" - "Gestern habe ich dies gemacht... heute werde ich das machen..." Meine besten Daylies hatte ich in einem Projekt mit einem sehr kleinen Team 3 Developer 1 Product Owner. Jedes Daily hatte den Spirit eines "Mini-Plannings". Wir machten uns einfach einen "Schlachtplan" für den folgenden Tag und im Daily diskutierten wir sämtliche Ziele, Probleme und Initiativen um dahin zu kommen wo wir am Ende des Tages landen möchten
Scrum funktioniert nur, wenn alle den "Sinn" darin erkannt haben. Und meist reicht einer, der nicht mit zieht, dann geht nichts mehr... Und wie du schon gesagt hast, müssen dann personele Konsequenzen getroffen werden, was aber meist nicht passiert.
Hallo Wolfgang, das stimmt vollkommen und ich verstehe auch nie, warum es da nicht endlich mal Konsequenzen gibt... Besonders unter Entwicklern sind halt viele, die eben nicht teamfähig sind. Habt ihr schon solche Konsequenzen gezogen? Gruß David
@@DavidTielke Welche Konsequenzen sollen den gezogen werden? Kündigung? Also in meinem Unternehmen mangelt es an Entwicklern und das Unternehmen leidet an dem Fachkräftemangel. Somit kann sich ein Entwickler quasi aufführen wir er will.
hey Zac, ohh ja :) genau deshalb habe ich gefühlt 100 Mal gesagt, dass es ein Framework ist - ich denke dass ist eine der größten Probleme in Scrum, das dieses grundlegende Verständnis fehlt :) Die Idee mit dem Spray schon patentiert? :D Gruß David
Du hast gesagt im Daily sagen wir was wir gemacht haben und machen werden. Aber was denkst du ueber diese Perspektive: Im Daily redet man ueber die Tickets, nicht ueber die Menschen
wow! Tolles, kompaktes Video! Wenn ich es richtig verstehe, folgt der agile Entwicklungsprozess dem Motto: "Ich weiß noch nicht wie und welche Anforderungen wir umsetzen, aber legen erstmal los und machen den ersten Schritt und sehen dann weiter." Trifft dieses saloppe Motto den Kern? Mir stellt sich dabei vor allem die Frage wie solch ein Entwicklungsprojekt kostenmäßig kalkuliert wird? I.d.R. möchte der Kunde vorab eine Kosten/Nutzen-Rechnung aufstellen und den ROI betrachten.
Ist es nicht so oder so offensichtlich, dass bei der Arbeit nicht alles genau nach Plan läuft. Oder haben die alle früher einfach nach Plan gearbeitet, bevor das Wort Scrum erfunden wurde, auch wenn was schief gelaufen ist. Glaube ich nicht. Man braucht nicht immer irgendwelche englischen Wörter für Dinge verwenden, die sowieso schon immer da waren, Stakeholder,Scrum usw.
Uff, gehts vielleicht auch mit normalen Ausdrücken, insbesondere im Abschnitt Sprints und Artefakte fliegen einem ja nur Fachwörter um die Ohren. Wenn sie einen Begriff erklären wie z.B Backlog usw. und dann noch mit anderen Fachbegriffen hantieren, dann versteht man nix. Einfach mehr Deutsch wagen (und das sage ich als Ausländer).
WIe immer interessiert mich, wie Ihr zu dem Thema Scrum steht und besonders "Was ist für Euch das wichtigste bei Scrum?" Die Verlosung des DWX Tickets geht bis zum 21.6. - Viel Erfolg. Und das *Abo* nicht vergessen, zu Scrum machen wir noch mehr in der Zukunft :)
Vorab. Ich halt nichts von Scrum. Mein Background: Fast 10 Jahre Erfahrung als Softwareentwickler und jetzt bald 2 Jahre Product Owner in einem Unternehmen mit > 5000 MA das eigene Produkte entwickelt, fertigt und vertreibt.
Wie fast in jedem Unternehmen das SW entwickelt, strauchelt es im SW Bereich. Backlog ist laut Jira für die nächsten 10 Jahr randvoll, ca. 50% der täglichen Arbeit wird mit Bugfixen verbracht und das Management schimpft weil die Zeitpläne nicht eingehalten werden.
Ich geh mal in die Vergangenheit. Vor ca. 8 Jahren haben bei uns einige Teams mit Scrum angefangen. Sie hatten das Problem, dass sie ständig während der Entwicklung von Sachen unterbrochen wurden und nichts fertig machen konnten, weil sie wieder wo anderes was neues implementieren sollten. Idee: Wir führen Scrum ein, damit transparent festgehalten wird, an was die nächsten 2 Wochen (fokussiert) gearbeitet wird. Ein Entwickler aus einem anderen Team wurde Scrum Master und ein Projektleiter wurde PO. Aber so richtig funktioniert hat das nicht. Hier muss ich noch anmerken, dass das Team Scrum eingeführt hat, ohne dem Wissen des Top Managements. Die wussten zum dem Zeitpunkt vermutlich nicht mal was Scrum und Agil bedeutet. Wenig überraschend ist es immer wieder dazugekommen, dass Sprints von der Geschäftsleitung gecrasht wurden. OK das kann passieren, dass man mal was sehr wichtiges vorziehen muss, aber es kam irgendwie zu oft vor. Natürlich war der Frust bei den Entwicklern dementsprechend groß und das Team hat schon darüber nachgedacht das mit Scrum wieder zu lassen.
Aber das Top Management wurde rund um die Probleme in der SW Entwicklung „aktiv“. Angefangen wurde damit einen Softwareentwicklungsprozess auszuarbeiten. Weil hier wurde vermutlich ein bisschen die Idee von Lean aufgeschnappt. Entwicklung ist ein Prozess der immer die gleichen Schritte hat und somit kann man Features wie am Fließband produzieren. „Haha“ Dieser Prozess wurde in ein PDF mit ca. 50 Seiten gegossen und in Form von Schulungen ausgerollt. Dieses Dokument enthält Definitionen für Rollen, Artefakte (wie Lasten- und Pflichtenheft ;-) ) usw., basierend auf dem V-Modell XT, Arc 42, Scrum, Kanban, SAFe usw. An dieser Stelle könnte man mal Bingo sagen. In dem Zusammenhang wurde dann noch Jira eingeführt, damit der Prozess mit über 20 Issue Typen und 100 Zuständen transparent ist. Währendes wurden auch noch andere Prozesse wie Anforderungs, Ideen, Änderungsmanagements ausgearbeitet und eingeführt. Mein Fazit: Klingt toll, aber diese Dokumente haben eigentlich mehr Fragen aufgeworfen als sie beantworten hätte sollen. Ist auch klar. Diese Dokumente wurden zum Teil von Leuten geschrieben die vielleicht mal in der Schule ein „Hello World“ programmiert haben. Natürlich wurde für diese ganzen Themen externe Hilfe herbei gezogen, Aber zum Ende dieser Phase wurde die Zusammenarbeit mit dem ersten externen Beratungsunternehmen beendet.
Vor ca. 3 Jahren hat das Top Management hat Wort „Agil“ (in einer Buchstabensuppe) entdeckt. Vermutlich in dem Zusammenhang - Mit agil werden die Software Entwickler schneller. Nein. Ein weiteres großes Beratungsunternehmen wurde engagiert mit dem Ziel eine agile Transformation im Unternehmen einzuläuten. Eine große Veranstaltung wurde gemacht wo alle vom agilen Arbeiten überzeugt werden sollen. Gefolgt von 100erten super teuren Beratungsstunden. Dieses Beratungsunternehmen hat es aber glaube ich geschafft dem Top Management klar zu machen, dass wenn man eine agile Transformation durchführt werden soll, das Top Management auch agil sein muss.
Wenn man eine agile Transformation macht will wird natürlich gerne Scrum eingeführt - ist ja (gerade) modern. Darum wurden ca. 5 Vollzeit Scrum Master eingestellt und Product Owner installiert.
Jedoch hat dieses Beratungsunternehmen einen Zwist in das Unternehmen gebracht. Dieses Beratungsunternehmen hat ihr eigenes agiles Framework entwickelt und dieses wollte bzw. hat es zum Teil mittels Musterprojekten eingeführt. Jedoch ist dieses nicht mit firmeneigenem Softwareentwicklungsstandard konform, mit dem der Großteil entwickelt wurde. Schlussendlich haben einige interne Leute gesagt: „Wie sollen wir jetzt arbeiten?“ und das Management hat sich dazu entschieden die Zusammenarbeit mit diesem Beratungsunternehmen zu beenden bzw. nicht weiter verlängert und diese eingeführten Sachen wurden über Bord geworfen.
Man kann sich jetzt Fragen wieso schreib ich das jetzt alles? Naja vielleicht habe ich einen Schaden von dem ganzen agilen Zeugs davon getragen und bin deswegen kein Fan von Scrum. Aber vielleicht kommt (bzw. kam) auch der Schaden von diesen hardcore Scrum Mastern, die versucht haben in jedem kleinen Fleck im Unternehmen Scrum zu machen. Angefangen von der Softwareentwicklung bis hin zum Support. Kein Scherz. Auch im Support soll ein Mitarbeitern schätzen, wie langer er für die Lösung von einem Problem braucht. Naja ich halte davon nichts.
Hier muss ich mal festhalten, dass ich vom agilen Arbeiten natürlich schon was halte. Aber ich verdrehe halt die Augen wenn man dazu „agil“ sagt. Für mich ist das intuitiv wenn Software in kleine funktionale Teile runter bricht. Wer will schon ein Jahr Anforderungen schreiben ohne eine echte Funktionalität zu sehen? Also ich würde das nicht aushalten.
Zurück zu Scrum. Ich habe da jetzt zwei Sichtweisen drauf. Ich fange mal von der Sicht des Dev Teams an. Würde ich in einem Scrum Team sein, würde mich das Schätzen von User Stories stören. Man bekommt ja oft Sachen vorgelegt die man machen soll, zum Teil nicht klar ist was gemacht werden soll, die User Story sehr groß ist, bzw. man keine Expertise auf dem Gebiet hat. Und dann soll man das Schätzen und ein commitment machen. *bäh* Wenn man jetzt eine Person ist, die gut SW schreiben will, immer sein Wort halten möchte und kein Zeit gefühlt hat, dann kommt da bei mir ein innerlicher Stress auf, dass sich negativ auf die Arbeitsleistung auswirkt. Hier kann man einhacken. Ja aber man schätzt ja eh im Team. Sollte so sein, ist aber oft nicht so. Weil oft ist es so, dass sich nur einer in der Software auskennt.
Bei uns im Unternehmen kommt mir vor, dass Scrum Master überall dort eingesetzt werden, wo „Babysitter“ benötigt werden. Ich schlage oft innerlich die Hände über dem Kopf zusammen, was mir die Scrum Master von ihrer täglichen Arbeit erzählen. Beispiel: Mitarbeiter A kennst sich wo nicht aus und weiß das Mitarbeiter B ihm da weiterhelfen kann. Jedoch will Mitarbeiter A nicht Mitarbeiter B bei seiner Arbeit stören und kommt deswegen bei seiner Arbeit weiter und das obwohl sie Tisch an Tisch sitzen. Und um solche Fälle müssen sich bei uns Scrum Master kümmern. Ich nenne das „betreutes programmieren“. Anderes gesagt es ist traurig wenn ein Scrum Master benötigt wird das ein Daily gemacht wird oder man sich kontinuierlich verbessern will. Sicher immer weiter zu verbessern sollte ja selbstverständlich sein.
Aus der Sicht des Product Owners sehe ich da wieder andere Herausforderungen. Ziel von agiler Softwareentwicklung ist ja „Value“ dem Kunden zu liefern. In Scrum soll ja nach jedem Sprint ein „potentielles“ Release geliefert werden können. Sprich in Scrum müssen die Stories dementsprechend klein sein, dass sie innerhalb von z.B. 2 Wochen implementiert werden kann. Und wenn zu groß dann muss man sich kleiner bekommen. Und dieses „zermahlen“ von Sachen ist echt schwierig und würde mich nerven.
Zum Beispiel habe ich jetzt gerade ein Software Projekt. Drei Entwickler sollen eine Datenbank aufsetzen, mit einem Webfrontend bestehend aus einer Seite. Diese Seite enthält ca 5 Suchfelder und die Suchergebenisse werden beim Drücken einer Schaltfläche aufgelistet (sehr einfache Anwendung). Das ganze habe ich in eine User Stories gepackt, weil es den Stakeholder einen Mehrwert bietet. Ich dachte auch, würden wir Scrum machen würde sich das durchaus in 2 Wochen ausgehen. Angefangen wurde damit Anfang 2021 und nach 6 Monaten sind die 3 Entwickler damit fertig geworden. Warum? Weil diese drei Entwickler eigentlich immer Embedded Software in C++ entwickelt haben und dieses Mal zum ersten Mal in C#.
Hallo Franz,
alleine Dein erster Absatz zeigt ganz hervorragend genau die Auswirkungen des ersten Profi Tipps am Ende: Wenn das Management nicht mitzieht und diese Agilen Werte vorlebt, dann kann das gar nicht funktionieren. Agile nur in einem kleinen Team zu sein ist sehr sehr schwer wenn das Umfeld nicht mitspielt und oft geht es schief.
Der neu aufgesetzte Prozess klingt schon vom Start weg (in meinen Augen) viel zu kompliziert. Ich würde sagen Deine Vorgesetzten haben agilität und kontinuierliche Verbesserung nicht verstanden und die Chance und das Potenzial überhaupt nicht genutzt. Ihr hättet mit Scrum und einem richtig guten Scrum Master starten sollen und dann diese Transition von Sprint zu Sprint machen sollen. Dann hätte das Ergebnis zu 100% gepasst und ihr hättet es schrittweise adaptieren können ohne alle zu überfordern. Und auch das engagierte Unternehmen hat Euer Problem nicht gelöst, auch wenn der Ansatz super war. Agilität ist nichts was man einkauft sondern ist eine Denk- und Handlungsweise die schrittweise in ein Unternehmen getragen werden muss, das dauert sehr lange und erfordert viel Arbeit. Und warum das Beratungsunternehmen ausgerechnet ein eigenes Agiles Modell gebraucht hat, verstehe ich schon - die Standardmodelle da draußen sind sehr gut für sehr viele Situationen geeignet. Aber wenn Ihr deren Modell nutzt besteht natürlich eine gewisse Abhängigkeit zu dem Unternehmen was Folgeaufträge sichtert.
Zu Deinen restlichen Aussagen:
- PBI ungenau / zu groß: dann macht ihr das Refinement nicht richtig, genau solche Dinge sollten da geklärt werden und in der Definition of Ready hinterlegt werden
- In der Tat verkommen Scrum Master manchmal zu Babysittern: Dann hat man aber meist in anderen Bereichen massive Defizite, welche in der Retro angesprochen und gelöst werden sollten. Dein Beispiel klingt nach einem klassischen Kommunikationsproblem und hätte z.B. über das Daily geklärt werden sollen.
- KVP sollte selbstverständlich sein: JA, JA und JA! Das Problem ist nur, dass sich meist niemand bei KVP für den Prozess zuständig fühlt, daher gibt es den Scrum Master.
- PBI zermalen ist nervig: Ja, genau das ist aber die große Herausforderung und auch ein Stück weit die Kunst von einem guten PO. Manche mögen das, manche finden das nervig - aber es kann halt auch nicht jeder Programmieren :)
Das Problem mit Deinem Beispielprojekt habe ich nicht verstanden: die Probleme sind doch offenslichtlich?
Gruß David
Hallo David, danke für deinen Überblick über den Prozess und die Tipps am Ende. Die sind meiner Meinung nach sehr wertvoll.
Ich finde gerade zu Beginn ist es sehr wichtig, dass man so startet wie es Scrum vorgibt. Einfach Teile / Rollen / Events davon im voraus bereits wegzulassen, ohne dem ganzen die Chance zu geben sich zu entwickeln, halte ich für sehr kritisch. Man braucht Menschen, die sich darauf einlassen und daran gefallen finden.
Zusätzlich muss man sich wirklich bewusst sein, dass Scrum immer Probleme hochkochen lässt. Jeder kann Probleme lösen, wenn z.B der Buildprozess nicht läuft oder Anforderung verbessert werden müssen. Der, der es aber schafft eine Athmosphäre zu schaffen, wo man ehrlich, kritisch und offen über alles reden kann, egal was es ist, hat meiner Meinung nach schon gewonnen, denn dann kannst du alles aus der Welt schaffen.
Guter Punkt mit der Atmosphäre - da hat Du Recht. Das ist ja das schöne an agilen Manifest, das regelt unter der Haube viele dieser Dinge. Klappt das bei Euch?
Gruß David
@@DavidTielke Vieles funktioniert, bei einigen Punkten gibt es aber viel Potenzial. Was uns u.a Probleme bereitet ist der Wechsel zwischen Projekten die weiterentwickelt werden und welche die erst in der Neuentwicklung stecken
Wir haben auch (leider erst vor ca 1 Jahr) angefangen, unsere Projektplanung agil mit Scrum zu gestalten. Am Anfang klingt alles so einfach, aber die Umsetzung hat an vielen Ecken dann doch seine Herausforderungen.
Besonders die Rollen des Product Owners und Scrum Masters gut zu besetzen hat sehr lange gedauert. Es ist leider nicht jeder dazu geschaffen.
Ich finde auch die Daily Meetings mit am wichtigsten. Sie geben jedem einen klaren Überblick was getan wurde und was getan werden soll.
Allerdings machen wir dieses aktuell Corona bedingt in Microsoft Teams als Chat - was finde ich, eine geniale Lösung ist. So können auch Kollegen die Urlaub haben oder krank sind, später nachschauen, was getan wurde und wo es vielleicht Probleme gab.
Ich danke dir David für dieses wirklich gute Video was eigentlich den perfekten Überblick zu dem Thema liefert. Und die Folien sind ebenfalls sehr passend und auf den Punkt gebracht.
Liebe Grüße aus Bremen und bis zum nächsten Video!
Und läuft Scrum den jetzt bei Euch?
Gruß David
Vielen Dank für den Upload. Bin gerade dabei mich für meine Scrum-Master Zerti vorzubereiten und deine Erfahrung ist hilfreich um noch mal über meine eigenen Ansätze und Vorgehensweisen zu reflektieren.
Hi, allerseits, ich glaube, ich bleibe lieber, bei meiner guten alte Mindmap Methode, da mache ich nichts falsch, aber danke für die Aufklärung.
Vielen Dank für das tolle Video und der tollen Erklärungen. Ein "Like" hätte es vielleicht auch getan, aber in meinen Augen bräuchte es dafür eine gesonderte Erwähnung mit Kommentar 😊
Hi David, dieses Video ist sooo geil! Alles passt. Ich bin auch enorm am verzweifeln und komme kaum noch weiter. Ich bin PO und soll in meinem Unternehmen als PO agieren. Ich nutze SCRUM in der Tat als Rahmen für die Projekte, jedoch stelle ich SCRUM nicht als "Gottes-Gesetzte" über alles. Mein Problem ist, dass KEINER in meinem Unternehmen kapiert was ein PO macht, sie verstehen SCRUM als Anfeindung und sie verstehen es nicht on-point Anforderungen zu erstellen (selbst das Wort "Userstory" ist mir verboten worden...) Dabei geht es mir nur darum, dass die Anforderungen so geschrieben werden, dass alle beteiligten genau wissen und verstehen a) welchen Prozess sie beschreiben, b) welche Herausforderungen die Userstorys ausmachen usw. Ich will das Entwicklerteam mit gezielten Infos versorgen und mit ihnen agil arbeiten, denn wenn sie keine sauberen Infos bekommen, dann kommt am Ende nur Kacke raus. Aber mein Kollegenteam boykottiert einfach alles. Kannst Du mir irgendwie helfen oder nen Tipp geben. Grüße
Danke für dieses Video ! Hat mir sehr geholfen !
Ist der Scrummaster auch automatisch der Vorgesetzte? Oder wie wird das in der Praxis meist gehandhabt? Vielen Dank für das super Video!
Für mich ist das wichtigste in Scrum die Retrospektive, aber sie bringt nur was, wenn man auch kritisieren kann was nicht gut gelaufen ist.
Hey Chrishh,
ja, bin total bei Dir - wenn das Video hier gut ankommt, machen wir dazu als nächstes eins - Retrospektive ist mein Lieblingsthema bei Scrum :)
Funktioniert es denn bei Euch?
Gruß David
@@DavidTielke Es könnte besser laufen, bin aber auch relativ Frisch im Team
wie lange dauert die Retro im Schnitt?
Gruß David
Die letzte war ca. 3h, bei meiner Letzten Firma ging es aber Teilweise auch den ganzen Tag. Wie lange dauern sie bei dir so?
kommt drauf an wie lange das team zusammenarbeitet aber in den ersten 6 Sprints ist es eigentlich immer ein Tag, danach selten weniger als 3h. Wie lange hattet ihr Scrum in dem Team schon?
Gruß David
Danke für Erklärung. Für mich eine Auffrischung, weil wir vor Jahren mal ein Scrum-Training hatten, mit der Zeit und Betriebsblindheit sich Scrum dann vielleicht auch mal verselbstständigt und man so manche Regeln nicht mehr eingehalten werden, weil sie nervig sind oder zu viel Zeit in Anspruch nehmen. Dann macht man doch wieder sein eigenes Scrum, was nach gewisser Zeit kein wirkliches Scrum mehr ist, wie du ja im Video sagst.
Hallo Julian,
sehr gerne, schön das es Dir gefällt. Ja, das ist leider so ein Problem mit Scrum - wenn diese "Verselbstständigung" getrieben durch den Scrum-Master passiert, ist ja alles gut. Aber leider passiert die oft implizit und ungesteuert und damit ist das Ergebnis später nicht selten totaler Murks...
Gruß David
Ich habe Scrum noch nicht korrekt umgesetzt gesehen.
Die Teams die es bei uns machen verschwenden Zeit mit Daily Scrum das zu Status-Reports verkommt und 10 Leute stehen da und warten nur drauf,
dass sie endlich weiterarbeiten können, nachdem sie ihre 2 Sätze gesagt haben.
Und da wir Komponenten oft wegen Komplexität auf Owner aufteilen und nicht 10 Leute an 1 Feature oder Bug arbeiten (auch keine 5 oder 3),
interessiert es uns nur periphär was die Kollegen gestern getan haben, heute tun, oder morgen tun wollen.
Trotzdem verschwendet man mindestens 15 Minuten * 5 Tage * 10 Leute * 20 Tage = 13 Stunden pro Monat mit nutzlosem verbalen Status-Report,
obwohl jeder selber im Bug- und Anforderungs-Management System bei Bedarf sehen kann, wer was macht oder gemacht hat oder machen wird.
Abstimmung läuft also bei Bedarf und 15 Minuten Händchenhalten in der Kaffeeküche nützt keinem was.
Sicher toll wenn man Scrum korrekt einsetzt. Wir tun's nicht...
"Agil" geht auch ohne Scrum mit weniger Overhead.
Sind Softwareentwickler für Industrieanwendungen, also Automatisierungstechnik eigentlich ein ganz anderer Fall?
Eine inhaltliche Frage:
Du hast Scrum jetzt allgemein beschrieben, aber ich frage mich - wo findet die Planung für Architektur/Design Platz? Ganz besonders, wenn es um ein Grüne-Wiese-Projekt geht.
Wo ist der Anfang, arbeitet der Architekt vorher allein und schafft einen Rahmen? Wie wird die Umsetzung der einzelnen Aufgaben geplant, damit man sie verteilen kann und nicht jeder qualitätsrelevante Entscheidungen allein trifft?
Meine ersten Gedanken dazu:
Man bezieht die Detail-Planung mit in den Scrum-Prozess ein, aber nicht als Software-Projekt, sondern als reines Planungs-Projekt.
Vor dem Architektur-Entwurf entwirft der Architekt einen groben Rahmen, dann bekommt jeder Mitarbeiter einen Teil des Rahmens und baut einen kleinen Prototypen, um mögliche Probleme zu finden und Lösungen zu finden. Anstelle des Reviews werden die Erkenntnisse gesammelt und mögliche Lösungen diskutiert, die der Architekt dann mit in den Entwurf einbaut.
Steht der Architektur-Entwurf, muss die Struktur auf Assembly/Klassen-Ebene geplant werden, das könnten in dem Fall je zwei Mitarbeiter machen, die für einen Teilbereich die Struktur entwerfen. Anstelle des Reviews werden die Ergebnisse gesammelt und zu einem großen Konzept zusammengeführt, der Architekt überwacht, begleitet und behält die Hoheit.
Das geht dann so lange, bis jeder klar vor Augen hat, wie das Projekt am Ende strukturiert sein soll und es können für die Sprints konkrete Entwicklungsaufgaben definiert und verteilt werden.
Danach geht dann die normale Entwicklungsarbeit los. Ändern sich zwischen den Sprints Teile der Anforderungen, dann wird das zumindest teilweise so für die geänderten Anforderungen wiederholt, der Rest des Teams arbeitet an den unveränderten Anforderungen weiter, sofern die Änderungen nicht zu großflächig sind.
Meinen wichtigsten Punkt zu Scrum schreibe ich als eigenen Kommentar, Ordnung muss sein ^^
Ja, das Thema agile Architektur machen wir definitiv auch noch - Scrum ist ein allgemeiner Produktentwicklungsprozess, deshalb gibt es keinen speziellen Architekturpart weil den brauchen nur wir in der Softwareentwicklung. Packe es mal auf die Liste :) Wie läuft das denn bei Euch?
@@DavidTielke
Gar nicht.
Sowas wie "SOLID" kennt man nicht (hab das mal angesprochen und verwirrte Blicke geerntet) und Architektur- und Struktur-Entscheidungen trifft jeder selbst oder es wird im Daily zwishen zwei/drei Kollegen ausdiskutiert.
Und Scrum wurde versucht und ist gescheitert, also gibt's keinen passenden Prozess dafür.
Effektiv gibt also der Chef irgendwelche Vorgaben, die oft nicht mal zu den Anforderungen passen - aber die werden ja auch erst im Laufe des Projektes klar.
Der einzige rote Faden durch alle Projekte sind ein paar wenige DLL-Projekt, in dem irgendwelches zusammengewürfeltes Zeug steht und regelmäßig für Probleme sorgt, alles wegen der Vorgabe: Kein doppelter Code. Zu dem Thema hattest Du auch mal ein Video gemacht und den Gedanken in den Raum gestelt, dass doppelter Code in manchen Fällen auch besser sein kann.
Siehst mit du das so oder mehrere in Deinem Team?
Gruß David
@@DavidTielke Ich habe nur mit zwei von den anderen vier .NET-Entwicklern darüber gesprochen und die sehen das ähnlich.
Und unter den C++-Entwicklern herrscht auch Frust, aber damit habe ich zu wenig Erfahrung, um wirklich etwas sagen zu können.
schade zu hören, klingt nach ernsthaften Problem...
Gruß David
Die Entscheidungsträger verstehen in der Regel nicht die Aufteilung der Im Backlog befindlichen Themen in Sprints nach deren Komplexität und Priorität. Meistens kommt nur ist morgen das Thema schon implementiert? Das ist doch nur eine kleine Änderung.
Hallo Danny,
ja das mag vorkommen, zeigt aber dann einfach das es bei Euch kein agiles Mindset gibt und der Prozess nicht ernst genommen wird. Da kann man leider ohne eine Änderung nicht viel machen.
Gruß David
Hi David, macht es sinn als Softwareentwicklung-Student Scrum Zertifikat zu machen? z.B Master Scrum Zert. bei TÜV; Die Studienskripten decken die Themen so oberflächlich ab, dass ich mich immer intensiv mit den Modulen durch weiteren Bücher befassen muss.🤷🏻
In meinem Projekt wird gerade Scrum eingeführt. Da sehe ich, dass ein falscher Product Owner, der von dir erwähnten Eigenschaften nicht besitzt, den ganzen Scrum Process schwer gängig werden lässt.
Hey,
ja, das ist leider eins der Probleme am Anfang und oft auch das, was dann zum scheitern führt. Ich hoffe Ihr habt das im Griff?
Gruß David
Tolles Video David! Hat mir als ausgebildetem Scrum-Master auch weitergeholfen.
Meine Frage aber, planst du Videos zu den einzelnen Rollen? Ich glaube das würde vielen Personen (mich eingeschlossen) helfen ihre Rolle und die damit einhergehenden Aufgaben besser zu verstehen.
Liebe Grüße Jonathan
Hallo Jona. Hab Deinen Beitrag erst gesehen, als ich meinen schon geschrieben hatte. In meinem Beitrag beschreibe ich, wie ich die Rolle des SM ausfülle. Vielleicht hilft Dir das, bei der Selbsteinschätzung. Du darfst meine Auslegung des Scrum Guide gerne auch kritisieren. Alles Gute!
Den für mich wichtigsten Punkt in Scrum erwähnst Du erst ganz am Ende oder indirekt durch andere Punkte:
"Das Team - eine Gruppe [...] die gemeinsam Sprint für Sprint auf ein Ziel hinarbeiten"
Das wichtige sind die zwei Worte "EIN Ziel".
Ich denke, ein sehr großes Problem, warum bei uns eigentlich nichts wirklich funktioniert, ist, dass wir nicht ein Ziel haben, sondern ungefähr so viele völlig verschiedene Ziele wie Mitarbeiter. Obwohl wir uns Team nennen und jeden Morgen ein sog. „Daily“ machen, arbeitet am Ende wieder jeder für sich, weil jeder sein komplett eigenes Projekt hat.
Wenn mal zwei zusammenarbeiten, dann heißt das meistens „Person XY entlasten“ und sieht meist so aus, dass der Kollege irgendeine Aufgabe von Person XY übernimmt, während der etwas Anderes mit hoher Prio abarbeitet und ggf. Fragen beantwortet.
So kann Scrum mMn. nicht funktionieren, man muss erst dafür sorgen, dass sich ein Team bilden kann, was in unserem Fall bedeutet: Nur ein Projekt gleichzeitig für ein Team.
Hey,
da hast Du recht, so kann es nicht funktionieren - Ihr seid in einem Team aber alle haben eigene Projekte?!?!? Verstehe ich nicht, erklär mal :)
Gruß David
@@DavidTielke Es gibt viele Programme, die meisten klein, ein paar etwas größer. Viele sind quasi ausgelagerte Funktionalität für das große C++-Programm, da das nicht mehr wirklich wartbar ist.
Die Projekte sind dann neue Features oder neue Mini-Programme, vom Umfang her durchaus von einer Person in einigen Tagen bis wenigen Wochen realisierbar.
Und genau so wird auch geplant - jemand hat Zeit, dann bekommt er ein Projekt. Hat der seine Arbeit erledigt, dann geht das in das Test-Team zum testen. In der Zeit hat besagte Person wieder Zeit, ergo: Das das nächste Projekt kann begonnen werden. Danach springt er dann ständig zum alten Projekt zurück, wenn beim Test oder dem Kunden ein Problem auffällt, behebt das, organisiert, etc. Manche Mitarbeiter, die viel fachliches KnowHow tragen, haben auf diese Weise meist mehrere parallel laufende Projekte, die sie irgendwie stämmen müssen, oder sie geben eins an einen Kollegen ab.
Und solange dieses Chaos nicht beseitigt wird, braucht man mMn. gar nicht mit Scrum anfangen.
Oder man fängt damit an, muss dann aber auch die zwei Leute (Scrum Master und Product Owner) entsprechend besetzen (nicht der Chef!) und denen entsprechende Möglichkeiten einräumen, den Prozess zu ändern.
ich würde sagen, in der Umgebung passt Scrum hat nicht, schon mal Kanban probiert?
Gruß David
@@DavidTielke Soweit ich weiß nicht.
Und ich persönlich kenne es auch quasi nur vom Namen.
Machst Du noch ein Video dazu? :D
jupp, ist auf der Liste, dauert aber noch etwas :)
Gruß David
Wir praktizieren in unserem Unternehmen leider keine "Daily Standups" und ich vermute aus diesem Grund blähen sich dann die Retrospektiven ziemlich auf. Das resultiert dann in einer Sitzung in der teilweise 6 parallel laufenden Projekte in kürzester Zeit abgehandelt werden müssen. Die Aufmerksamkeit der Mitarbeiter ist meistens schon nach einer Stunde im Keller. Noch mehr Meetings sind bei geringer Personalstärke allerdings auch wirklich schwer einzuführen und der Chef hält diese Treffen sowieso für "Labersülze".
Hey,
genau solche Situationen meinte ich - da wird es schwierig mit Scrum. Wie lange macht ihr das schon?? Wie lange dauert so eine Retrospektive denn bei Euch?
Gruß Davi
@@DavidTielke Wir sind kein reines Softwareunternehmen sondern entwickeln Produkte in der Medizintechnik. Daher hat man vorher auf das Wasserfallmodell gesetzt, allerdings auch hier mit nur mäßigen Erfolg (in Sachen Tranzparenz und Prioriesierung war das ein Blindflug). Scrum machen wir ungefähr ein Jahr. Ziel war es ehrlich gesagt überhaupt erstmal einen klaren Überblick über die Aufgaben der einzelnen Mitarbeiter zu bekommen und in regelmäßigen Abständen sich die Ergebnisse vor Augen führen zu können! Die Retrospektive dauert im Schnitt 2h für ca. 6-8 parallel laufende Projekte. Sie besteht im Wesentlichen aus der Präsentation der Ergebnisse (z.B. Laboruntersuchungen oder Herstelleranfragen) und Planung des nächsten Sprints. Ich bin der einzige Softwareentwickler und leider musste ich festellen, dass sich meine Themen für nicht-Coder sehr schwer darstellen lassen..Vielen ist einfach nicht klar welcher Rattenschwanz an einem "simplen" Feature/Ticket hängt ;) LG!
Meine persönliche Meinung zu dem Thema ist, dass man auch nicht nur als Team-Mitglied, PO oder SM, sondern die Abteilung(en) und vor allem das Unternehmen das "Mindset" dafür haben muss. Es muss von allen gewollt und dann auch umgesetzt werden, konsequent. Leider klingt das alles sehr einfach, scheitert aber am Ende genau an diesem wichtigen Element. Scrum selbst konfrontiert einem dann auch noch mit alten Prozessen und Kulturen (bei Einführung), die irgendwie nicht zu Scrum zusammen passen wollen 😉 und man an verschiedenen Stellen nicht in der Lage ist, sich dann entsprechend anzupassen oder aufzustellen. Das kann man auf verschiedene Dinge übertragen. Das finde ich persönlich schade, denn einfach "agil" (weil buzzword, klingt cool und so) zu sein reicht nicht.
Innerhalb eines Scrum-Projektes konnte ich bisher mitwirken und empfand es als super. Alle anderen und bisherigen Projekte habe ich "agil umgesetzt, nur nicht nach dem Schema F (Scrum, Kanban oder ähnlichem). Wasserfall und co habe ich mich schon vor ca. einem Jahrzehnt verabschiedet.
Grundsätzlich finde ich Scrum und andere Frameworks wichtig und sollten konsequent umgesetzt werden, auch wenn es am Anfang ein "Hindernis" ist, profitiert man mittel- und langfristig durch die Verbesserung der Gesamtstruktur.
Beim Thema "Mindset" stimme ich dir voll zu. Jeder im Team muss ein wirkliches Interesse haben das Produkt zu verbessern bzw. die wie auch immer definierte Vision zu erreichen. Falls die Leute nur "Dienst nach Vorschrift" machen helfen auch irgendwelche agilen Rituale nicht, die Situation zu verbessern.
hey,
stimmt die total zu, leider ist es sexier Scrum zu machen als nur agil zu sein - und wenn man es dann halbherzig macht... gibt es noch mehr Probleme. Agilität kann man nicht kaufen, nur leben.
Gruß David
@Alex Rampp: richtig, sie sind sogar richtig schädlich... das waren die personellen Konsequenzen die ich angesprochen habe.
Gruß David
Die "Definition of Ready" ist meiner Meinung nach das Wichtigste. Essentieller Bestandteil dieser Definition ist meiner Meinung nach, dass jeder im verstanden hat, worum es in dieser Anforderung geht. So lange das nicht gewährleistet ist, kann man die Anforderung weder schätzen noch irgendwie planen. Leider wird dies in der Praxis meiner Erfahrung zu oft nicht beachtet und es landen aus verschiedenen Gründen sehr vage Anforderungen im Sprint.
Dies ist aber ganz klar eine Aufgabe des Teams. Leider werden zu oft unklare Anforderungen "irgendwie geschätzt" weil sie aufgrund von Zeitbeschränkungen dringend in den nächsten Sprint müssen. Hier sind vor allem wir erfahrenere Entwickler in der Pflicht, den Finger in die Wunde zu legen, Unklarheiten anzusprechen und eine Klärung dieser einzufordern und Notfalls auch mal eine Schätzung oder Planning zu blockieren wenn es nicht anders geht. Das hat nichts mit unkooperativem Arbeiten zu tun - im Gegenteil - es zeigt die Probleme bereits beim Planning auf, die später in der Implementierung sowieso aufgetreten wären.
Auch wenn das Team 100% zu Scrum committed ist, kommt es hin und wieder mal zu solchen Situationen und dann ist es natürlich gut, wenn man das trotzdem "irgendwie schaukelt". Das ist dann aber definitiv ein Thema für die nächste Retrospetkive wo man analysieren muss warum es zu dieser Situation kam und wie man dies in Zukunft vermeiden kann.
Hey Alex, total richtig - bin absolut bei dir. Das Thema Rückgrad ist sehr wichtig bei Scrum, leider sehr ich das auch bei den wenigsten Teams. Machst Du das denn als Entwickler?
Gruß David
Scrum braucht auf jeden Fall das Daily, denn nichts finde ich schlimmer, als Teamkollegen, die nicht informiert sind. Das geht sprachlich im Daily am besten. Besser als im Chat
verstehe ich total, hatte leider nur 5 Plätze frei :)
Gruß David
Irgendwie hat eben meine App nicht funktioniert: Wollte noch anfügen, dass es mit dem Daily zu Zeiten von Corona nur etwas schwierig ist. Über Teams ist zwar ok, aber auch kein wirklicher Ersatz. Wie macht Ihr das?
Gruß David
Richtig, ein gutes Daily ist extrem wichtig.
Leider hat das Daily oft den Anschein eines "Reporting Meetings" - "Gestern habe ich dies gemacht... heute werde ich das machen..."
Meine besten Daylies hatte ich in einem Projekt mit einem sehr kleinen Team 3 Developer 1 Product Owner. Jedes Daily hatte den Spirit eines "Mini-Plannings". Wir machten uns einfach einen "Schlachtplan" für den folgenden Tag und im Daily diskutierten wir sämtliche Ziele, Probleme und Initiativen um dahin zu kommen wo wir am Ende des Tages landen möchten
Scrum funktioniert nur, wenn alle den "Sinn" darin erkannt haben. Und meist reicht einer, der nicht mit zieht, dann geht nichts mehr...
Und wie du schon gesagt hast, müssen dann personele Konsequenzen getroffen werden, was aber meist nicht passiert.
Hallo Wolfgang,
das stimmt vollkommen und ich verstehe auch nie, warum es da nicht endlich mal Konsequenzen gibt... Besonders unter Entwicklern sind halt viele, die eben nicht teamfähig sind. Habt ihr schon solche Konsequenzen gezogen?
Gruß David
@@DavidTielke Welche Konsequenzen sollen den gezogen werden? Kündigung? Also in meinem Unternehmen mangelt es an Entwicklern und das Unternehmen leidet an dem Fachkräftemangel. Somit kann sich ein Entwickler quasi aufführen wir er will.
Scrum bzw. Agile wird oft davon gesprochen wie es ist ein Produkt was Mann kaufen kann. "Schick mal Tobias los, wir brauchen mehr Agile Spray."
hey Zac,
ohh ja :) genau deshalb habe ich gefühlt 100 Mal gesagt, dass es ein Framework ist - ich denke dass ist eine der größten Probleme in Scrum, das dieses grundlegende Verständnis fehlt :) Die Idee mit dem Spray schon patentiert? :D
Gruß David
Die Hintergrundmusik lenkt ab und stört.
Ganz ehrlich, Scrum ist der allerletzte Scheiss. Und zwar so richtig
Du hast gesagt im Daily sagen wir was wir gemacht haben und machen werden. Aber was denkst du ueber diese Perspektive: Im Daily redet man ueber die Tickets, nicht ueber die Menschen
wow! Tolles, kompaktes Video! Wenn ich es richtig verstehe, folgt der agile Entwicklungsprozess dem Motto: "Ich weiß noch nicht wie und welche Anforderungen wir umsetzen, aber legen erstmal los und machen den ersten Schritt und sehen dann weiter." Trifft dieses saloppe Motto den Kern? Mir stellt sich dabei vor allem die Frage wie solch ein Entwicklungsprojekt kostenmäßig kalkuliert wird? I.d.R. möchte der Kunde vorab eine Kosten/Nutzen-Rechnung aufstellen und den ROI betrachten.
Im online Marketing wird es zunehmend eingesetzt
Danke ;-)
Ist es nicht so oder so offensichtlich, dass bei der Arbeit nicht alles genau nach Plan läuft. Oder haben die alle früher einfach nach Plan gearbeitet, bevor das Wort Scrum erfunden wurde, auch wenn was schief gelaufen ist. Glaube ich nicht. Man braucht nicht immer irgendwelche englischen Wörter für Dinge verwenden, die sowieso schon immer da waren, Stakeholder,Scrum usw.
Uff, gehts vielleicht auch mit normalen Ausdrücken, insbesondere im Abschnitt Sprints und Artefakte fliegen einem ja nur Fachwörter um die Ohren. Wenn sie einen Begriff erklären wie z.B Backlog usw. und dann noch mit anderen Fachbegriffen hantieren, dann versteht man nix. Einfach mehr Deutsch wagen (und das sage ich als Ausländer).