Diskussion:Scrum/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Scrum/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Scrum/Archiv#Thema_1

Kritische Betrachtung

Ich stimme mit dem ersten Teil der kritischen Betrachtung nicht überein, und da keinerlei Quellen angegeben sind würde ich sie als Mißverständnis eines vorigen Autors verwerfen. Der Stil, sie stehen zu lassen dann aber zu kommentieren finde ich äußerst unschön. Gibt es Einwände dagegen, den ersten Abschnitt einfach herauszunehmen?

Abgesehen von den fehlenden Quellen sind die beiden Absätze auch widersprüchlich. Im ersten Absatz wird davon gesprochen, dass Scrum kein Vorgehensmodell ist, im zweiten Absatz spricht der Autor dann vom Vorgehensmodell Scrum. Ich würde einer Löschung des Abschnitts auch zustimmen. --MartinK1180 14:57, 14. Mai 2008 (CEST)

• -- Scrum ist laut Sutherland und Schwaber ein Framework und keine Vorgehensmodell

Unklar ist mir hier, wann die Software von der Testabteilung getestet wird. Erst wenn sie komplett fertig ist? Oder parallel zur Auslieferung beim Kunden? Oder vor der Auslieferung beim Kunden? Wird sie nicht vor der Auslieferung getestet, bedeutet das realistisch, dass Scrump nur für Neuentwicklungen und außerhalb des Produktivsystems eingesetzt werden kann. Wird sie vor der Auslieferung getestet, ergibt sich doch ein deutlicher zeitlicher Versatz. Zeit x = Kunde hat einen Wunsch; Zeit x + 15 Tage => nächster Sprint beginnt; Zeit x + 45 Tage => Software ist in der Testabteilung; Zeit x + 60 Tage => Kunde erhält ein Update mit der gewünschten Programmänderung.... das wird sich auf Dauer nicht durchhalten lassen, insbesondere bei kritischen Fehlern, die den Arbeitsablauf deutlich stören

• -- Es hat hat so genannte "Cross Functional Teams" Teammitglieder sind auch Tester es werden nach jedem Sprint "potential shipable Products" fertiggestellt dies enthält auch das Testen. Ggf. müssen die Inkremente klein genug sein um in einem Sprint komplett ausgeliefert zu werden. (nicht signierter Beitrag von Jpb24 (Diskussion | Beiträge) 01:24, 2. Apr. 2010 (CEST))

Wird scrum ausschließlich bei Neuentwicklungen eingesetzt?

