Scrum Schnelleinstieg

Das Scrum-Framework
Kommentare

Scrum wird oft fälschlicherweise als Prozess oder Methode dargestellt. Dabei handelt es sich bei Scrum vielmehr um ein  Framework. Der Entwicklungsprozess selbst, also jene Handlungen und deren Abfolge, die vom Team vorgenommen werden, um von einer Idee zu einer auslieferbaren Software zu kommen, wird von Scrum so gut wie nicht vorgegeben.

Gerade weil Scrum so wenig invasiv ist, sprechen wir von einem Rahmenwerk, das durch einige wenige „Rahmenbedingungen“ gegeben ist. Innerhalb dieses Rahmens bestimmen die Entwicklungsteams selbst, was sie tun und wie sie zu ihren Ergebnissen kommen.

Dieser Rahmen hat natürlich Einfluss darauf, wie wir den Prozess gestalten, also welche Handlungen Teammitglieder vornehmen, wie sie testen, entwickeln, integrieren etc. Die wichtigste Funktion des Frameworks ist die kontinuierliche Inspektion und Adaption, einerseits von Arbeitsergebnissen und andererseits dieses Prozesses.

Sprints

Dazu stehen Iterationen, in Scrum Sprints genannt, im Zentrum des Scrum-Frameworks. Ein Sprint ist eine Timebox, ein Zeitraum mit fixer Dauer, z. B. zwei Wochen. Im Kontrast zu nicht agilen Vorgehensweisen wird in Scrum die Zeit in Intervalle unterteilt, die eine regelmäßige Begutachtung des Fortschritts und der Prozessgüte erlauben. Die Länge eines Sprints soll daher möglichst konstant bleiben, nur so wird ein konsistenter Inspektionsmechanismus etabliert.

Durch diese Beschränkung in der Zeit wird die oben genannte Inspektion und Adaption ermöglicht. Am Ende eines Sprints verlangt Scrum nach einem „potenziell auslieferbaren Produktinkrement, also nach brauchbarer, funktionsfähiger Software. Teams verfügen über eine gemeinsame Definition, was genau darunter verstanden wird, also welche Beschaffenheit Software haben muss, um als „auslieferbar“ akzeptiert zu werden. Ganz allgemein gelten aber die folgenden Eigenschaften:

  • Funktional vollständig umgesetzt (im Sinne der gemeinsam besprochenen Anforderungen)
  • Getestet und frei von bekannten Fehlern
  • Integriert und auf einer realistischen Systemumgebung vorgeführt (also nicht auf einem Entwicklersystem)

als wohlverstandenes Minimum hierfür. Damit verlangt Scrum, dass der gesamte Entwicklungsprozess in einem kurzen Zeitraum End-to-End durchlaufen wird.

In Abbildung 4.1 ist das Scrum-Framework zu sehen. Im Zentrum stehen Sprints mit auslieferbaren Produktinkrementen. Ein Inkrement ist ein Stück wertvolle, also brauchbare und funktionierende, fehlerfreie Software. Mit „fehlerfrei“ ist hier „frei von bekannten Fehlern“ gemeint.

Abbildung 4.1: Das Scrum-Framework

In der Architektursicht betrachtet sind Inkremente immer ein vertikaler Schnitt über alle Schichten der technischen Architektur. Inkremente sind das Sprint-Ziel und umfassen die zugehörigen User Stories.

In der Architektursicht betrachtet sind Inkremente immer ein vertikaler Schnitt über alle Schichten der technischen Architektur. Inkremente sind das Sprint-Ziel und umfassen die zugehörigen User Stories.

Abbildung 4.2: Inkrementelle Produktentwicklung

Ein Inkrement umfasst immer auch die zuvor ausgelieferten Inkremente, um sicherzustellen, dass die neuen Funktionen nicht bereits erstellte und womöglich auch ausgelieferte Software beeinträchtigen. Vollständige Softwarereleases (im Sinne von MMFs, vgl. Kapitel 3) werden dabei in einer aufeinanderfolgenden Sequenz von Sprints geliefert.

