Was in einem Regelwerk steht sind konkrete Regeln und akzeptanzfördernde Rhetorik. Man analysiert ein Regelwerk indem man sich überlegt, wie sich die Regeln im Wechselspiel mit echten Menschen und Institutionen auswirken. Die Rhetorik ist dagegen irrelevantes Rauschen.
Machen wir das doch mal so:
Da standen im Product Backlog also Aufgaben zusammen mit einer Zahl die ungefähr äquivalent zu einer Zeitschätzung ist. (Ob das jetzt direkt eine Zeitschätzung, Story Points, T-Shirt-Größen oder sonstwas ist, ist hierfür jetzt erst mal gleich.) Dann hat das Team in das aktuelle Sprint Backlog so viele Aufgaben übernommen, wie es für realistisch hält. So weit noch einigermaßen anonym, obwohl da natürlich keiner der Beteiligten so dumm ist, das er den nächsten Schritt nicht mitgedacht hätte.
Und dann überlegt sich die Klasse mit Unterstützung des Lehrers, Verzeihung meine natürlich überlegt sich das Team mit Unterstützung des Scrum Masters wie es das erreichen will. Und wenn es damit fertig ist "sollte das Entwicklungsteam in der Lage sein, Product Owner und Scrum Master zu schildern, wie es als selbstorganisiertes Team an der Erreichung des Sprint-Ziels und Erstellung des gewünschten Produkt-Inkrements arbeiten möchte". Peng. Das läuft faktisch auf eine Aufteilung der Aufgaben hinaus, höchstens noch auf eine Regel wie die Aufgaben aufgeteilt werden. Und das die auch klar genug wird, dafür sorgt das akute Coaching des Scrum Masters.
Nun ist also klar wer wann für was eingeplant war und wie schwer das genau ist, es gibt also letztlich individuelle Leistungsquoten, die man zwar höflicherweise nicht offen mit denen anderer Teammitglieder numerisch vergleicht, bei denen das aber konstruktionsbedingt möglich ist und unausgesprochen selbstverständlich auch passiert. Ja, nominell ist es eine Kollektivpflicht. Und ja gut, man hat immerhin auf die rituelle Demütigung verzichtet hier eine offizielle "Vereinbarung" zu "schließen" (auch bei offiziellen Zielvereinbarungen ist das ja ein extrem euphemistischer Begriff) aber faktisch - und faktisch habe ich auch in meinem Beitrag weiter oben gesagt - ist damit glasklar was Sache ist.
Und für den Rest des Sprints wird der Mitarbeiter täglich berichten ob er das auch geschafft hat. Und wenn nicht, dann kommt der Scrum Master um ihn zu "coachen".
Wie gesagt, das ist jetzt noch nicht einmal die regelabweichende Umsetzung in einem Unternehmen, das ist abzüglich der euphemistischen Sprache Scrum wie es im Guide steht.
Dem Team bleibt jetzt noch die Notwehrmöglichkeit inoffiziell dafür zu sorgen, dass die Schätzung im Backlog immer ursprünglich von dem stammt, an dem die Arbeit rein zufällig hinterher auch hängen bleibt, faktisch also die eingeplante Vergleichbarkeit zu unterlaufen. Das ist aber ziemlich genau die Möglichkeit, die es im Wasserfallprozess auch schon gehabt hätte, nur eben mit etwas weniger Not davon auch Gebrauch zu machen.
Die Beschreibungen von SCRUM erinnern mich irgendwie an irgendwelche Maßnahmen zur Teambildung und/oder Gruppenarbeit in der modernen Pädagogik. Das dürfte kein Zufall sein.
Der angesprochene Punkt, dass die Menschen aus eigener Motivation statt aufgrund von Belohnung etwas tun sollen, führt uns direkt zur leidigen Diskussion des "Bedingungslosen Grundeinkommens" (BGE). Auch dort wird postuliert, dass gesellschaftlich notwendige Arbeiten weiterhin ausgeführt werden würden, weil die Menschen sich freiwillig eine Beschäftigung suchen. Faktoren wie Preis oder Kosten werden von den einschlägigen Ideologen ja ohnehin nicht für voll genommen. Sind anscheinend alles Epi-Phänomene, die Unterdrückung durch den Kapitalismus ist primär.
Ich halte es für eine offene Frage, ob es so etwas wie eine intrinsische Motivation überhaupt gibt. Die Behavioristen scheinen ganz gut ohne diese Idee auszukommen und allein das stellt meines Erachtens schon in Frage, ob so etwas überhaupt existiert.
Selbst wenn wir diesen mehr theoretischen Einwand mal außer Acht lassen, stellt sich doch die Frage, wie viele Menschen wirklich undankbare Aufgaben erledigen werden, wenn es dafür keine besondere Belohnung mehr gibt. Die praktischen Menschenkenntnis verrät, dass es einige sein werden, aber ob das genügt?
Bei SCRUM stellt sich außerdem die Frage, wer sich so etwas überhaupt ausdenkt.
Bin schon gespannt auf Teil 2. Es ist mir (noch??) nicht so ganz klar, für was der Heise-Verlag eine im Artikel anklingende Menge von Entwicklern braucht, das was man von außen sieht ist doch eher überschaubar, und im besuchersichtbaren Bereich teilweise von grauenvoller, sich stets verschlechternder Usability geprägt. Naja, stetige Verschlechterung ist ja auch irgendwie agil.
Zitat von hubersn im Beitrag #28Aktueller Arikel bei Heise Online, quasi aus der "Wir machen jetzt SCRUM"-Praxis:
Ich kann mit den SCRUM-Beschreibungen bisher wenig anfangen, sehe auch nicht, wo die Probleme mit dem Wasserfall-Verfahren sein sollen. Die in dem heise-Beitrag beschriebenen Probleme lassen einfach auf schlechtes Projektmanagement schließen. Dass ein Kunde sich nicht vorstellen kann, wie das was er will tatsächlich funktioniert ist der Regelfall, oder aber bei Massenprodukten, dass die Entwicklungs- und Marketingteams sich den falschen Kunden vorstellen.
Aus diesem Grund hat man das Rapid Prototyping vorangetrieben, im Hardwarebereich ist der 3D-Druck ein Segen. Man muss am Anfang eben Zeit und Arbeit investieren, um zu verstehen, wie das Produkt aussehen soll. Es kann sein, dass reine Software-Projekte zu Disziplinlosigkeit verführen, wenn der glaube vorherrscht, dass man alles auch schnell wieder korrigieren kann.
In unseren Hochzeiten der Entwicklung haben sich die Entwickler regelmäßig in einem Konferenzraum beim Rotwein getroffen. Das hat oft zu einem entspannten, aber informativen Austausch geführt, da kann man sich tägliche formale 'Wasserstandsmeldungen' sparen.
Ansonsten ist das Wasserfallmodell lediglich die Grundstruktur. Im regulierten Bereich muss sie auch bei kleinen Änderungen immer wieder im Schnelldurchlauf durchgefahren werden, weil bei jedem Phasenübergang Reviews und Approvals notwendig sind, die nicht übersprungen werden dürfen. Letztlich gilt das auch für alle Postproduction-Änderungen. Gut organisiert ist das überhaupt kein Problem - vor allem diszipliniert es. Vielleicht benötigt man heute aber andere Strukturen, weil die Leute eben nicht mehr diszipliniert sind.
Zitat von Martin im Beitrag #29 Ich kann mit den SCRUM-Beschreibungen bisher wenig anfangen, sehe auch nicht, wo die Probleme mit dem Wasserfall-Verfahren sein sollen.
Das Unglück ist ja nicht die SCRUM-Methodik an sich, sondern die Tatsache, dass SCRUM ganz gewisse Eigenschaften hat, deren Nutzen sich nur manifestiert unter ganz bestimmten Voraussetzungen.
SCRUM ist ein sehr natürlicher Softwareentwicklungsprozess, wenn das Ziel komplett im Nebel ist und man mit kurzen Iterationszyklen sich einer Lösung unter ständigem Einbeziehen des Kundenfeedbacks nähert. Nach meiner Erfahrung ist dieses Setup - und darin insbesondere die enge Verzahnung mit dem Kunden - aber sehr sehr selten. SCRUM wird hingegen sehr sehr häufig eingesetzt, und dann machen viele dort als gesetzt zu sehende Dinge nur wenig Sinn.
Ich hatte mal das Vergnügen, eine Zertifizierungsschulung zum SCRUM-PO zu machen bei einem sehr sehr erfahrenen Kursleiter. In den Fragerunden, wo die Teilnehmer aus ihrer Praxis berichteten, war seine häufigste Antwort "wenn die Sache bei Ihnen so liegt, dann müssen Sie sich fragen, ob SCRUM das richtige Prozessmodell ist".
Etwas merkwürdig fand ich immer, wie stark SCRUM sich als "Abkehr vom Wasserfallmodell" positioniert hat. In meiner langen IT-Erfahrung inklusive der Software-Engineering-Vertiefung während des Studiums habe ich nie Verfechter eines solchen Wasserfall-Prozesses gefunden, wie ihn SCRUM-Freunde immer nutzen, um seine Vorteile herauszustellen. Im Software Engineering gibt es ja zig iterative bzw. inkrementelle Vorgehensmodelle mit klaren Empfehlungen, wann was am ehesten auf welche Projekte passt. Ich sag' mal "Spiralmodell" nach Barry Boehm von 1986. Das hat den Vorteil, dass es auf jede Problemstellung passt
Ich war mal dabei, als in einer bereits agil arbeitenden Truppe SCRUM eingeführt wurde. Da hat man erst nach Jahren wieder eine ähnliche Produktivität wie vor der Einführung wieder erreicht (manche würden sagen: nie mehr). Merkwürdigerweise scheint SCRUM die Ideologen anzuziehen wie die Motten das Licht, ähnlich XP.
Zitat von hubersn im Beitrag #30SCRUM ist ein sehr natürlicher Softwareentwicklungsprozess, wenn das Ziel komplett im Nebel ist ...
Dann ist SCRUM ja perfekt für alle real existierenden IT-Projekte geeignet ;-)
Es ist ja tatsächlich so, daß die meisten (fast alle?) IT-Projekte unter unzureichend definierten Zielvorgaben leiden und dadurch Zeitpläne etc. Makulatur werden. Wenn man Projekterfolg will, muß man diese Zielvorgaben konkretisieren und Widersprüchlichkeiten beseitigen. Und ja, wenn man sich auf unbekanntes Terrain begibt (unbekannt insbesondere für den Kunden), dann kann Try-and-Error eine gute Methode sein, um ein Gefühl für die Sache zu kriegen und den Zielbereich einzugrenzen. Und da scheint SCRUM eine gute Methodik zu sein, um dsa Try-and-Error zu organisieren.
Wenn dagegen der Kunde widersprüchliche und lückenhafte Vorgaben macht, dann kann es elende Zeitvergeudung sein, diese Widersprüche durch Prototypen darzustellen. Und besonders schlimm wird es dann, wenn Kunde und Lieferant schon einen Vertrag unterschrieben haben. Da gilt dann schlicht: Egal ob der Kunde eine Giraffe haben wollte - wenn im Vertrag ein Elefant steht, kriegt er einen Elefanten. Notfalls einen mit gelbem Hals.
Von Gilbert (und anderen glaube ich) steht die These im Raum, dass Scrum eine extrem starke Überwachung erzeugt und damit den Arbeitsdruck massiv erhöht.
Zunächst mal rein empirisch kann ich das nicht bestätigen. Aber das mag eine zu subjektive Sichtweise sein. Natürlich (!!) gibt es auch weiterhin Menschen, die kreativ und leistungswilig sind. Es gibt eine Teilmenge - ich glaube, etwa 10 bis 20 % - die arbeiten. Egal, welche Knüppel man denen zwischen die Beine schmeisst. Die Arbeiten auch unter Scrum hart. Aber der Rest... es gibt schlicht zu viele Möglichkeiten bei Scrum Komfortzonen zu erschaffen:
- Team-basierte Schätzung. Das Team entscheidet, wieviel Arbeit es im Sprint aufnehmen möchte; dadurch entsteht viel tote Pufferzeit. Eine Aufgabe wird begonnen und eben so lange gestreckt, bis der Sprint vorbei ist. Individuelle Überwachung der Arbeitslast gibt es nicht - und da hilft auch kein Daily. Wenn ein Entwickler sagt "Ich arbeite noch an der Analyse" oder "Der RQ ist kompliziert" - dann kennt Scrum keine Sanktionen dagegen. Mir ist völlig unklar, wie man diesen Punkt wegdiskutieren will: wie kann jemals eine vernünftige Auslastung entstehen, wenn der Mitarbeiter (hier: das Team) SELBST ENTSCHEIDET, wieviel Aufgaben die abarbeiten wollen? In dem ich an die "Ehre" appelliere? Ich lach mich tot.
- Stillstände. Grundsätzlich soll bei Scrum keine Arbeit "nachgezogen" werden. Sind die Sprintziele abgearbeitet, dann hat das Team frei. In der Zeit sollen die Entwickler dann selbstbestimmt entscheiden, wie sie diese Freizeit zum größten Nutzen des Produktes verwenden. Oder wenn eine Aufgabe nicht lösbar ist, soll (in der Theorie) das ganze Team daran arbeiten, den Engpass abzustellen. In der Zeit wird quasi an nix anderem gearbeitet.
- Verantwortungslücken. Das Team soll ja bei Scrum "für alles" verantwortlich sein. Aber mangels Sanktionsmechanismen ist niemand zuständig. Scrum erlaubt es (entgegen der Theorie) sich vor Verantwortung zu drücken. Versuch mal in einem Scrum-Team jemanden festzunageln mit "Es war doch DEINE Verantwortung, an xy zu denken"... der geschulte Scrum-Entwickler antwortet nur locker "Ich bin doch nicht Projektleiter... das ist Team-Verantwortung".
- Selbstorganisation. Hier wird davon ausgegangen, jeder bekäme bei Scrum eine individuelle Teilaufgabe zugewiesen. Aber Scrum sagt dazu nichts. Wenn mehrere Entwickler gemeinsam an einem Task arbeiten wollen ist das absolut von Scrum gedeckt.
- Bewusstes brechen der Scrum-Regeln. Scrum kennt nun mal keine Sanktionsmechanismen (ich kann das gar nicht oft genug wiederholen). Am Ende des Sprints sind halt so und so viel Feature offen. Klarer Regelverstoß. Und was passiert dann? Eine RETRO. Uuuuh, wie gruselig. Ich lach mich tot.
- Künstliche Konfusion. Da bei Scrum die zentrale Instanzen entmachtet sind, entwickeln die Team ein "Team-spezifisches Scrum" und die Handlungen, Ziele und Ergebnisse sind gerade NICHT mehr team-übergreifend vergleichbar. In jedem Team eine andere Darstellung des Boards, andere Maßstäbe beim Planning, andere Aufwände pro Sprint point.
- Kollektiver Schutz für Minderleister. Manche Menschen mögen das als soziale Errungenschaft ansehen. Aber dann soll man bitte auch offen zugeben, dass Scrum ausdrücklich die Möglichkeit bietet, Minderleister zu schützen. Denn es gibt keine externe, individuelle Leistungsbeurteilung mehr. Entscheidet sich das Team dazu, eine Kollegin/Kollegen mitzuschleppen und durchzufüttern, dann kann man in Scrum rein gar nichts dagegen tun.
Wenn ich die Beiträge hier so durchlese, dann fühle ich mich bestätigt, dass Scrum nicht funktioniert. Denn die Vorschläge hier laufen auf Folgendes hinaus:
Ein Arbeitsmodell zwar Scrum zu nennen, aber etwas ganz anderes zu tun: Nämlich weiterhin individuelle Arbeitsaufträge zu verteilen und bei Nichterfüllung individuelles Versagen festzustellen. Und so, wie man aus Medizin Gift machen kann, kann man aus den Scrum-Werkzeugen auch einen Überwachungsstaat basteln. Wenn ich das Daily nicht als team-internes Werkzeug für Inspect&Adept verstehe, dann kann ich diesen Termin auch wunderbar nutzen für einen täglichen Statusbericht über die Abarbeitung individuell zugeteilter Aufgaben. Wenn ich das Review nicht so verstehe, dass vom Kunden (Stakeholder) eine Bewertung des FEATURES (= kollektive Aufgabe) eingeholt wird, dann kann ich das Review auch so nutzen, dass jeder seine persönliche Teilarbeit vorstellt (= individuelle Aufgabe).
___________________ Jeder, der Merkel stützt, schützt oder wählt, macht sich mitschuldig.
Und weil ich grade so im Schwung bin, möchte ich euch nicht einen Artikel vorenthalten, der in unserer Scrum Master-Community geteilt wurde. Dieser Artikel beschäftigt sich mit der von mir oben provokativ gestellten Frage:
"Mir ist völlig unklar, wie man diesen Punkt wegdiskutieren will: wie kann jemals eine vernünftige Auslastung entstehen, wenn der Mitarbeiter (hier: das Team) SELBST ENTSCHEIDET, wieviel Aufgaben die abarbeiten wollen? In dem ich an die "Ehre" appelliere?"
Die Antwort in der Glaubenslehre Scrum hatte ich in meinem Eingangsbeitrag bereits genannt: es werden "Stufen der Persönlichkeitsentwicklung" postuliert, die die Menschheit durchlaufen soll. Dabei werden diese Stufen völlig offen in eine Reihenfolge gebracht. Die sind also nicht gleichwertig, sondern höhere Stufen werden völlig offen als "wichtiger", "besser" oder "wirkungsvoller" betrachtet...
"Co-Kreatoren verstehen wie die vorherigen Level nicht mehr nur intellektuell, dass es verschiedene Wirklichkeiten gibt, sondern können das auch fühlen und daraus wirksame Verhaltensweisen ableiten. ... Ihre größte Kompetenz ist es, Verbindungen zwischen Wirklichkeitskonstruktionen zu erkennen, die andere nicht sehen und daraus Neues zu schaffen. Co-Kreatoren können aus vorhandenen Ideen, Gedanken und Strömungen etwas Neues schaffen, weil sie zu einer Dekonstruktion fähig sind ... Sie streben danach, sich für Vorhaben einzusetzen, die einen übergeordneten Sinn haben. Ihre Krise erleben sie, wenn sie... sich vielleicht irgendwann fragen, ob irgendetwas anderes leiten kann als der Moment und sehr einfache Dinge, wie Liebe, Natur, Menschsein. All das interpretieren sie nun immer symbolischer, wobei sie merken, wie sich Vergangenheit, Gegenwart und Zukunft in ihrer Chronologie langsam auflösen."
Höchste Stufe:
"Wenn Vergangenheit, Gegenwart und Zukunft sich auflösen, steigt die Bewusstheit für die Gestaltbarkeit von allem, für Geschichten und Metaphern. Synergisten können alles mit allem verbinden und deshalb auch zusammenführen. Ziemlich sicher werden spirituelle Gedanken und Praktiken in ihr Leben Einzug gehalten haben. Da die Verbundenheit mit allem, Holismus nun nicht mehr nur ein Gedanke, sondern Teil des Lebens geworden ist, werden Synergisten kaum noch mehr nur auf wirtschaftliche Zusammenhänge schauen. Die Logik von Wettbewerb und Gewinnmaximierung ist ihnen fremd geworden. Auch wenn ihre Überzeugungen nicht von anderen geteilt werden, arbeiten Synergisten an der Veränderung ihrer Umwelt. Sie begreifen sich als Gestalter von Wirklichkeit. Längst haben sie deshalb auch die Grenzen von Wissenschaft erkannt – und verstanden, dass wir nicht verstehen."
Ich weiß nicht, wie es euch geht, wenn ihr so was lest. Aber mir gruselt es dabei. Das klingt wie jede andere Sekte -sei es Kommunismus, Islam oder Nationalsozialismus - die sich über den "gewöhnlichen Menschen" erheben wollen und den "Neuen Menschen" bauen wollen. Wenn ich höre oder lese, dass sich jemand berufen fühlt, für die ganze Menschheit zu sprechen und "neue Wirklichkeiten" zu bauen, dann kommen mir Millionen Tote in den Sinn, die für "höhere Ziele" ermordet -Verzeihung: "geopfert" - wurden.
___________________ Jeder, der Merkel stützt, schützt oder wählt, macht sich mitschuldig.
Zitat von Frank2000 im Beitrag #33Wenn Vergangenheit, Gegenwart und Zukunft sich auflösen, steigt die Bewusstheit für die Gestaltbarkeit von allem, für Geschichten und Metaphern. Synergisten können alles mit allem verbinden und deshalb auch zusammenführen. Ziemlich sicher werden spirituelle Gedanken und Praktiken in ihr Leben Einzug gehalten haben.
Ganz großes Kino. Und real geht es dann darum, in der Abrechnungssoftware eine neue steuerliche Regelung einzubauen.
Es wäre großartig, wenn in Zukunft jeder seine Selbsteinschätzung bezüglich dieses Levels in seine Bewerbung reinschreibt, dann kann man viel einfacher die Idioten ohne vertiefendes Gespräch aussortieren.
Zitat von Frank2000 im Beitrag #33...wie kann jemals eine vernünftige Auslastung entstehen...
Mir fällt dazu ein ganz anderer Aspekt ein: Ich kenne IT-Projekte so, dass jemand eine Idee hat und die dann mit einem Team umgesetzt werden soll. Wenn dabei Know-How intern fehlt, werden eben Externe beschäftigt. Das geht wegen der geforderten Integration bei Scrum aber zumindest in Deutschland kaum noch, weil Auftraggeber und die Externen sofort dem Verdacht von Scheinselbstständigkeit und arbeitnehmerähnlicher Beschäftigung ausgesetzt sind.
D.h. man kann entweder das Projekt nicht umsetzten oder muss intern Ressourcen vorhalten, die nach Projektabschluss wieder Däumchen drehen.
Bei mir (bekennender Code-Monkey) lief das dann so, dass das Scrum-Team Präsentationen zur erfolgreichen agilen Transformation für das mittlere Management erstellt hat, während wir Externen gemütlich am heimischen Rechner und unbelastet von irgendwelchen Prozessen die Anforderungen umgesetzt haben.
Abschließend vielleicht noch ein ganz anderer Blickwinkel. Wir haben bei uns im Unternehmen Interviews mit Führungskräften zu Scrum-Themen geführt. Eine der Fragen bezog sich auf die Leistungsbewertung und Vergütung unter Scrum.
Die Führungskraft aus dem Bereich Verkauf/ Produktmanagement antwortete: im Verkauf spielt Scrum dabei keine Rolle, da im Verkauf das Ziel das Ziel ist und nicht etwa der Weg das Ziel ist.
Geschulte Scrum-Master würden mir jetzt heftig widersprechen und behaupten, Scrum würde ganz im Gegenteil eine viel stärkere Zielorientierung enthalten.
Wenn überhaupt, dann gilt diese Sichtweise nur in der Theorie. Ich habe selbst auf vielfältige Weise erlebt, dass unter Scrum schlechte Ergebnisse (und damit meine ich vor allem die Ablieferung lauffähiger Software) wegdiskutiert wurde. Aus der Sicht eines Vertrieblers, der am Ende des Jahres weniger Geld hat, weil ein Umsatzziel nicht erreicht wurde, stellt sich der Scrum-Kram als labernder Kindergarten dar.
___________________ Jeder, der Merkel stützt, schützt oder wählt, macht sich mitschuldig.
Das bento eine gewisse Sympathie für "Laberjobs ohne konkrete Leistungsmessung" hat, ist jetzt nicht überraschend. Ebenfalls nicht überraschend, dass weder dem gefragten Scrum master noch dem bento-Mitarbeiter aufgefallen ist, dass es eine in sich widersprüchliche Aussage gibt:
"Der Product Owner entscheidet, was wann getan werden soll. Das Entwicklerteam entscheidet wie und wie viel getan wird."
Wenn das Team entscheidet, wie viel getan wird, kann der PO nicht entscheiden, wann etwas getan wird. Denn das wie viel bestimmt das wann. Richtig wäre: "Der Product Owner entscheidet, was in welcher Reihenfolge getan werden soll. Das Entwicklerteam entscheidet wie und wie viel getan wird."
___________________ Jeder, der Merkel stützt, schützt oder wählt, macht sich mitschuldig.
___________________ Verbote sind Freiheit. Meinungen sind Terror. Quoten sind Leistung. Linke Regierung ist Familie. (c) Rot-Grüne Allianz Prophezeiung: 2022, das Jahr in dem in Deutschland der Schleier für alle eingeführt wird. Nennt sich dann "Maske". "Warum halten sie Begriffe wie 'Zigeunersoße' für rassistisch, aber 'Schei** Juden' für harmlos?", Hamed Abdel-Samad
Bitte beachten Sie diese Forumsregeln: Beiträge, die persönliche Angriffe gegen andere Poster, Unhöflichkeiten oder vulgäre Ausdrücke enthalten, sind nicht erlaubt; ebensowenig Beiträge mit rassistischem, fremdenfeindlichem oder obszönem Inhalt und Äußerungen gegen den demokratischen Rechtsstaat sowie Beiträge, die gegen gesetzliche Bestimmungen verstoßen. Hierzu gehört auch das Verbot von Vollzitaten, wie es durch die aktuelle Rechtsprechung festgelegt ist. Erlaubt ist lediglich das Zitieren weniger Sätze oder kurzer Absätze aus einem durch Copyright geschützten Dokument; und dies nur dann, wenn diese Zitate in einen argumentativen Kontext eingebunden sind. Bilder und Texte dürfen nur hochgeladen werden, wenn sie copyrightfrei sind oder das Copyright bei dem Mitglied liegt, das sie hochlädt. Bitte geben Sie das bei dem hochgeladenen Bild oder Text an. Links können zu einzelnen Artikeln, Abbildungen oder Beiträgen gesetzt werden, aber nicht zur Homepage von Foren, Zeitschriften usw. Bei einem Verstoß wird der betreffende Beitrag gelöscht oder redigiert. Bei einem massiven oder bei wiederholtem Verstoß endet die Mitgliedschaft. Eigene Beiträge dürfen nachträglich in Bezug auf Tippfehler oder stilistisch überarbeitet, aber nicht in ihrer Substanz verändert oder gelöscht werden. Nachträgliche Zusätze, die über derartige orthographische oder stilistische Korrekturen hinausgehen, müssen durch "Edit", "Nachtrag" o.ä. gekennzeichnet werden. Ferner gehört das Einverständnis mit der hier dargelegten Datenschutzerklärung zu den Forumsregeln.
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Offline