• -- Nein, Scrum kann auch für bestehende Produkte eingesetzt werden. Da es sich um ein Vorgehensmodell handelt, ist es auf den Prozess der Produkterstellung fokussiert und nicht auf das Projekt. Bei der Umstellung auf Scrum bedarf es aber sicherlich eines Change Management. -- Oemmler (16:35, 2. Okt. 2009 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Aber welcher Größe des Kundenstamms übersteigen die Kosten der häufigen Updates den Produktivitätszuwachs?

Vorteile / Nachteil dieser Methode

Die 15 Minuten am Morgen erscheinen mir wesentlich zu kurz. Wenn man SCRUM ernst nimmt, müsste diese Zeit absolut ausreichen. In der Praxis wären vermutlich eher 45 Minuten sinnvoll, wenn sich Team-Leiter und 9 Leute (=die Maximalzahl einer Gruppe) treffen um über das Projekt zu sprechen. Dann hat man in dem Meeting 5 Minuten zum "Auftauen" und 10 x 4 Minuten um über den letzten Tag zu sprechen. --Patchworker 16:30, 14. Okt 2005 (CEST)

• -- es gibt keinen Team Leiter in Scrum und die 15 Minuten reichen vollkommen aus. Tausende von Scrum Teams machen das so. JPB24 (nicht signierter Beitrag von Jpb24 (Diskussion | Beiträge) 01:24, 2. Apr. 2010 (CEST))

Hi, SCRUM fordert diese 15 Minuten. Ich arbeite zur Zeit auch im SCRUM Modus, wir sind meist 10 Leute beim Scrum Meeting und schaffens in unter 20 Minuten. Ziel ist es schnell zu informieren nicht irgendwas auszudiskutieren. Auftauzeit brauchts nicht. Und 4 Minuten is viel zu viel. Oder wie lange brauchst du um zu sagen:

• Gestern habe ich Modul x angefangen, leider nicht fertigbekommen weil ich noch Troubleshooting machen musste.
• Heute mach ich das Modul x mit Dokumentation fertig und versuche den daily build zu optimieren.

--FabianLange 20:55, 13. Nov 2005 (CET)

Wichtig ist dabei, dass Diskussionen nach außen verlagert werden. Dann und nur dann ist die Zeit schaffbar. In der Praxis brauchen man 0,2...0,5 h. Außerhalb werden dann Details besprochen. Der Leiter schreibt immer noch einiges auf für "Scrum of Scrum", sofern es ein größeres Projekt ist, das in mehrere Teams modularisiert ist. --Hutschi 09:43, 11. Apr 2006 (CEST)

Hi, mit Auftauen meint er wahrscheinlich auch soziales Auftauen (sich auch privat erstmal wieder hallo zu sagen. Die Scrum-Methode gibt zwar keine Uhrzeit vor, aber empfiehlt genau deshalb die Zeit nach dem Mittagsessen (Soziales Aufwärmen abgeschlossen und die etwas träge Zeit des Verdauens wird sinnvoll genutzt) --Dobberph 20:23, 26. Feb. 2010 (CET)

Was ist ein Produkt-Backlog?

Der Artikel erwähnt dass ein Produkt-Backlog geführt wird? Was ist das genau? Eine Tätigkeitsliste mit Prioritäten? Haben sich deutsche Bezeichnungen eingebürgert? HJH 18:36, 9. Apr 2006 (CEST)

Ein Beispiel eines Product-Backlog http://www.mountaingoatsoftware.com/scrum/productbacklog.php ; es bleibt die Frage, welche deutsche Bezeichnung sich eingebürgert hat. HJH 21:34, 10. Apr 2006 (CEST)

• -- Product Backlog ist eine Liste der Anforderungen in Form von so genannten User Stories. es gibt keine deutsche Bezeichnung dafür. zumindest kenne ich keine. Product Backlog ist so als Ausdruck akzeptiert (JPB24) (nicht signierter Beitrag von Jpb24 (Diskussion | Beiträge) 01:24, 2. Apr. 2010 (CEST))

Ja, das Backlog kann entweder als Tätigkeitsliste verstanden werden (insbesondere beim Sprint-Backlog) oder als Feature-Liste (funktionale und nichtfunktionale Anforderungen) beim Produkt-Backlog. Bei diversen Scrum Meetings habe ich versucht mit anderen deutschsprachigen Teilnehmern einen griffigen deutschen Begriff zu finden, das mislang uns aber. AngeloSchneider 17:16, 24. Nov 2006 (CEST)

Was sind Interkationen?

Im Artikel steht: "Individuen und Interkationen gelten mehr als Prozesse und Tools"Kommt das auch vom Sport? Ich habe das Wort "Interkationen" noch nie gehört. Ist es eventuell aus der Chemie? (Kationen?) --Hutschi 09:41, 20. Apr 2006 (CEST)

Scherzkeks. Das ist offensichtlich ein Tippfehler und soll „Interaktion“ heißen. (Obwohl mir dieses seichte Gesülze etwas auf die Nerven geht, werde ich's mal korrigieren.) :-) --jpp ?! 10:54, 20. Apr 2006 (CEST)

UUUps. Mir vor die Stirn klopf. Da waren soviel fremde Ausdrücke, dass ich das nicht gesehen habe. --Hutschi 11:55, 20. Apr 2006 (CEST)

Welche Firmen oder sonstige Gruppen im deutschsprachigen Raum benutzen Scrum? Für welche Projekte?

Würde mich mal interessieren... Also, wer will kann sich hier in einer Liste eintragen:

-Crytek seit wann sie es benutzen weiß ich leider nicht genau, aber das dürfte schon mindestens seit Beginn der (kompletten) Entwicklung von Crysis sein.

-Games Academy, bietet seit Mitte 2008 Scrumkurse an

-InterComponentWare AG nutzt seit 2006 Scrum als Vorgehensmodell für alle Entwicklungsteams im Unternehmen (nicht signierter Beitrag von Oemmler (Diskussion | Beiträge) 16:35, 2. Okt. 2009 (CEST))

- Allianz (Vortrag über Projekt bei Allianz auf dem Scrum-Day [1])

- SAP (Vortag von SAP auf dem Scrum-Day [2])

- IBM (Vortag von IBM Labor auf dem Scrum-Day [3]

- Xing (Vortrag von Xing auf dem Scrum-Day [4]) (nicht signierter Beitrag von Jpb24 (Diskussion | Beiträge) 01:24, 2. Apr. 2010 (CEST))

- Ich kenne in Wien persönlich 4 international bekannte Firmen, die Scrum verwenden (habe dort mitgeholfen Scrum einzuführen), kann sie aber leider nicht nennen (NDA). Wenn ich eine Liste an Firmen haben möchte, die Scrum verwenden, würd ich einfach Boris Glogner anschreiben... --Sebastian.Dietrich 09:53, 2. Apr. 2010 (CEST)

Software-Architektur?

Wie wird im SCRUM Prozess eine Software-Architektur etabliert. Es mag ja sein, dass jeder am besten das macht, was er gerade machen kann. Aber die Form ist ja nicht unwichtig. Irgendwie muss die Software ja auch am Ende des Prozesses mal gewartet werden oder eventuell erweitert. Wenn man einfach so Code zusammenklatscht hat man keine Fort- sondern Rückschritt begangen. Wer also definiert beim Scrum die Architektur? --195.212.29.163 17:04, 17. Okt. 2008 (CEST)

Architektur entsteht durch laufende (Architektur-)Refactorings (form follows function). In der Praxis wird allerdings zu Beginn die grobe Architektur (von Architekten oder "Wissenden") vorgegeben. --Sebastian.Dietrich 08:39, 24. Mär. 2010 (CET)

Auch hier emfehle ich einen Blick auf den Scrum-Day Vortrag: Wie entsteht Architektur in Scrumprojekten [5] jpb24 (01:24, 2. Apr. 2010 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Schleichwerbung

Die offensichtliche Werbung zugunsten von Herrn Boris Gloger stößt mir in diesem Artikel unangenehm auf.

Erstens ist es formal völlig überflüssig, in jedem zweiten Absatz auf ein Buch hinzuweisen, dass im Literaturverzeichnis aufgeführt ist. Zweitens ist dieses Buch nicht nur generell eines von vielen, sondern ist insbesondere neben ebenso aktuellen Büchern von den eigentlichen Schöpfern der Scurm-Methodik zu sehen. Daher halte ich es für falsch und verwirrend, Herrn Glogers Buch in der Literaturangabe an erste Stelle zu sehen, anstatt der chronologischen Ordnung (nach Erscheinungsdatum) folgend ganz unten (bei den anderen Büchern von 2008).

Dieses Phänomen ist in Wikipedia sicherlich häufig zu finden, aber in diesem Artikel ist es mir zum ersten Mal so aufgefallen. Da ich mich beruflich seit einer Weile mit dem Thema Scrum auseinandersetze, ist mir die offensive Wertschöpfungspolitik der Scrum Alliance und überzeugter (bzw. intensiv mit der Überzeugung beschäftigter) Scrum-Apostel bekannt.

Ich hoffe, meinem Änderungsvorschlag wird stattgegeben. Und ich würde mir wünschen, dass die zuständigen Wikipedia-Peers bei zukünftigen Reviews - besonders zu Artikeln über Hypes wie z.B. Scrum - genaues Augenmerk auf solche gezielten (und nicht einmal besonders subtilen) Wahrnehmungsverzerrungen zu Werbezwecken richten würden. Sonst ist dieses Review-System nicht sehr nützlich.

Freundliche Grüße

habe deine Änderung bereits als gesichtet markiert, mehr geht nicht. Ich mag solche Schleichwerbung ebenfalls nicht, habe mich bisher aber hauptsächlich auf die teilweise noch ärgerlicheren Weblinks gestürzt. Ansonsten ist kontinuierliches Beobachten der Artikel wichtig. Trublu ?! 12:08, 26. Nov. 2008 (CET)

Schleichwerbung sehe ich eher in der sehr selektiven Auswahl der erwähnten Tools im Abschnitt "Software", wo z.B. Agilo von agile42 erwähnt wird. Das ist eher ein Nischenprodukt, andere Programme wie Version One, Scrum Works, Rally u.v.m. sind wesentlich verbreiteter und leistungsfähiger. Auch in den Weblinks taucht agile42 zweimal auf mit zwei englischsprachigen Inhalten. Stattdessen wurden aber die Links auf die ausführliche Scrum-Einführung und das Scrum-Glossar in deutsch bei scrum-master.de - wir sind in der deutschen Wikipedia - als angebliche "Werbelinks" entfernt. Dabei sind sie vollkommen werbefrei, weder Glossar noch Einführung wollen etwas verkaufen. Mit dem Argument, daß die Homepage, wo die Inhalte beheimatet sind, kommerziellen Charakter hat, müßte man den Verweis auf controlchaos.com auch löschen. Alexander Kriegisch 01:27, 18. Dez. 2009 (CET)

Sprint

Habe Heute versucht den Begriff Sprint heraus zu nehmen und in der nächsten Zeit mehr darüber zu schreiben. Der Ausgagspunkt dafür sollte der Text der hier im Abschnitt Sprint steht dienen. Ein (ich suche den schönsten Begriff der mir erstmal einfällt) übereifrige Admin hat es mit Bemerkung "Teilkopie von Scrum -->URV, eigenständige Relevanz nicht erkennbar" einfach gelöscht.

So. Teilkopie oder URV jetzt? Wieso eigenständige relevanz nicht erkennbar? Wer kann das beurteilen? Auf der englischen Wikipedia ist man weniger pragmatisch. Dort stört so ein (obwohl nicht so üpig) Artikel keinen.

Manche verstehen eben nicht, das es Leute gibt eben, die nicht auf einmal alles aufschreiben und zusammensuchen können und eben einfach mehr Zeit brauchen an einem Artikel. Und wenn es als Teilkopie einige Zeit steht - das ist nicht falsch! Man muss Zeit bekommen um an dem Artikel arbeiten zu können.

Denke, das die deutsche Wikipedia mittlerweile zu viele übereifrige (oder zu wenige gute) Admins hat, die jede Lust am Mitarbeit schon am Anfang erwürgen. Vielen Dank. --Kaster 13:40, 8. Okt. 2009 (CEST)

• -- Das mit dem übereifrig kann ich nur beipflichten. Ich habe über die beiden Scrum Organisationen und deren Zertifizierungen geschrieben. Ein Admin hat das kurzerhand als Werbung deklariert und gelöscht. TsTs--Kopfschüttel  :-(

Ich denke bald schreibe ich hier gar nichts mehr rein. Eigentlich Schade, dass Leute Dinge beurteilen von denen Sie nur teilweise etwas verstehen. JPB24 (nicht signierter Beitrag von Jpb24 (Diskussion | Beiträge) 01:24, 2. Apr. 2010 (CEST))

Hi Jpb24! Bezüglich der Entfernung der beiden Scrum Organisationen und deren Zertifizierungen. Ich habe diese Information entfernt. Ich bin weder ein Admin, noch unerfahren mit Scrum (ganz im Gegenteil). Wenn Du meine Zusammenfassung der Löschung liest & auch Wikipedia:Was Wikipedia nicht ist und Wikipedia:Neutraler Standpunkt, wirst Du vielleicht erkennen, dass diese gerechtfertigt war. --Sebastian.Dietrich 09:48, 2. Apr. 2010 (CEST)

Erster Abschnitt unklar

In jedem guten Wikipedia-Artikel erklärt der erste Abschnitt in aller Kürze (konzise), was das ist. Der jetzige Text erfüllt dieses Kriterium nicht. Er ist zwar kurz aber erklärt es nicht. Er ist unverständlich für einen Aussenstehenden.

Ich spreche hier konkret vom Satz "Scrum ist ein Vorgehensmodell mit Meetings, Artefakten, Rollen, Werten und Grundüberzeugungen, das beim Entwickeln von Produkten im Rahmen agiler Softwareentwicklung hilfreich ist.". Das trifft zu ziemlich auf alle Software-Entwicklungsmethoden zu. Bitte spezifischer. Das einzig neue resp. unbekannte in der Aufzählung "Meetings, Artefakten, Rollen, Werten und Grundüberzeugungen" ist das Wort "Artefakten", das eigentlich kein deutsches Wort ist und erst viel weiter unten erklärt wird.

Dann der Satz "Teammitglieder organisieren ihre Arbeit weitgehend selbst und wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -Methoden." Das ist nichtssagend und trifft - je nachdem wie eng man es sieht - auf ziemlich alle Software-Entwicklungsmethoden zu. Schliesslich stellt sich auch die Frage, was hier mit "Methoden" gemeint ist und damit verbunden: Ist Scrum eine Methode? (ich denke ja)

-- 80.254.182.95 08:04, 14. Feb. 2010 (CET)

Ich habe die Einleitung etwas aufgeräumt und von wenig aussagekräftigen Sätzen befreit. --Das Ed 12:13, 24. Apr. 2010 (CEST)

Zukunft von Scrum – Parallelisiertes Pipelining von Sprints

Ist das nicht Glaskugelei? Wenn dann sollte der Abschnitt stark gekürzt werden und auf Meinungen der Autoren der Zukunftsvision umformuliert werden. --Sebastian.Dietrich 08:40, 24. Mär. 2010 (CET)

Ich hab den Abschnitt jetzt drastisch reduziert und statt auf Glaskugelei auf die Techniken fokussiert. --Sebastian.Dietrich 01:38, 9. Mai 2010 (CEST)

Selected Backlog

Sinnhaftigkeit? "Das ... enthält alle Aufgaben, die notwendig sind, um das Ziel des Sprints zu erfüllen."

Wenn beide einander entsprechen, dann erhöht es nur die Komplexität und bietet Angriffsfläche für Fehler.

Quellenangabe(n) bitte wo dieses Artefakt erwähnt wird. Bei Schwaber jedenfalls nicht.

P.S. --88.117.127.46 18:30, 14. Jun. 2010 (CEST)

Ich vermute mal, du meinst dass Selected Backlog und Sprint Backlog einander entsprechen? Das Selected Backlog enthält alle Aufgaben, die nochtwendig sind um die Backlog Items zu implementieren, die sich im Sprint Backlog befinden. Erwähnt wir dieses Artefakt zum Beispiel bei Gloger. --78.42.26.164 09:34, 12. Aug. 2010 (CEST)

Einloggen vergessen ;) Ich war das --Das Ed 09:35, 12. Aug. 2010 (CEST)

Backlog

Bei den ganze Fachbegriffen hier fehlt mir vor allem mal eine Definition was eigentlich genau ein Backlog ist. Leider gibt das dafür ja auch keinen allgemeinen Wikipedia-Artikel. --Hcy 09:42, 17. Sep. 2010 (CEST)

Ein Backlog ist prinzipiell mal eine Liste. In Scrum gibt es mehrere Backlogs: Product-Backlog, Sprint-Backlog, Impediment-Backlog, ... - also Listen mit Dingen, die noch offen sind. Keine Task- oder ToDo-Listen (weil dort nicht unbedingt Tasks/ToDos draufstehen), keine vollständigen/unumstößlichen Listen (weil sie agil wachsen/schrumpfen/nicht völlig umgesetzt werden können). Ist eigentlich mit nichts aus dem klassischen Projektmanagement vergleichbar... --Sebastian.Dietrich ✉ 20:24, 19. Okt. 2010 (CEST)

Tendenziöser Artikel

Der gesamte Artikel ist tendenziös und reflektiert in keiner Weise, welche strukturellen Schwächen Scrum aufweist. Auch würde ich gern wissen, worin die "Hinzunahme streng wissenschaftlicher Vorgehensweisen" besteht. (nicht signierter Beitrag von 195.37.205.30 (Diskussion) 10:04, 19. Okt. 2010 (CEST))

Das mit den streng wissenschaftlichen Vorgehensweisen hab ich mal ausgebaut - kommt wenns dafür einen Beleg gibt gerne wieder rein. Ansonsten kann ich keine Tendenz erkennen - mMn ist der WP:NPOV gut gewahrt. Etwaige Strukturelle Schwächen von Scrum bitte mit Beleg in den Abschnitt "Kritische Betrachtung". --Sebastian.Dietrich ✉ 20:16, 19. Okt. 2010 (CEST)

Unterschied Review <-> Retrospektive

Gibt es da wirklich einen Unterschied? Bzw. wo liegt der? (nicht signierter Beitrag von 62.220.31.131 (Diskussion | Beiträge) 16:33, 17. Jan. 2007 (CET))

Das Review Meeting dient dazu, den Stakeholdern den aktuellen Stand zu beschreiben, es hat also das Produkt zum Gegenstand. Die Retrospektive dagegen hat den Scrum Prozess als Gegenstand und dient dazu, dem Team eine Möglichkeit zu geben, den Prozess anzupassen. Beides auf Basis von Ken Schwabers Buch "Agile Management with Scrum".--194.45.12.12 14:23, 6. Mai 2008 (CEST)

Ist das auch auf Großprojekte anwendbar?

Wenn ein Großprojekt in Kleine Teams von maximal 15 Leuten zerlegbar ist funktioniert das. Entsprechender Abschnitt fehlt aber noch im Artikel --FabianLange 20:57, 13. Nov 2005 (CET)

Ein Grossprojekt sollte als scrum of scrums abbildbar sein. (nicht signierter Beitrag von 87.166.227.140 (Diskussion | Beiträge) 22:58, 2. Dez. 2008 (CET))

Woher stammt die Bezeichnung 'Scrum'?

http://www.mountaingoatsoftware.com/pres/scrumpres.pdf erwähnt DeGrace and Stahl, Wicked Problems, Righeous Solutions, 1990 (nicht signierter Beitrag von HJH (Diskussion | Beiträge) 22:26, 10. Apr. 2006 (CEST))

Mehr Angaben unter http://www.controlchaos.com/download/Controlled-Chaos%20Software%20Development.pdf Seite 11 (nicht signierter Beitrag von HJH (Diskussion | Beiträge) 22:26, 10. Apr. 2006 (CEST))

Im Eintrag fr:Scrum wird darauf hingewiesen, dass die Bezeichnung aus dem Wortschatz der Rugby-Spieler stammt.

http://www.ifi.unizh.ch/req/courses/seminar_ws03/12_Boegli_Anforderungen_Ausarbeitung.pdf enthält noch weitere Angaben. HJH 22:45, 10. Apr 2006 (CEST)

Beschreibung des Product Owners

Ich bin mit der Beschreibung des Product-Owners nicht einverstanden, in meinen Augen ist er der Besitzer des Product Backlogs und übernimmt damit die Verantwortung für das Produkt. Was er mit der „Kapitalrendite“ zu tun haben soll ist mir schleierhaft. (nicht signierter Beitrag von 80.226.217.183 (Diskussion | Beiträge) 22:45, 4. Sep. 2006 (CEST))

Magic Numbers

Dieser Artikel enthält Magic Numbers, bspw. "15 Minuten". Das finde ich nicht richtig. Auch für die Scrum-Ablaufgrafik würde ich auf jeden Fall erwähnen, dass das nur exemplarische Werte sind. (nicht signierter Beitrag von 88.215.124.106 (Diskussion | Beiträge) 19:15, 17. Sep. 2009 (CEST))

Scrum Master

Die Beschreibung des Scrummasters hinkt in dem Punkt, dass er weder zum Management noch zum Team gehört. Es wird sogar auf der Beschreibung des ScrumMasters auf der Offiziellen Website der Scrumalliance darauf hingewiesen, dass dies eine praktikable Möglichkeit ist. (nicht signierter Beitrag von 212.64.228.99 (Diskussion | Beiträge) 14:35, 10. Dez. 2009 (CET))

Grundlegende Überarbeitung erforderlich

Einiges an diesem Artikel entspricht nicht den Tatsachen, bzw. den zugrunde liegenden Forschungsergebnissen und Definitionen. Nonaka und Takeuchi beschreiben kein Scrum - als Vorgehensmodell - sondern vergleichen die von ihnen beobachteten Veränderungen in einigen Unternehmen mit dem Teamspiel von Rugby. Auch die weiter unten beschrieben A, B, C Typen haben als solche nichts mit Scrum zu tun, sondern mit der Entwicklung überlappender Prozessphasen. Ich werde in den nächsten Wochen sukzessive versuchen, die entsprechenden Darstellungen zu korrigieren und den Artikel auf ein solides Fundament zu stellen.

Andreas Schliep (nicht signierter Beitrag von 88.71.196.162 (Diskussion) 23:00, 14. Mai 2010 (CEST))

Die Scrum-Lüge in einem Praxisbeispiel

Aus persönlicher Praxis kann ich nur berichten wie bei uns Scrum angewendet wird (bzw. was von Scrum noch übrig ist): Es gibt keine Product Owner mehr; auch vorher war der Einfluss der Product Owner zu gering. Review und Retrospektive waren einmal. Den Scrum-Mastern ist das ganze in den Kopf gestiegen und sie agieren großteils nicht im Sinne des Scrum-Teams und auch nicht im Sinne von Scrum sondern nehmen Möchtegern-Chef-Positionen ein (ohne Legitimation und ohne Kompetenz). Scrum-Planning findet praktisch nicht statt. Die Motivation aller Team-Mitglieder ist am Boden. Ein Product-Backlog existiert zwar, es gibt jedoch viele die darüber stehen. Aber das ganze wird noch immer als "Scrum" und als Erfolg verkauft. -- 178.191.76.235 00:52, 5. Nov. 2010 (CET)

Das was Du ansprichst ist die alte Frage "Wieviel X brauche ich, um mich X nennen zu dürfen" - konkret auf agile Prozesse angewandt: bin ich agil, wenn ich 1%, 5%, 99% eines agilen Prozesses umgesetzt habe. Die meisten Projekte, die ich kenne, die sich "Scum" nennen liegen irgendwo zwischen 20% und 60% - Dein Projekt scheint sich eher bei 20% oder weniger zu bewegen. mMn kann man das aber nicht dem Prozess per se anlasten. --Sebastian.Dietrich ✉ 10:24, 5. Nov. 2010 (CET)

Nur weil es beim Unternehmen X nicht so funktioniert wie vom Erfinder angedacht, bedeutet das nicht, dass es nicht funktioniert. Wir alle – die bereits Praxiserfahrung haben – wissen, dass es im realen Leben oft nicht so ablaufen kann wie in einem Modell. Es wird immer irgendwelche Manager, Kunden oder andere Großmäuler geben die sich zwar gerne mit irgendwelchen netten Schlagwörtern schmücken und im Hintergrund läuft alles anders. Für diesen Artikel ist dies jedoch unerheblich, da hier lediglich das Prozessmodell erläutert wird und nicht wie es im Unternehmen X oder Y in der Realität abläuft. LG, ひき肉器 ^公議 20:05, 6. Nov. 2010 (CET)

Nur um es klar zu stellen: Ich will nicht Scrum per se in Frage stellen (auch wenn es so rüberkommt), wollte aber ein konkretes Beispiel aus der Praxis bringen - eines, wie es nicht sein sollte. Es geht hier auch nicht um ein konkretes Projekt, sondern um viele kleine bis mittelgroße Projekte und um den laufenden Betrieb an sich. Vieles davon spielt sich im Legacy-Bereich ab, wo agile Methoden ohnedies noch schwieriger einzusetzen sind und gewisse Tools einfach nicht zur Verfügung stehen. Mit der Einführung von Scrum wurden auch die "alten" Verantwortlichkeiten großteils aufgehoben und auf irgendwelche (dynamische) Scrum-Teams aufgeteilt. Unsere Prozesse sind oft auch nicht das Papier wert, auf dem sie stehen. Und auch sonst passt hier vieles nicht. BTW @Sebastian: Wir hatten vor Jahren einmal kurz miteinander zu tun und es spielt sich in unserer Stadt ab. -- 188.22.20.1 20:55, 6. Nov. 2010 (CET)

ja kann schon sein - an jemanden Namens "188.22.20.1" kann ich mich aber nicht erinnern :-) --Sebastian.Dietrich ✉ 10:39, 19. Nov. 2010 (CET)

Länge von Aufgaben im Sprint Backlog

Es existiert in dem Artikel ein Widerspruch bzgl. der maximalen Länge einer Aufgabe.

• In Kapitel 3.2 Selected Backlog steht:
  

Eine Aufgabe sollte dabei nicht länger als 16 Stunden dauern.

Längere Aufgaben sollten in kurze Teilaufgaben zerlegt werden.

• In Kapitel 4.2 Sprint-Planungstreffen 2 steht:

Dazu werden die Selected-Backlog-Einträge in Aufgaben zerlegt,

die in weniger als einem Tag bearbeitet werden können.

Aus den Aufgaben und deren Verteilung entsteht das Sprint Backlog.

-- 12:48, 3. Dez. 2010 (CET) (ohne Benutzername signierter Beitrag von 82.198.197.57 (Diskussion) )

Habs entsprechend korrigiert --Sebastian.Dietrich ✉ 17:46, 3. Dez. 2010 (CET)

einführendes Satement zu Scrum

Hallo, also das einführende Statment zu Scrum gefällt mir ehrlich gesagt gar nicht.

-Scrum (deutsch: Gedränge) ist ein Vorgehensmodell der agilen Softwareentwicklung. Ken Schwaber, Jeff Sutherland und Mike Beedle haben Scrum entwickelt und etabliert. Als Software-Entwicklungsmethode wird Scrum das erste Mal in dem Buch Wicked Problems, Righteous Solutions (1991)[1] beschrieben. Scrum in Produktionsumgebungen wird zum ersten Mal in dem Artikel The New New Product Development Game[2] erläutert und später in The Knowledge Creating Company weiter ausgeführt von Ikujiro Nonaka und Hirotaka Takeuchi.-

Und zwar deshalb: 1.) es wird von einem Vorgehensmodell und von einer Softwareentwicklungsmethode gesprochen. -> das ist Scrum aber nicht! Scrum ist ein methodisches Framework das sich besonders gut eignet um Softwareprojekte durchzuführen.

2.) Scrum wird das erste Mal 1991 als "Softwareentwicklungsmethode erwähnt" -> Komisch Jeff Sutherland hat Scrum 1993 (mit dem Entwicklungs-Team das Enfin/Object Studio (ein Smalltalk IDE und Modelling Tool) erstellt hat) erst entwickelt. Wie kann es dan schon 1991 in einem Buch erscheinen?

Das stelle ich jetzt einfach mal zur Diskussion JP (nicht signierter Beitrag von Jpb24 (Diskussion | Beiträge) 10:14, 10. Dez. 2010 (CET))

@1) - ein methodisches Framework ist eine Art von Vorgehensmodell (auch wenn es weniger strikt ist).

@2) - ich kann mir gut vorstellen ein (theoretisches) Buch über X zu schreiben und X erst 2 Jahre später praktisch auszuprobieren und weiterzuentwickeln. Aber egal - in dem 1991 erschienenen Buch wird tatsächlich Scrum (neben Video/Hollywood, CleanRoom und Sashimi) vorgestellt. --Sebastian.Dietrich ✉ 13:09, 10. Dez. 2010 (CET)