Ursprünglich wurden für die Dauer von Sprints vier Wochen definiert, die meisten Teams haben sich jedoch im Laufe der Jahre für einen deutlich kürzeren Zeitraum entschieden, um schnellere Feedbackzyklen zu erhalten, typischerweise sind das heute zwei Wochen. Die Sprint-Dauer kann natürlich im Laufe der Zeit geändert werden, jedoch ist dann eine Stabilisierung von erfahrungsgemäß ca. drei bis fünf Sprints notwendig.

Das Wesen von Scrum ist durch die drei Eckpfeiler des Frameworks, Transparenz, Inspektion und Adaption als empirische Prozesssteuerung bestimmt. „Empirisch“ bedeutet in diesem Zusammenhang, dass der Prozess (im obigen Sinne) durch Entscheidungen und Anpassungen gesteuert oder besser verändert wird, die auf Erkenntnissen und Erfahrungen basieren, die in den vorangegangen Iterationen gewonnen wurden.

Transparenz

Transparenz in Bezug auf die aktuelle Situation, die Probleme, den Prozess und das Zusammenwirken aller Beteiligten ist in Scrum ein Grundpfeiler des Frameworks.

Durch die Kompression des Prozesses von der Idee zur fertiggestellten und lauffähigen Software (bzw. des Produktinkrements) auf den sehr kurzen Zeitraum eines Sprints werden Prozessschwächen und Probleme deutlich sichtbar.

Inspektion

Wie in Kapitel 3 bereits angesprochen, teilt Scrum die Verantwortungen des Entwicklungsprozesses in drei Rollen. Deren Aufgabe ist es nun, in regelmäßigen Intervallen all jene Ergebnisse zu inspizieren, die durch die Transparenz sichtbar geworden sind. Dabei ist es wichtig, das Ziel (oder eine Vision) und den Fortschritt im Hinblick darauf nicht aus den Augen zu verlieren.

Adaption

Diese Erkenntnisgewinnung führt zu Anpassungen am Prozess, an den Anforderungen, an technischen Lösungen und manchmal sogar am Ziel. Diese Anpassungen werden so schnell wie möglich und notwendig umgesetzt.

Allein am Beispiel der Forderung nach auslieferbarer Software als Rahmenbedingung lässt sich gut erkennen, wie Scrum funktioniert. Teams, die mit Scrum beginnen, haben in der Regel massive Schwierigkeiten damit, nach bereits zwei Wochen einen komplett fertiggestellten, fehlerfreien und brauchbaren Teil ihrer Software zu liefern. Die durch Scrum eingebrachte Transparenz lässt die Problemstellen in ihrem heutigen Prozess der Erstellung von Software klar zutage treten. „Inspect & Adapt“ – so der englische Begriff hierfür – hilft dem Team, hier besser zu werden.

Eine andere Ebene der Erkenntnisgewinnung ist gegeben durch das Feedback von fertiggestellten Features einer Software am Ende eines Sprints. Hier erlernen sowohl Mitglieder des Scrum-Teams als auch Benutzer, Kunde etc. (Stakeholder) die Möglichkeiten der Technologie und kommen z. B. auf neue, zuvor noch unbekannte Anforderungen. Noch eine andere von vielen weiteren Erkenntnissen ist die Leistungsfähigkeit oder Kapazität des Teams, wie viel an neuen Features also ein Team in einem bestimmten Zeitraum (Sprint) liefern kann.

In Abbildung 4.1 sind die beiden wesentlichen Rückführungskanäle an den Rändern oben und unten eingezeichnet:

  • Im Sprint Review wird das Sprint-Ergebnis inspiziert und Feedback von Kunden und Stakeholdern an das Scrum Team geliefert. Das Ergebnis sind Produktverbesserungen. Das könnten z. B. neue oder geänderte Anforderungen in Form von Product-Backlog-Einträgen sein.
  • In der SprintRetrospektive wird der Sprint selbst inspiziert und dazu Feedback über das Zusammenwirken, über den Prozess der Erstellung des Sprint-Ergebnisses oder auch die Zielerreichung gegeben. Das Ergebnis einer Sprint-Retrospektive sind Verbesserungsmaßnahmen für den Prozess.

Info

Anhand dieses Bildes ist erkennbar, dass das Scrum-Framework einen Regelkreislauf darstellt, in dem die Erkenntnisse aus dem aktuellen Sprint unmittelbar in die nächsten Handlungen (Sprint) einfließen.

