Diskussion:Scrum/Archiv

message: 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)
thread_title:  Kritische Betrachtung 

message: 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)
thread_title:  Vorteile / Nachteil dieser Methode 

message: 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)
replies: text: 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)
thread_title:  Was ist ein Produkt-Backlog? 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Was sind Interkationen? 

message: 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)
thread_title:  Welche Firmen oder sonstige Gruppen im deutschsprachigen Raum benutzen Scrum? Für welche Projekte? 

message: 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)
replies: text: 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)
thread_title:  Software-Architektur? 

message: 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)
thread_title:  Schleichwerbung 

message: 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)
replies: text: 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)
thread_title:  Sprint 

message: 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)
replies: text: Ich habe die Einleitung etwas aufgeräumt und von wenig aussagekräftigen Sätzen befreit. --Das Ed 12:13, 24. Apr. 2010 (CEST)
thread_title:  Erster Abschnitt unklar 

message: 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)
replies: text: Ich hab den Abschnitt jetzt drastisch reduziert und statt auf Glaskugelei auf die Techniken fokussiert. --Sebastian.Dietrich 01:38, 9. Mai 2010 (CEST)
thread_title:  Zukunft von Scrum – Parallelisiertes Pipelining von Sprints 

message: 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)
replies: text: 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)

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

message: 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)
replies: text: 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)
thread_title:  Backlog 

message: 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)
replies: text: 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)
thread_title:  Tendenziöser Artikel 

message: 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)
replies: text: 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)
thread_title:  Unterschied Review <-> Retrospektive 

message: 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)
replies: text: 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)
thread_title:  Ist das auch auf Großprojekte anwendbar? 

message: 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)
thread_title:  Woher stammt die Bezeichnung 'Scrum'? 

message: 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)
thread_title:  Beschreibung des Product Owners 

message: 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)
thread_title:  Magic Numbers 

message: 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)
thread_title:  Scrum Master 

message: 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)
thread_title:  Grundlegende Überarbeitung erforderlich 

message: 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)
replies: text: 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)
replies: text:  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)

text: 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)
replies: text: 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)
thread_title:  Die Scrum-Lüge in einem Praxisbeispiel 

message: 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)
replies: text: Habs entsprechend korrigiert --Sebastian.Dietrich  ✉ 17:46, 3. Dez. 2010 (CET)
thread_title:  Länge von Aufgaben im Sprint Backlog 

message: 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)
thread_title:  Release Planning Meeting 

message: 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)
replies: text: 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)
thread_title:  Scrum ist ein Framework und kein Prozess 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Juristische Erwägungen 

message: 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)
replies: text: 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 . 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)
thread_title:  Erfahrung dass die meisten modernen Entwicklungsprojekte zu komplex sind 

message: 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)
replies: text: 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)
thread_title:  Daily Scrums 

message: 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)
replies: text: Gute Idee --Sebastian.Dietrich  ✉ 19:13, 2. Jan. 2014 (CET)
replies: text: 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)
thread_title:  Scrum Guide vs. Gloger 

message: 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. 
: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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)

text: +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)
thread_title:  Zertifizierung unzureichend 

message: Neuer Diskussions-Abschnitt "O neein!" plötzlich fälschlicherweise in "Einzelnachweise" gerutscht. Bitte um Korrektur! 
:Worum gehts? Du musst dich schon verständlicher äußern. --Schotterebene (Diskussion) 16:20, 4. Jun. 2020 (CEST)
replies: text:  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)
thread_title:  Was ist den hier passiert? (erl.)