Begriffserklärungen unzureichend

Scrum ist eine Welt, die sich durch viele neue Eigennamen (Backlog, Sprint, ...) eine eigene Begriffswelt geschaffen hat. Für einen Neuling ist das deshalb schwer einzusteigen. Diese Wikipedia-Seite erklärt Scrum mit seinen eigenen Begriffen ohne diese vorher alle eindeutig zu definieren/erklären. Bitte ändern. Danke. (nicht signierter Beitrag von 80.149.148.212 (Diskussion) 16:31, 13. Apr. 2011 (CEST))

Bitte zuerst gesamten Artikel lesen - sowohl Backlog als auch Sprint sind erklärt. --Sebastian.Dietrich ✉ 17:39, 13. Apr. 2011 (CEST)

Hallo Sebastian, ich teile den Verbesserungswunsch. Scrum verwendet bekannte Begriffe in einer völlig neuen Bedeutung, bzw. erfindet neue unbekannte Begriffe. Damit das für den WP-Leser verstehbar wird, müssen die Begriffe erklärt werden. Als erstes der Begriff "Scrum" ;-) . Die von Dir erwähnte Erklärung steht im Kapitel "Artefakte". Lies mal was unter Artefakt steht - vielleicht verstehst Du dann, wie unmöglich es für den Leser ist auch nur diesen Titel zu verstehen. Dieser Artikel wird ja nicht nur von IT-Studenten gelesen, sondern auch von (potentiellen) Kunden.