Wie bereits erwähnt, folgen in Scrum Sprints unmittelbar aufeinander. Es gibt keine Pause zwischen ihnen. An welchem Wochentag ein Sprint beginnt bzw. endet, bestimmt im Normalfall das Scrum Team, die Ausnahme davon sind synchronisierte Sprints mehrerer Teams, hier ist eine gemeinsame Absprache nötig.

Ungestörte Arbeit

Sprints sind in Scrum ein geschützter Zeitraum für das Umsetzungsteam, das sich gemeinsam mit dem Product Owner zu Beginn eines Sprints auf ein zu erreichendes Ziel einigt (Sprint-Planung). Das Team wird alle nötigen Aufgaben wahrnehmen und sein Bestes geben, um das Ziel zu erreichen. Im Gegenzug dazu wird das Team nicht mehr gestört. Das bedeutet, dass keine neuen Anforderungen hinzukommen dürfen und die Teammitglieder ihre Zeit zu 100 % dem Sprint-Ziel widmen dürfen. Die Konsequenz ist, dass sie auch nicht mit anderen Aufgaben oder Projekten belastet werden dürfen. Damit kann ein Scrum Team effizient und effektiv am Ziel arbeiten.

Aufmacherbild: Businessmen playing rugby isolated in white von Shutterstock / Urheberrecht: Luis Louro

[header = Scrum Meetings]

Scrum Meetings

Scrum definiert vier Meetings, auch Zeremonien oder Ereignisse genannt:

  • Sprint-Planung (engl. „Sprint Planning“)
  • Daily Scrum
  • Sprint Review
  • Sprint-Retrospektive

Zur laufenden Pflege des Produkt-Backlogs wurde von den meisten Teams ein weiteres Meeting eingeführt, das so genannte „Backlog Grooming“, das jedoch nicht zum Kern von Scrum gehört.

Im Folgenden wollen wir kurz die Meetings im Zusammenhang mit dem Framework erörtern, um einen Überblick über Scrum zu geben. In den nachfolgenden Kapiteln wird jedes einzelne Meeting nochmals vertieft und über die Forderungen des Scrum-Frameworks gute Praktiken beschrieben, diese Meetings abzuhalten. Dabei wollen wir Antworten auf jeweils typische Fragen zu den Scrum Meetings geben.

Sprint-Planung

Das Allererste, was ein Scrum Team in einem Sprint macht, ist den Sprint zu planen, dazu gibt es das Planungsmeeting. Im Sprint-Planungsmeeting wird gemeinsam mit dem Product Owner ein Sprint-Ziel festgelegt. Dieses beschreibt ein „sinnvolles Ganzes“ – also das Ergebnis des Sprints, das „auslieferbare Produktinkrement“.“. Neben dem Sprint-Ziel werden hier auch eine bestimmte Anzahl an Einträgen bzw. User Stories aus dem Produkt-Backlog gewählt – diese nennen wir dann „Sprint Backlog“.

Das bedeutet, dass das Umsetzungsteam nur so viele Anforderungen aus dem Produkt-Backlog wählt, wie es glaubt, in diesem Sprint umsetzen zu können. Die Reihenfolge hingegen wird vom Product Owner bestimmt. Die Anforderungen werden dann aus dem Produkt-Backlog entnommen und in den Sprint Backlog übernommen.

Info

Das Zusammenwirken von Sprint-Ziel und Sprint Backlog kann auch so dargestellt werden, dass das Sprint-Ziel ähnlich einer Vision für einen Sprint zu verstehen ist, und die gewählten Einträge (Sprint Backlog) stellen dann die Akzeptanzkriterien für das Ziel dar.

Nach der Einigung darüber, was gemacht werden soll, nimmt sich das Scrum Team die Zeit, einen Plan zu erstellen, wie das Sprint-Ziel erreicht werden soll. Im Anschluss beginnt die Arbeit an den einzelnen Aufgaben durch das Umsetzungsteam.

Daily Scrum

Während eines Sprints findet an jedem Arbeitstag ein kurzes, maximal 15 Minuten dauerndes Meeting statt, in dem das Team seinen Fortschritt hinsichtlich des Sprint-Ziels inspiziert und eine Planung für die verbleibende Arbeit, insbesondere für diesen Tag, bespricht. Für diese Inspektion verwendet das Team mehrere Artefakte, die auch die Selbstorganisation eines Teams unterstützen. In der Praxis haben sich hierzu das Sprint Burndown Chart und das Taskboard als besonders gut geeignet erwiesen.

Die Tagesarbeit wird hier grob besprochen, im Anschluss an das Daily Scrum werden offene oder neu auftauchende Punkte im Detail besprochen. Im Daily Scrum werden also keine inhaltlichen Diskussionen geführt. Dieses Meeting wird typischerweise im Stehen vor dem Taskboard abgehalten, um es kurz zu halten (daher hat dieses Meeting auch den Namen „Standup“ in anderen agilen Vorgehensweisen).

Das Daily Scrum ist also ein wichtiger „Inspect & Adapt“-Punkt im Scrum-Framework. Es unterstützt in erster Linie das Umsetzungsteam bei seiner Selbstorganisation. In der Praxis hat sich die Mechanik der drei Fragen als gut erwiesen, wenn Teams mit Scrum starten. Dazu beantwortet jedes Teammitglied die folgenden drei Fragen:

  • Was habe ich seit gestern/dem letzten Mal gemacht bzw. erreicht?
  • Was werde ich heute/bis zum nächsten Mal tun?
  • Welche Blockaden habe ich, was hindert mich am Fortschritt?

Die letzte Frage zielt darauf ab festzustellen, ob es Probleme gibt, die das Team daran hindern, effizient fortzuschreiten und das Sprint-Ziel zu erreichen.

Sprint Review

Im Sprint Review wird das gelieferte Produktinkrement inspiziert. Dazu führt das Scrum Team den Stakeholdern die Software auf einer produktionsähnlichen Umgebung mit realen Daten vor. Das Ziel des Review Meetings ist es, von den Stakeholdern, Benutzern, Kunden etc. möglichst viel Feedback zum Produktinkrement zu erhalten.

Normalerweise werden hier Erkenntnisse gewonnen, die in der Regel zu neuen bzw. geänderten Anforderungen führen. Es kann sein, dass das gelieferte Stück Software noch nicht dem entspricht, was sich die Kunden wünschen, dass Anforderungen nicht richtig umgesetzt oder nicht gänzlich verstanden wurden etc. In vielen Fällen werden hier auch Verbesserungen entwickelt, die auf Basis der Erkenntnis entstehen, was überhaupt möglich ist, bzw. anhand von neu erlangtem Wissen über neue Technologie oder Benutzbarkeit. Das Review Meeting ist ein weiterer zentraler Punkt der Inspektion und Adaption in Scrum – auf inhaltlicher Ebene.

Das Review Meeting nimmt auch die Rolle der Berichterstattung über den Fortschritt ein. Hier können sich sämtliche Beteiligte ein Bild darüber machen, was bereits geliefert und wie weit das Entwicklungsvorhaben fortgeschritten i

Sprint Retrospektive

In der Retrospektive betrachtet das Scrum-Team den Prozess der Erstellung des letzten Inkrements bzw. den letzten Sprint, es stellt das Gegenstück zum Sprint-Review als prozessuale Inspektion und Adaption dar. Es wird darauf geachtet, welche Probleme aufgetreten sind, was überraschend gut lief, welche unerwarteten Ereignisse eingetreten sind etc.

Die Inspektion liefert auch Einsichten und Gründe, warum Dinge passiert sind. In weiterer Folge erarbeitet das Scrum Team einige wenige konkrete Maßnahmen, um den Prozess auf Basis der gewonnenen Erkenntnisse zu verbessern.

Weitere Meetings

Die folgenden Meetings sind nicht Bestandteil des Scrum-Frameworks, sie sind jedoch bei so gut wie allen Scrum Teams zu finden. Es macht daher Sinn, sie im Kontext des Frameworks kurz zu erörtern.

Backlog Grooming Meeting

In der Sprint-Planung werden User Stories (oder allgemein PBIs) in einen Sprint übernommen. Das Umsetzungsteam wählt bzw. „zieht“ eine User Story nach der anderen in den Sprint Backlog. Damit eine User Story überhaupt in einen Sprint übernommen werden kann, muss sie in einem bestimmten Zustand hinsichtlich der Vorarbeiten sein. Dann kann das Umsetzungsteam garantieren, sie innerhalb eines Sprints umzusetzen (vergleiche hierzu auch die DEEP- und INVEST-Kriterien aus Kapitel 3).