Was ist der "Produkt-Owner"? a) der Auftraggeber also der Kunde? oder b) der Projektleiter?

falls a): ist wirklich gedacht, dass der Kunde bei jedem Sprint-Revwiew mit dabei sitzt?

falls b): wo wann wie erfolgt die Kommunikation zwischen Kunde und Team?

Gruss, --Markus 09:42, 6. Jun. 2011 (CEST)

Ich stimme Markus zu. Die Neubelegung bekannter Begriffe macht es einigermaßen schwer, in das Thema hier einzusteigen (das Beispiel Artefakt wurde schon genannt). Eine Begriffserklärung ist, glaube ich, unabdingbar. Wir sind übrigens vermutlich aus diesem Grund im firmeninternen Gebrauch von den Begriffen teilweise abgewichen und benutzen altbekannte Begriffe (Iteration statt Sprint --obwohl ich als Rugby-Gucker gerade mit Sprint und Scrum (Gedränge) weniger Probleme gehabt hätte ;-)).--Zipor haNefesch 14:09, 5. Jul. 2011 (CEST)

Release Planning Meeting

Dieses optionale Meeting (im Scrum Guide von scrum.org) fehlt in diesem Artikel gänzlich. -- 141.6.11.18 09:22, 8. Jul. 2011 (CEST)

Scrum ist ein Framework und kein Prozess

Warum schreibt ihr hier immer wieder vom Scrum Prozess. Den gibt es defacto nicht. Es handelt sich um das "Scrum FrameWork"! Wenn ihr es nicht glaubt schaut mal im Scrum Guide nach http://www.scrum.org/scrumguides/ Gruß JP (nicht signierter Beitrag von Jpb24 (Diskussion | Beiträge) 00:11, 1. Aug. 2012 (CEST))

Scrum ist ein Vorgehensmodell. Im Englischen (!) wird Scrum manchmal als Framework bezeichnet, wobei damit nicht Framework gemeint ist (was dem en:Software framework entspricht), sondern Prozessframework (wie z.B. ITIL oder das Eclipse Process Framework). --Sebastian.Dietrich ✉ 08:02, 1. Aug. 2012 (CEST)

Stimmt so passt die Definintion einigermßen (aber lasst das Prozesszeug weg.) Scrum steckt den Rahmen ab aber gibt keinen Prozess vor. (eher so wie "wir einigen uns auf Spielregeln") gruß JP (nicht signierter Beitrag von 79.248.225.251 (Diskussion) 08:59, 1. Aug. 2012 (CEST))

Juristische Erwägungen

Verstehe nicht, was es zu erwägen gibt. Wer ein Projekt nach dem Scrum-Vorgehensmodel beauftragt, kann nur einen Dienstvertrag schließen, da er in die Kooperation/Begleitung des Entwicklungsteams mit einstimmt und direkt am Erfolg beteiligt ist und nie und nimmer allein die Arbeit der anderen abnehmen kann. --37.49.29.242 00:23, 19. Jan. 2013 (CET)

Dasselbe würde aber auch für den Bau eines Hauses gelten, bei dem man Eigenleistung einbringt. Nein, nur deswegen, weil etwas in Kooperation gemacht wird heisst das nicht, dass keine Fixpreisprojekte oder Werkverträge möglich sind. --Sebastian.Dietrich ✉ 19:34, 19. Jan. 2013 (CET)

Da es sich bei der Erstellung eines individuellen Produkts immer um einen Werkvertrag handelt (übrigens wie beim Hausbau), ist die Aussage, es könne sich nur um einen Dienstleistungsvertrag handeln falsch. Selbstverständlich kommen im Rahmen von Scrum auch andere Vertragsformen in Betracht, aber bezogen auf die Beschreibung des Artikels ist die darin enthaltene Aussage korrekt. Lediglich mit dem Bezug auf das Produkthaftungsgesetz habe ich meine Probleme, da Haftung sowie Sach- und Rechtsmängel eigentlich im BGB geregelt sind. --Morphelianus (10:21, 10. Sep. 2013 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Erfahrung dass die meisten modernen Entwicklungsprojekte zu komplex sind

Bez. auf:"Er beruht auf der Erfahrung, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um durchgängig planvoll umgesetzt zu werden und auf der Erkenntnis, dass allein ständig verfügbares Feedback den Erfolg sichert. Damit wird vermieden, die anfänglich gegebene Komplexität durch einen komplexeren Plan zu steigern."

Negiere ich vollständig! - Also ich habe jetzt 150 Projektleiter u.a. auch für Großprojekte ab 100 Mio aufwärts geschult und gecoacht. Weiterhin gehöre ich zu Europas führenden Experten im Requirements Engineering usw. Mein Konsens ist, dass agile Methoden nur deshalb eine Existenzberechtigung haben, weil die Mitarbeiter nicht ausreichend qualifiziert sind großen Projekte zu managen und NICHT weil die Projekte zu komplex sind. Also Vorschlag: "Erkenntnis" durch "Annahme" oder "Vermutung" ersetzen. (nicht signierter Beitrag von 194.8.216.50 (Diskussion) 16:14, 31. Okt. 2013 (CET))

Das ist deine persönliche Sicht der Dinge. Die persönliche Sicht der "Erfinder" von Scrum kamen nunmal zur Erkenntnis, dass dem so ist. Wenn du wo Belege dafür finden kannst, dass die Projekte gar nicht zu komplex sind, sondern nur die Hirne zu klein sind, dann gerne her damit. Solange du keine Belege dafür hast, haben deine Ansichten (und natürlich auch meine) in der Wikipedia nichts verloren. Darum habe ich auch deine entsprechenden Ergänzungen im Abschnitt "Die Grenzen und Nachteile von Scrum" wieder gelöscht [6]. Sie können natürlich gerne wieder rein, wenn du Belege beibringst. Einem der führenden Experten Europas im Requirements Engineering sollte das ja wohl nicht schwer fallen. --Sebastian.Dietrich ✉ 20:49, 31. Okt. 2013 (CET)

Könnte ich, aber DEINE Meinung ist für auch nicht relevant. (nicht signierter Beitrag von 79.193.217.226 (Diskussion) 17:17, 7. Nov. 2013 (CET))

Daily Scrums

Beim Daily Scrum Meeting trifft sich das gesamte Scrum Team und nicht nur das Entwickler-Team! http://scrum-master.de/Scrum-Meetings/Daily_Scrum_Meeting

-- 95.223.227.81 15:09, 9. Apr. 2012 (CEST)

Ich würde mich da lieber an den offiziellen Scrum Guide halten (von Ken Schwaber und Jeff Sutherland) anstatt mich an privaten Webseiten zu orientieren. -> beim Daily Scrum muss nur das Dev.Team dabei sein. Scrum Master optional (Wenn der auch Dev.Team Mitglied und SM in Personalunion ist, muss er dabei sein). Der PO (der ja auch zum Scrum Team gehört) muss nicht da sein. Guß JPB24 (nicht signierter Beitrag von Jpb24 (Diskussion | Beiträge) 00:11, 1. Aug. 2012 (CEST))

Der Scrum Guide geht sogar noch weiter: Nur das Entwicklerteam darf teilnehmen! Scrum Master und PO sind allenfalls Beobachter.--Philipp Sªsse (Diskussion) 06:54, 18. Jan. 2014 (CET)

Scrum Guide vs. Gloger

An vielen Stellen findet man in der Beschreibung ohne besonderen Hinweis spezielle Interpretationen von Scrum, z. B. durch Gloger, statt der Definition von Schwaber/Sutherland. Ich würde jeweils den Scrum Guide in der aktuellen Version zur Grundlage nehmen und davon abweichende oder darüber hinausgehende Regeln kenntlich machen. Ich füge demnächst mal Beispiele ein, falls keine Einwände kommen. --Philipp Sªsse (Diskussion) 10:08, 2. Jan. 2014 (CET)

Gute Idee --Sebastian.Dietrich ✉ 19:13, 2. Jan. 2014 (CET)

So ich habe mal einiges eingepflegt, in einzelne Änderungen, damit man es besser nachverfolgen und weiterbearbeiten kann.--Philipp Sªsse (Diskussion) 07:22, 18. Jan. 2014 (CET)

Zertifizierung unzureichend

Die SCRUM Zertifizierung des IUE ist die einzige, welche nicht kommerzieller Natur ist und welche wissenschaftlich durch das IUE fundiert wird. Hingegen sind dort fast rein privatwirtschaftliche Unternehmen aufgeführt, dessen Relevanz nicht wirklich überzeugend ist. Bitte also auf meine Ergänzung im Artikel "Scrum" unter dem Punkt Zertifizierung, welche wieder rückgängig gemacht wurde. (nicht signierter Beitrag von BusinessExpertZh (Diskussion | Beiträge) 17:13, 4. Jan. 2020 (CET))

Auf mich macht das Agilitätskonform Bildungszentrum den Eindruck einer kommerziellen Unternehmung, und der Abschnitt macht den Eindruck von Werbung für dieses Unternehmen. --Mussklprozz (Diskussion) 17:41, 4. Jan. 2020 (CET)

Das Agilitätskonform Bildungszentrum ist der zertifizierte Bildungspartner des IUE (aber ja, auch ein wirtschaftliches Unternehmen, wie jeder private Bildungsanbieter). Im Sinne glaubwürdiger Konsequenz, müsste man somit alle privatwirtschaftlichen Bildungsanbieter in diesem Artikel löschen. Auch Scrum.org, welcher der grosste Anbieter ist. (nicht signierter Beitrag von BusinessExpertZh (Diskussion | Beiträge) 17:52, 4. Jan. 2020 (CET))

"Borisgloger Consulting" (ebenso aufgelistet) ist demnach ebenso Werbung. Von der Relevanz allerdings absolut nichtig. (nicht signierter Beitrag von BusinessExpertZh (Diskussion | Beiträge) 17:56, 4. Jan. 2020 (CET))

Nur als Hinweis: Derartige Vergleiche sind (aktuell) wenig zielführend. Derzeit geht's um das Agilitätskonform Bildungszentrum bzw. das IUE in Zürich. Deren Relevanz kann nach den hier geltenden Regeln nicht durch Vergleiche/Analogien nachgewiesen werden... Grüße, --rolf_acker (Diskussion • Beiträge) 18:25, 4. Jan. 2020 (CET)

Es macht zwar den Eindruck einer Sockenpuppen-Racheaktion, trotzdem scheint mir die Löschung von "Borisgloger Consulting" gerechtfertigt. Ein Argument ist richtig oder falsch unabhängig von seinem Urheber, hin und wieder ist Aufräumen in solchen Aufzählungen sinnvoll. Ich habe die Löschung daher gesichtet. --Mussklprozz (Diskussion) 21:14, 7. Jan. 2020 (CET)

Ist die Aufführung einzelner Anbieter hier überhaupt enzyklopädisch relevant? Im Zweifel werden so einfach immer nur noch mehr versuchen, ihre speziellen Angebote hier darzustellen. Von mir aus genügt eine algemeiner Absatz ohne Aufzählung einzelner Anbieter. --Grindinger (Diskussion) 17:07, 18. Feb. 2020 (CET)

So wie derzeit mit einem eigenen Abschnitt je Anbieter völlig übertrieben. Warum einige relevant und andere nicht relevant wären erschließt sich mir nicht. Keiner der Anbieter ist vermutlich relevant im Sinne der WP:Relevanzkriterien. Ich wäre für einen allgemeinen Absatz aber inkl. Aufzählung der Anbieter (und inkl. Boris Gloger, der zumindest in Ö deutlich relevanter ist als viele der anderen). --Sebastian.Dietrich ✉ 20:47, 18. Feb. 2020 (CET)

Habs jetzt entsprechend geändert. Wenn ich es aber recht bedenke, dann bringt die Aufzählung der Anbieter keinen Mehrwert gegenüber einer simplen Google Suche, wo man deutlich mehr Treffer findet. Plädiere also dafür auch die Liste zu streichen. --Sebastian.Dietrich ✉ 21:05, 18. Feb. 2020 (CET)

+1, mach das, kein enzyklopädischer Mehrwert, immer subjektiv und bleibt immer ein Streitpunkt (s. o.), auch gemäss WP:WWNI Nr. 7.2 --Alpöhi (Diskussion) 08:38, 19. Feb. 2020 (CET)

Oh neein!

Der Artikel beginnt mit: "Scrum (aus englisch scrum für „Gedränge“) ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Es wurde ursprünglich in der Softwaretechnik entwickelt, ist aber davon unabhängig. Scrum wird inzwischen in vielen anderen Bereichen eingesetzt.[1] Es ist eine Umsetzung von Lean Development für das Projektmanagement.[2][3]" Genausogut könnte man schreiben: "Scrum ist Scrum". Nichtsagender geht es wohl kaum noch! Kauderwelsch von "Experten" für "Experten" - aber eben KEINE saubere Enzyklopädik! Was ist denn das (kurzgfefaßte!) Wesen(!) von Scrum gegenüber anderen Vorgehensweisen?! Der Artikel ist ja recht umfangreich, aber völlig nichtssagend! Reiner Blähstil! Wenn man ihn gelesen hat, ist man hinterher genauso "schlau" wir vorher. DAS kann nicht die Aufgabe von Enzyklopädik sein. Im Anfang des Artikels sollte also nur das Wesentliche(!) stehen: "Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung." OK. Da sollte aber "agilen Softwareentwicklung" schon als erklöärender Link gestaltet sein, denn auch dieser Begriff ist enzyklopädisch erklärungsbedürftig! Und dann sollten zunächst und sofort erstmal die wichtigsten Wesensmerkmale von Scrum genannt werden. Wer nicht weiß, worum es sich überhaupt dreht, wird sich auch nicht für weiterführende Details, wie die historische Entwicklung von scrum interessieren (die eigentlich erst ganz am Schluß des Artikels interessant sein könnte, wenn der Leser dann schon sachlich erstmal Bescheid weiß, worum es überhaupt geht! Aus dem Zusammenhang gerissene Historie ist immer uninteresseant - und genau das KANN nicht Anliegen einer Enzyklopädie sein, oder?) Didaktische Neuordnung des Artikels empfohlen: Harte Fakten und Wesentliches zuerst, das "Drumherum" später! (nicht signierter Beitrag von 109.41.129.128 (Diskussion) 14:56, 4. Jun. 2020 (CEST))

Da gebe ich dir teilweise Recht. "Scrum … ist ein Vorgehensmodell des Projekt- und Produktmanagements" ist schon mal nicht schlecht, es fehlt jedoch tatsächlich in der Einleitung die Information, was denn dieses Vorgehensmodell ausmacht bzw. worin es sich von anderen unterscheidet. --Alpöhi (Diskussion) 19:03, 4. Jun. 2020 (CEST)

hätte ich nicht schreiben sollen - entschuldigung - deshalb wieder gelöscht. (nicht signierter Beitrag von 2001:A61:111B:4201:1CB4:A530:96F2:7284 (Diskussion) 08:56, 27. Feb. 2021 (CET))

Bitte WP:NPOV und WP:Q beachten, das ist deine Privatmeinung. --Johannnes89 (Diskussion) 09:35, 27. Feb. 2021 (CET)

Was ist den hier passiert? (erl.)

Neuer Diskussions-Abschnitt "O neein!" plötzlich fälschlicherweise in "Einzelnachweise" gerutscht. Bitte um Korrektur! (nicht signierter Beitrag von 109.41.129.128 (Diskussion) 14:58, 4. Jun. 2020 (CEST))

Worum gehts? Du musst dich schon verständlicher äußern. --Schotterebene (Diskussion) 16:20, 4. Jun. 2020 (CEST)

ich habs geklärt und den Abschnitt "Einzelnachweise" gelöscht, sowas haben wir auf Diskussionsseiten garnicht. --Alpöhi (Diskussion) 19:03, 4. Jun. 2020 (CEST)

Die Wikipage zu "Scrum" ist zum Teil ein getarnter Werbetext für Scrum-Zertifizierer

Der jetzige "Artikel" zu Scrum ist in teilen ein Werbetext von kostenpflichtigen Zertifizierern. Ich werde nicht wissenschaftlich widerlegen können, dass "swiffern" besser ist als "staubwischen". Ähnlich werde ich nicht widerlegen können, dass ein "Scrum-Master" mehr ist als ein Team-Chef. Es sollte trotzdem nicht auf Wikipedia behauptet werden.

Scrum ist etwas geschickter als Swiffer, das muss man eingestehen. Aber ähnlich wie beim "swiffern" womöglich alles so dreckig bleibt wie es war: Es gibt zu Scrum nicht nur "keine Erfolgsgarantie", es gibt keine Belege dafür das Scrum irgendetwas verbessert. Im Text wird nun aber konstant, subtil und der Eindruck erweckt, Scrum wäre etwas ganz spezielles, neues, durchdachtes, besonderes und könnte Entwicklung beschleunigen. Bereits die Behauptung das Scrum irgendetwas "könnte" ist aber eine fragwürdige Behauptung, denn sie ist ohne jeden Beleg. Viele Dinge die es angeblich bewirken soll werden hier als Tatsachen dargestellt.

Ich versuche hier mal ein Paar Beispiele aus dem schiefen Abschnitt "Grenzen und Nachteile von Scrum" zu erklären. Ein solcher Abschnitt sollte mindestens erwähnen, das die Wirksamkeit von "Scrum" unbelegt ist. Das wäre nämlich ein Nachteil. Stattdessen ist der Text eine verkappte Lobhudelei, die etwas Banales und Selbstverständliches wie "keine Erfolgsgarantie" als kritische Betrachtung verkauft. "Keine Erfolgsgarantie" impliziert es gäbe belegte Erfolge durch Scrum. Das ist nicht der Fall. Hier eine Satz für Satz Analyse eines manipulativen Textes der sich so auf der Seite findet:

Überschrift: "Verwertung gewonnener Erkenntnisse"

Liefert Scrum denn tatsächlich Erkenntnisse? Das ist unbelegt.

"Bei der Verwendung von Scrum muss man sich darauf einstellen, dass die ursprünglichen Einschätzungen permanent über- oder untertroffen werden."

Ist das so? Wer sagt das? Muss man sich darauf nicht bei jeder Planung einstellen? (besonders wenn sie schlecht ist)

Scrum zeigt vom ersten Tag an Abweichungen vom Soll-Zustand an.

Wie jede Planung? Sogar wenn man Nichts-Tun plant weicht man bevor man nichts-tut vom Soll-Zustand ab.

Ob Scrum dazu führt, dass Produkte schnell, gut, günstig oder qualitativ hochwertig entwickelt werden, hängt davon ab, wie das Scrum-Team die gewonnenen Erkenntnisse anwendet. Nach Schwaber kann auch ein „Team von Idioten“ nach Scrum arbeiten.[83]

Hier überschlägt sich der Werbesprech: Woher weiß ich eigentlich dass Scrum bei irgendeinem Team dazu führt, dass Produkte "schnell, gut, günstig oder qualitativ hochwertig" entwickelt werden? Vielleicht führt ja Scrum dazu das Produkte "schlecht, dumm und gar nicht" entwickelt werden, egal wie blöd das Team ist? Ich weiß es nicht, denn es gibt für nichts davon Belege.

Und warum steht da eigentlich gleich "schnell, gut und günstig" statt einfach nur "effektiv"? Die Antwort sollte ab hier klar sein:

Weil das hier WERBUNG ist. Es ist unbelegt das Scrum überhaupt irgendeinen Vorteil bietet. Folgend ist es voreingenommen soetwas anzudeuten indem man Wörter wie "schnell, gut, günstig oder qualitativ hochwertig" benutzt.

Nach Schwaber kann auch ein „Team von Idioten“ nach Scrum arbeiten.[83] Das Team liefert am Ende jedes Sprints zuverlässig Produktinkremente, hält alle Meetings ab, und verteilt die Rollen nach Scrum. Wenn aber das Scrum-Team die Ergebnisse nicht nutzt, um anders zu arbeiten und Anpassungen vorzunehmen, wird auch das Produkt nicht besser oder früher fertig sein.

Da steht also ein Zitat von jemandem der an Scrum Geld verdient. Der Scrum-Verkäufer sagt uns: Wenn Scrum ausnahmsweise mal nicht funktioniert, dann liegt das an einem „Team von Idioten“ und bestimmt nicht an Scrum. Schwaber verkauft Scrum Zertifikate. Er ist keine brauchbare Quelle im Abschnitt "Grenzen und Nachteile von Scrum". Wieder wird implizit und unhinterfragt behauptet Scrum führe dazu, dass Produkte "besser oder früher fertigwerden".

Dies ist ein geschickter, manipulativer Werbetext. Er gehört nicht auf wikipedia.

Wikipedia ist keine Werbeplattform für Zertifizierer und nicht-anerkannte Ausbildungen.

"Scrum", "Sprint", "Epic" all diese Begriffe sind eindeutig der Sprachmanipulation zuzuordnen. Sie sind darauf ausgerichtet den Eindruck von Geschwindigkeit und Qualität zu erzeugen. Es wird darüber hinweggetäuscht, dass Vieles aus dem SCRUM Spezial-Vokabular Selbstverständlichkeiten sind. "Daily Scrum" ist ein Ersatzbegriff für "tägliches Meeting". Man kann vermuten, er wird benutzt weil "tägliches Meeting" kritischer gesehen werden würde. Scrum liefert primär neue Worte für alte Prozesse. Es wird als Lösung verkauft für altbekannte Probleme. Oft gäbe es etablierte und wissenschaftlich erforschte Lösungsstrategien. Wer nach der Lösung eines "Daily Scrum"-Problems sucht, forscht nicht unbedingt akkurat nach welche Effekte tägliche 15-Minuten-Meetings wirklich haben.

Ohne Kritik an der offensichtlich manipulativen Sprache ist die Wikipage zu Scrum ganz sicher nicht neutral. Belege dafür sind auf Grund der Offensichtlichkeit nicht nötig. Ich werde auch nicht wissenschaftlich widerlegen können, das "swiffern" mehr ist als "putzen". Es sollte offensichtlich sein. Zudem liefert die Webpage zu Sprachmanipulation auf Wikipedia selbst bereits genug Belege.

Die wikipage zu Scrum ist nicht neutral. Auch ein deskriptiver Werbetext ist ein Werbetext. Nur darum geht es mir. Ich kann und will nicht beurteilen wie gut oder schlecht "Scrum" ist. Dennoch sei angemerkt: Ein kryptisches Spezial-Vokabular, das bekannte, deskriptive Begriffe willkürlich austauscht, dient normalerweise nicht dazu Prozesse zu beschleunigen. Es dient zum Verwirren und zur Ab- und Auszugrenzen. Es gibt keinen nicht-manipulativen Grund einen Wochenplan "Sprint" zu nennen.(nicht signierter Beitrag von 2001:A61:111B:4201:1CB4:A530:96F2:7284 (Diskussion) 06:09, 27. Feb. 2021 (CET))

Ich ignoriere mal deine Unsachlichkeiten, erinnere daran, dass sowohl der Artikelinhalt, als auch jede Änderung Wikipedia:Belege und Wikipedia:Neutraler Standpunkt entsprechen müssen und versuche mal was zur inhaltlichen Kritik zu schreiben:

• Deine Behauptungen zu „Sprachmanipulation“ etc. sind deine Privatmeinung und können nur in den Artikel, wenn dies in Fachliteratur zu Scrum so steht. Es wird definitiv auch kritische Fachliteratur geben, die du nutzen kannst, falls du nicht nur hier deine Privatmeinung äußern möchtest.
• Scrum-Zertifikate werden durch einen Artikel, der einen Arbeitsprozess beschreibt, den man völlig ohne Zertifikat nutzen kann, sicher nicht verkauft. Ich frage mich allerdings tatsächlich, ob der Abschnitt Scrum#Zertifizierung enzyklopädisch relevant ist oder ob der gelöscht werden kann.
• Deine Feststellung, dass die Wirksamkeit von Scrum unbelegt ist, steht jetzt im Artikel [7], das muss aber nicht hinter jedem Satz nochmal stehen.
• Die Abweichungen (Über- und Untertreffen von Zielen) sind bei Scrum doch tatsächlich größer als z.B. im Wasserfallmodell, das auf ein sehr präzise definiertes Ziel zusteuert?
• Das „schnell, gut, günstig oder qualitativ hochwertig entwickelt ...“ habe ich neutraler formuliert: „Wie gut die Produktentwicklung funktioniert, hängt nach Angaben der Entwickler von Scrum davon ab ...“ [8]

Es wäre schön, wenn du weitere Kritik anhand von konkreter Literatur vorbringst oder aber (wie immerhin teilweise geschehen) konkrete Textstellen benennst, die deiner Meinung nach nicht neutral sind und dann konkrete Alternativvorschläge machst, sodass man darüber diskutieren kann. --Johannnes89 (Diskussion) 09:35, 27. Feb. 2021 (CET)

"Wochenplan" oder "weekly schedule" in "Sprint" umzubenennen ist Sprachmanipulation. Das ist nicht meine private Meinung. [9] [10] Sprachmanipulation klingt erst mal reißerisch, es ist aber nicht zwangsläufig etwas furchtbares. Diese Art der Manipulation ist z.B. in Werbung alltäglich. Ich würde mal behaupten Begriff "Sprint" auch deshalb gewählt wurde, weil er ein gewisses Tempo andeutet.

Belege? Meine Kritik ist, dass ein Teil des veröffentlichten Textes auf der Scrum wikipage keine Belege hat und schillernde Aussagen macht. Das ist auch dir aufgefallen: "Die Abweichungen (Über- und Untertreffen von Zielen) sind bei Scrum doch tatsächlich größer als z.B. im Wasserfallmodell, das auf ein sehr präzise definiertes Ziel zusteuert?" Ist das so? Ich weiß nicht wie man das Vergleichen will, geschweige denn Belegen. Trotzdem steht diese Aussage da, als sei es eine Tatsache. Das "Wasserfallmodell" kenne ich nicht genau, ich weiß nicht wo darauf Bezug genommen wurde.

Unsachlich? Zitat aus dem Artikel: "Ob Scrum dazu führt, dass Produkte schnell, gut, günstig oder qualitativ hochwertig entwickelt werden, hängt davon ab, wie das Scrum-Team die gewonnenen Erkenntnisse anwendet. Nach Schwaber kann auch ein „Team von Idioten“ nach Scrum arbeiten". Das nicht neutral und es ist nicht sachlich. Der Satz müsste lauten: "Ob Scrum dazu führt, dass Produkte schnell, gut, günstig oder qualitativ hochwertig entwickelt werden, ist nicht belegt. Bei Problemen sehen die Entwickler von Scrum die Schuld beim Team. Sollte Scrum nicht die gewünschten Ergebnisse liefern, dann liegt das nach Schwaber an einem "Team von Idioten" und nicht am Konzept von Scrum."

"Scrum-Zertifikate werden durch einen Artikel, der einen Arbeitsprozess beschreibt, den man völlig ohne Zertifikat nutzen kann, sicher nicht verkauft. Ich frage mich allerdings tatsächlich, ob der Abschnitt Scrum#Zertifizierung enzyklopädisch relevant ist oder ob der gelöscht werden kann." Ich habe nichts dagegen das Scrum-Zertifikate verkauft werden. Trotzdem: Der Text trägt sogar mit Sicherheit dazu bei, dass Scrum-Zertifikate verkauft werden. Wikipedia ist eine der zentralsten Anlaufstellen überhaupt. Jemand der mehr über Scrum wissen will und sich neutrale Information erhofft landet hier. Bei einer Zertifizierung geht es ja nicht darum, dass man etwas neu lernt, sondern um eine Art Beleg, dass man es kann. Manche würden ohne Wikipedia wahrscheinlich nicht erfahren das es diese Zertifizierungen gibt. (nicht signierter Beitrag von 2001:A61:111B:4201:1CB4:A530:96F2:7284 (Diskussion) 11:16, 27. Feb. 2021 (CET))

Ich denke diese ausufernde Diskussion hier bringt nichts. Bitte bringe deine Punkte einzeln, kurz und präzise - oder baue sie mit geeigneten Belegen gleich in den Artikel ein. Ich habe mal versucht deinen letzten Beitrag hier zusammenzufassen:

• "Wochenplan" oder "weekly schedule" in "Sprint" umzubenennen ist Sprachmanipulation. - Nein sicher nicht - das Ding heißt im Englischen "sprint" - siehe https://www.scrumguides.org/scrum-guide.html. Oder meinst du das Ding war bereits im Englischen eine Sprachmanipulation? Dann lies dir die Geschichte von Scrum durch - dann wirst stehen, woher das Wort Sprint wohl stammt (nämlich vom Rugby).
• Ein Satz im Artikel ist nicht neutral und nicht sachlich - du schlägst eine Umformulierung vor. - die Umformulierung ist aber genauso nicht neutral und nicht sachlich. Das was du Schwaber bzw. den Entwicklern von Scrum (wen meinst du damit?) in den Mund legst ist so nicht richtig. Darüberhinaus denke ich dass bestimmte Studien sehr wohl belegen, dass Scrum dazu führt, dass "Produkte schnell, gut, günstig oder qualitativ hochwertig entwickelt" werden - vergleiche dazu die diversen Chaos Reports. Die Wirksamkeit oder Unwirksamkeit von Scrum gehört aber (wie Johannnes89 schon gesagt hat) an einem einzigen Punkt im Artikel erwähnt und nicht verstreut. Siehe Scrum#Grenzen_und_Nachteile_von_Scrum. So ein Abschnitt fehlt bei anderen Vorgehensmodellen, Methodiken, Tools, etc...
• Du bekrittelst (?) dass man über die Wikipedia erfährt, dass es Scrum Zertifikate gibt. - Klar, und das ist auch die Aufgabe der Wikipedia. Es werden/wurden belegterweise eine relevante Anzahl an Personen zertifiziert, warum sollen die diesbezüglichen Zertifikate nicht relevant sein. Schau dir mal Liste von IT-Zertifikaten an. --Sebastian.Dietrich  ✉  13:51, 28. Feb. 2021 (CET)

Es gelingt mir nicht immer, ich weiß - aber ich bemühe mich ehrlich um Sachlichkeit und kann mich nur entschuldigen für die Stellen an denen es nicht hin haut. Trotzdem: Eine euphemistische, suggestive Wortwahl bleibt auch dann schief wenn sie nicht intendiert. Sport- und Rugby-Vokabular für die IT-Prozessplanung bei Schreibttisch-Jobs zu nehmen, das ist Sprachmanipulation. Ich bewerte das nicht - es ist einfach so. Mir sind sowohl Scrum als auch seine Erfinder oder Zertifizierer egal. Ich versuche auf die Sachebene zu kommen. Da angekommen: "Weekly schedule" in "Sprint" umzubenennen ist Sprachmanipulation. Auch im Englischen. Ein beschreibender Begriff wird unnötig durch einen dynamisch klingenden, Suggestiven ersetzt. In meiner ursprünglichen Kritik hatte ich sowohl "weekly schedule" als auch "Wochenplan" geschrieben. Es ist dabei sachlich (und auch mir persönlich) egal, was die Erfinder von Scrum wollten. Genauso ist es egal wie Begriff historisch zustande kam. Stell dir vor dein Footballtrainer sagt: "Nenn mich ab heute bitte "Scientist" und dein Training heißt jetzt "weekly bachelor thesis"". Es ist egal warum er das will. Es ist eindeutig schief und suggeriert Dinge, die nicht da sind. Programmieren ist kein Rugby. Es könnte sich lohnen, darüber nachzudenken welchen Effekt diese Sprache wirklich hat hat und warum sie so gewählt wurde.(nicht signierter Beitrag von 2001:a61:111b:4201:cb8:7a3e:2626:ff03 (Diskussion) 02:57, 2. Mär. 2021 (CET))

Warum denkst du dass "weekly schedule" in "sprint" umbenannt worden wäre. Was auch immer "weekly schedule" oder "Wochenplan" sein soll - es ist kein Begriff aus der Softwareentwicklung und sicher nicht mit Sprint gleichzusetzen. In Scrum wurde niemals "weekly schedule" gesagt und dann in "Sprint" umbenannt. Das Ding hieß von Anfang an Sprint und dauert in der Regel 2 oder 3 Wochen.

Der Begriff "Sprint" passt auch viel besser dazu als "weekly schedule", auch wenn ein Sprint immer eine Woche dauern sollte. Ein Sprint ist (im Rugby) ein kurzer Spielzug (gefolgt von vielen weiteren derartigen Spielzügen), für den alle Spieler an einem Strang ziehen, der ein Ziel hat, keine Unterbrechungen erlaubt, und entweder erfolgreich oder erfolglos durchgezogen wird. Dasselbe gilt auch für Scrum, da gehts genauso um immer Wiederkehrendes, das Committment, die Zusammenarbeit aller, das Ziel, das Verbot von Unterbrechungen und den Erfolg. Einen besseren Begriff als Sprint (Rugby) gibt es dafür mMn nicht. --Sebastian.Dietrich  ✉  14:02, 2. Mär. 2021 (CET)

@2001:a61:111b:4201:cb8:7a3e:2626:ff03: Ob Sprachmanipulation vorliegt oder nicht, entscheiden nicht wir. Das schreiben wir in den Artikel, wenn das so in Fachliteratur über Scrum steht. Vgl. dazu WP:NPOV und WP:Q.

Der Vergleich mit dem Footballtrainer hinkt übrigens: Scrum nennt bestehende Begriffe nicht um, sondern verwendet ganz normale englische Begriffe, die dann bei der Einführung im Deutschen Sprachraum schlichtweg nie ins Deutsche übersetzt wurden. Das ist keine Sprachmanipulation, sondern einfach Bequemlichkeit. Aber darüber muss gar nicht diskutiert werden, weil weder deine noch meine Beurteilung zählt, sondern die von Sekundärquellen. --Johannnes89 (Diskussion) 15:24, 2. Mär. 2021 (CET)

• Rugby Begriffe zu verwenden um ein bestimmtes "Mindset" zu suggerieren, genau DAS ist Sprachmanipulation. Nochmal: Das ist nicht zwangsläufig etwas Böses oder Schlechtes. Der Begriff "sprint" passt offensichtlich nicht, denn er beschreibt Sport und eben keinen wochenlangen Arbeitsplan in der Softwareentwicklung. Auch im Englischen gäbe es natürlich deskriptive Begriffe aus Arbeit, Management und Softwareentwicklung. ('schedule', 'plan', etc) Scrum nutzt stattdessen Begriffe eines Sports. Ganz bewusst, wie du ja selbst schreibst, mit der Intention ein Mindset aus Rugby in Bürojob-Angestellten-Arbeitsverhältnisse zu übertragen. Das nennt man halt nun mal Sprachmanipulation. Softwareentwicklung ist nicht Rugby oder sonst ein Freizeitsport. Die parallelen halten sich wirklich in Grenzen.
• Zitat: "Der Begriff "Sprint" passt auch viel besser dazu als "weekly schedule", auch wenn ein Sprint immer eine Woche dauern sollte. Ein Sprint ist (im Rugby) ein kurzer Spielzug (gefolgt von vielen weiteren derartigen Spielzügen), für den alle Spieler an einem Strang ziehen, der ein Ziel hat, keine Unterbrechungen erlaubt, und entweder erfolgreich oder erfolglos durchgezogen wird. Dasselbe gilt auch für Scrum, da gehts genauso um immer Wiederkehrendes, das Committment, die Zusammenarbeit aller, das Ziel, das Verbot von Unterbrechungen und den Erfolg. Einen besseren Begriff als Sprint (Rugby) gibt es dafür mMn nicht." Hier wird wieder so getan, als sei der aus intendierte Wunschzustand eine Beschreibung des Vorgangs. Das ist nicht so. Statt "Ein Sprint sollte sein..." steht da "Ein Sprint ist..." und dann folgen subjektive Begriffe wie "Commitment" und "Zusammenarbeit". Selbst für Rugby wäre das blumig. Das ist es auch was mich im Artikel immer wieder so stört, denn es ist manipulativ. Generell kann man sagen, genau wie du es hier selbst beschreibst: Der schiefe Begriff "Sprint" suggeriert subjektive Werte und Vorstellungen aus dem Mannschaftsport in einen Schreibtischjob-Arbeitsplan hinein.
• Da man anscheinend glaubt ich schüttle mir aus dem Ärmel das mit diesem Artikel etas nicht stimmt, verweise ich jetzt einfach mal kurz auf die Englische Wikipedia Seite zu Scrum, in der ein "This article has multiple issues" aus guten Gründen oben dran steht.
• Man braucht nicht zu Antworten, wenn man das was geschrieben wurde nicht richtig ließt. Zitat: "Warum denkst du dass "weekly schedule" in "sprint" umbenannt worden wäre. " Wie bereits mehrfach erklärt: Das denke ich nicht.
• Hier mal ein bißchen eigene Meinung: Rugby ist eine der forderndsten und gefährlichsten Mannschaftssportarten. Eine Karriere in Rugby dauert typischerweise 10 Jahre. Danach sind sie fast immer gesundheitlich geschädigt. Ein Schelm wer glaubt Scrum könnte Selbstausbeutung fördern.(nicht signierter Beitrag von 2001:a61:111b:4201:a9c1:9f40:9aa6:26df (Diskussion) 11:12, 3. Mär. 2021 (CET))

Ich denke, dass damit alles gesagt ist. Du schienst keinerlei Quelle zu haben, die Scrum der „Sprachmanipulation“ bezeichnet, WP:NPOV und WP:Q wurden dir aber bereits verlinkt. Selbst wenn du recht hättest, kann das ohne Quelle nicht in den Artikel. Damit ist die Diskussion für mich erledigt. --Johannnes89 (Diskussion) 15:50, 4. Mär. 2021 (CET)

Change-Manager

Hallo, ich kenne mich mit dem Thema nicht aus, aber was mir aufgefallen ist: Der Begriff "Change-Manager" (zu der der SCRUM-Master "werden kann"), wird nur einmal erwähnt und dabei nicht erklärt. Der Informationsgehalt ist damit null. Der Satz "Der SCRUM-Master wird zum "DINGDONG-Manager" würde damit im isolierten Artikel gleich viel Sinn ergeben. Ich bin mir nicht sicher, ob es in diesem Zusammenhang einem "Veränderungs-Manager" entspricht und eine Weiterleitung zu "Veränderungsmanagement" sinnvoll ist. Auf jeden Fall muss der Begriff erklärt oder verlinkt werden. Kann eine Person, die sich damit auskennt bitte machen? Danke :)--94.221.111.175 19:05, 11. Jan. 2018 (CET)

Ich habe einen passenden Wikilink eingefügt.--Hfst (Diskussion) 10:04, 8. Apr. 2022 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Hfst (Diskussion) 10:04, 8. Apr. 2022 (CEST)

SCRUM als Managementmethode für alles? ein Irrweg!

Meiner Meinung nach wird SCRUM heutzutage viel zu oft für Erzeugnisse verwendet, für die das Management mangels Domänenwissen überhaupt nicht geprüft hat, ob es überhaupt für SCRUM/agile Entwicklung geeignet ist. Jeder will agil sein, damit er es auf dem Lebenslauf hat. Leider wird SCRUM dadurch zunehmend für Erzeugnisse genutzt, deren iterative Entwicklung wirtschaftlich völlig absurd ist oder die eh nur einmalig erstellt werden können. Oder SCRUM wird für die Linie, den Betrieb oder Servicemanagement genutzt, die gar kein Erzeugnis produzieren: "wir machen diesen Sicherheitspatch nach dem Sprint 14". Würde man eine Herz-OP nach SCRUM machen? Der Artikel in der Wikipedia zementiert leider diese krude Zukunft, indem es SCRUM als "Projekt"managementmethode für jedes Erzeugnis und jede Managementaufgabe propagiert (aufgrund wirtschaftliche Gründe der SCRUM Alliance?), und gleichzeitig auf den Artikel in der Wikipedia verweist, der ein "Projekt" viel strenger definiert. Aus meiner Sicht müsste der Artikel demnach überarbeitet werden, da es zu viele Widersprüche gibt. Es sollte viel präziser auf die Definitionen der verwendeten Begriffe geachtet werden, als einfach nur der in der Industrie etablierte Mischmasch wiederholt werden. (nicht signierter Beitrag von 217.110.196.152 (Diskussion) 10:19, 13. Jul. 2022 (CEST))

Deine Meinung in Ehren, aber wenn du eine Kritik an Scrum (nicht S.C.R.U.M.) bzw. dessen Verwendung hast, dann bist du hier falsch. Wenn du den Artikel kritisierst, dann bitte konkreter:

• wo im Artikel wird "SCRUM als "Projekt"managementmethode für jedes Erzeugnis und jede Managementaufgabe propagiert"?
• wo im Artikel gibt es Widersprüche?
• wo wird nicht "präzise auf die Definitionen der verwendeten Begriffe geachtet"? wo wird "der in der Industrie etablierte Mischmasch wiederholt"?

--Sebastian.Dietrich  ✉  21:30, 13. Jul. 2022 (CEST)

Ich bin auch der Meinung man sollte mehr kritische Aussagen im Artikel unterbringen. Als Wikipedia ist man der Neutralität verpflichtet was bedeutet Probleme müssen klar benannt werden, sondern könnten wir Leser in die Irre führen.Scrum ist nicht einmal für alle Software Projekte geeignet. Beispiel: Nicht alle Aufgaben lassen sich auf einen Tag herunterbrechen. Das muss im Artikel klar dargestellt werden. Ich habe mal ein bisschen kritik am Pokerspiel untergebracht. Eigentlich ist da viel mehr dazu zu schreiben. Komplexe Sachverhalte mit Hilfe eines Pokerspiels einzuordnen in wenigen Minuten ist doch Humbug. Aber Manager lesen sowas gern. Viele Entscheidungen is kürzester Zeit zu treffen, oder besser entscheiden zu lassen. Ein Wikipedia Artiekl verpflichtet, wenn es um Themen wie Managementmethoden geht. ไม่เป็นไร (Valanagut) (Diskussion) 09:41, 5. Okt. 2022 (CEST)

Deine Änderungen sind viel unbelegte Allgemeinaussagen, die so nicht stimmen. Weder verdienen System Architekten zwangsläufig mehr als Seniorentwickler oder Juniors weniger als Seniors. Es geht bei Scrum (wie auch bei anderen Prozessen) nicht darum, dass der Mehrverdiendende das Sagen hat. Der Rang/Rolle/... einer Person ist irrelevant in einem Cross-Functional Team, darum funktionieren sie auch erwiesenermaßen besser. Konflikte gibt es da selten. Warum sollte ein Junior keine Entscheidungen treffen (das macht jeder Junior 100te Male am Tag). Scrum fociert sogar, dass die Entwickler mit den Usern sprechen (und nicht nur der PO).

Ich vermute, dass dein Geschrubel nicht durch das Buch belegbar ist, da Boris Glogner sich mit Scrum auskennt. Aber du kannst gerne zu deiner Ref ein Zitat aus dem Buch hinzufügen, dass das deiner Meinung nach belegt. Wenn nicht, dann lösche ich den Absatz wegen groben Unfugs.

Natürlich löst Scrum wie alle anderen Methodiken weder das Welthungerproblem, noch ist es für alle Projekte geeignet (was ja auch im Artikel steht), und funkt auch nicht für Organisationen, wo Leute Macht nicht abgeben wollen (oder nicht Scrum machen wollen) - aber das zu erwähnen wäre schon etwas komisch oder? Das was du hier schreibts zeigt nur, dass du keine Ahnung von Scrum hast: Selbstverständlich lassen sich so gut wie alle Softwareentwicklungsaufgaben auf einen Tag herunterbrechen, selbstverständlich können komplexe Sachverhalte mit dem Planning Poker geschätzt werden, ja sogar mit Magic-Estimation ganze Projekte in 15min., was dir gerne Boris erklären kann. --Sebastian.Dietrich  ✉  18:57, 6. Okt. 2022 (CEST)