In diesem Meeting wird das Produkt-Backlog „gepflegt“ (engl. „grooming“).  Das Team fokussiert sich damit in diesem Meeting auf die zukünftigen Lieferungen, also jene, die außerhalb des laufenden Sprints liegen, um den Backlog für den nächsten, den übernächsten und die folgenden Sprints vorzubereiten.

Wie beschrieben, werden die Details zu einer Anforderung bzw. User Story erst im Laufe der Zeit erörtert. Allein durch die Tatsache, dass in einem Sprint (genauer bei der Planung) dem Produkt-Backlog Einträge entnommen werden und die nachfolgenden Einträge nachrücken, entsteht die Notwendigkeit, sie weiter zu detaillieren. Das Backlog Grooming Meeting ist genau dafür da, dabei werden folgende Aktivitäten wahrgenommen:

  • Das Team schätzt die Einträge des Produkt-Backlogs, z. B. unter Zuhilfenahme der „Planning Poker“-Schätztechnik.
  • Zu umfangreiche, also zu große User Stories werden in kleinere User Stories mit höherem Detailgrad aufgeteilt.
  • Durch die Aktivität des Schätzens wird neues Wissen im Team generiert. Ein wichtiger Aspekt des Backlog Groomings ist es, dass im Team neues Domänenwissen entsteht bzw. verteilt wird.
  • Es wird auch über technische Risiken gesprochen, sodass der Product Owner Feedback darüber bekommt, ob Features mit hohem Geschäftswert auch technisch ein hohes Risiko bergen (z. B. architekturrelevante Features) und ggf. höher zu priorisieren sind.

Design- und Architekturmeetings

Agile Softwareentwicklung und Scrum im Besonderen legen gesteigerten Wert auf Zusammenarbeit im Team. Daher ist es wichtig, dass Entwurf und Architektur vom ganzen Team und nicht von einzelnen Personen gemacht werden. Viele erfolgreiche Scrum Teams nehmen sich pro Sprint sogar mehrmals Zeit, um gemeinsam grobe Architekturkonzepte für die Lösung und technische Herausforderungen bei einzelnen User Stories im gesamten Team zu besprechen. Hierbei wird das intellektuelle Kapital einer gesamten Gruppe[1] wirksam eingesetzt, und nicht nur ein einzelnes Gehirn bemüht.

Release-Planungsmeeting

Manchmal ist in der Scrum-Literatur von einem Meeting zur Planung eines Releases zu lesen. Diese Meetings werden in der Regel dazu benutzt, eine grobe Vorschau darauf zu geben, was in einem Release – typischerweise eine Sequenz von rund drei bis zwölf Sprints – enthalten sein wird. Oft wird dazu auch eine eigene Vision vermittelt.

Ein solches Meeting ist nicht Bestandteil des Scrum-Frameworks. Vielmehr ist die laufende Inspektion und Adaption eines Plans im Hinblick auf einen auszuliefernden Umfang oder auf einen Lieferzeitpunkt auf der Basis des bestehenden Wissens eine Aufgabe, die dem Product Owner zuzuschreiben ist. Weitere Details dazu sind in Kapitel 12 zu finden.

Scrum-Artefakte

Neben den drei Rollen und den vier Meetings definiert Scrum auch noch drei Artefakte. In der Literatur zu Scrum sind hier meist unterschiedliche Angaben zu finden, manchmal sind auch vier Artefakte benannt. Im Original sind es

  • Das Produkt-Backlog (Kapitel 2),
  • Das Sprint Backlog (Abschnitt 4.2.1)
  • Das auslieferbare Produktinkrement (Abschnitt 4.1).

Die Scrum Alliance und andere Mitglieder in der internationalen Scrum-Gemeinde definieren den Burndown Chart (Kapitel 7) als weiteres Artefakt. Unabhängig von der exakten Definition sind die hier beschriebenen vier Artefakte essenzielle Merkmale von Scrum, ohne die dessen wesentliche Funktion nur eingeschränkt gewährleistet ist.

Info

Anhand der bisher beschriebenen drei Rollen, drei Artefakte und vier Meetings ist gut erkennbar, dass Scrum kein Prozess, sondern ein Rahmen ist, der den eigentlichen Prozess der Softwareerstellung empirisch steuert. Es gibt immer wieder Diskussionen, ob das Regelwerk von Scrum nicht als Prozess gesehen werden kann. Wer es so sehen möchte, möge Scrum am besten als Metaprozess bezeichnen.

Als Scrum Coaches sehen wir immer wieder Organisationseinheiten, die nur Teile des Scrum-Frameworks umgesetzt haben und dann darüber klagen, dass Scrum nicht gut funktioniere oder nur überschaubare Verbesserungen liefert. In anderen Teams wiederum wurden Teile weggelassen, da sie Probleme machten oder nicht wie gewünscht funktionieren. Solche Scrum-Implementierungen nennen wir in der Scrum-Community Scrum-But, nach dem Muster „Wir machen Scrum, aber …“ (tun dies und das nicht).

Meinung

Das Scrum-Framework an sich ist sehr leichtgewichtig und braucht – auch auf die Gefahr hin, als Evangelist zu wirken – alle seine drei Rollen, drei Artefakte und vier Meetings, um wie bestimmt zu wirken.

Wirkung

Scrum wurde in den letzten Jahren sehr populär und von vielen Unternehmen aufgegriffen. Auch wenn Scrum heute noch nicht im Mainstream angekommen ist, ändern zunehmend mehr Organisationen ihren Entwicklungsprozess hin zu agilen Vorgehensweisen und damit meist zu Scrum. Viele denken, Scrum sei die Lösung für alle ihre Probleme und mit Scrum werde alles gut – manche denken, Scrum sei „the next best thing“ und man müsse es einfach tun.

Das ist schlichtweg falsch. Mit Scrum allein wird gar nichts gut. Ok, das ist vielleicht etwas übertrieben, aber die Wirkkraft von Scrum kommt von den folgenden Faktoren:

  • Knallharter Transparenz und Feedback
  • Selbstorganisation bzw. selbstorganisierende Teams
  • Dem nicht zu bändigenden Drang nach Veränderung hin zu besserem Tun
  • und einigen wenigen Regeln (das hier besprochene Framework).

Man sieht, dass im Kern betrachtet Scrum nicht mehr ist als ein konstanter Feedback-Regelkreis, der zunächst nur aufzeigt, welche Probleme eine Organisation hat, ein Konzept in lauffähige Software zu überführen. Dieser Überführungsprozess wird in Scrum auf einen sehr kurzen Zeitraum – einen Sprint – komprimiert und diese Kompression macht sämtliche Probleme, Prozessschwächen und Flaschenhälse sichtbar. Scrum ist ein Framework für Change Management.

Die wesentliche Wirkung von Scrum ist, wie schon in Kapitel 2 erwähnt, vergleichbar mit einem Spiegel. Scrum zeigt nackte Tatsachen auf und präsentiert sie im Abstand von zwei Wochen. Und Scrum definiert eine Rolle, die sich darum kümmert, dass diese Probleme angegangen werden – die des Scrum Masters.

Endogenes Change Mangement

Der endogene Veränderungsprozess, also der Wunsch nach Veränderung von innen heraus, vom Ort des Geschehens, wirkt einerseits im Team, andererseits außerhalb des Teams, und berührt damit die Organisation. Die Probleme werden dort sichtbar, wo Software entwickelt wird. In einer Organisation, zu deren Hauptgeschäftsprozessen die Softwareentwicklung gehört, entsteht der Wunsch nach Verbesserung also im Zentrum, im innersten Kern der Organisation. Im nicht seltenen Fall von konkurrierenden Prozessen ist, je nach Stellenwert der Softwareentwicklung in der Organisation, die Wichtigkeit einer konkreten Veränderung zu beurteilen.

Jede Organisation, die Scrum ernsthaft einführt und auf mehrere Teams ausweitet, wird bereits nach kurzer Zeit mit dieser Wirkung konfrontiert. Die Scrum Master funktionieren zwar als Agenten der Veränderung, sind aber meistens nicht ausreichend in die Lage versetzt, eine gesamte Organisation in diesem Veränderungsprozess zu steuern. Sie arbeiten typischerweise mit einem oft „Transition Team“ genannten, virtuellen Team aus Managern zusammen, um den Veränderungsprozess voranzutreiben (siehe dazu auch Kapitel 13).

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -