Software-Engineering – agile Pattern und agile Antipattern: Retrospektive Antipattern (Teil 1)

Inhalt:

  1. Keine Retrospektive benötigt
  2. Retrospektiven bringen nichts
  3. Auf die nächste Retrospektive verschieben
  4. Retrospektive die entbehrliche Pufferzeit
  5. Übereilte Retrospektive
  6. Gebrochene Las Vegas Regel
  7. Das Team in der Opferrolle
  8. Action-Items sind nicht SMART
  9. Keine Verantwortlichen und keine Verbindlichkeit
  10. Kein Abschließen von Action-Items

1. Keine Retrospektive benötigt

Beschreibung des Antipatterns:

  • Das Team hält keine Retrospektive ab, weil es glaubt, es würde nichts zu besprechen geben.

Warum ist das schlecht?

  • Es gibt immer etwas zu besprechen und zu verbessern, sieht das Team dies nicht, so wird vielleicht die Retrospektive falsch abgehalten oder das Team ist zu unreflektiert und sieht wirklich nicht, was gut und was schlecht gelaufen ist und was besser gemacht werden kann. Hält das Team die Retrospektive jedenfalls für unnötig, wird sie nicht oder maximal halbherzig gemacht. Dies hat denn Effekt, dass keine Verbesserung stattfindet und die Kommunikation bzw. die Zusammenarbeit zwischen den Teammitgliedern leidet.
  • Es können Konflikte entstehen oder begünstigt werden, wenn keine oder zu wenige Retrospektiven abgehalten werden.
  • Weil das Team die Möglichkeiten der Retrospektive nicht ausschöpft, leidet die Effizienz des Teams außerdem.
  • Die Teamarbeit wird dementsprechend nicht verbessert, denn das Team reflektiert nicht, wie die Arbeit abläuft und findet auch somit auch keine konkreten Verbesserungsmaßnahmen.

Verbesserungen:

  • Um Verbesserungen abzuleiten, muss zunächst geklärt werden, wie es zu der Einstellung kommt, dass das Team keine Retrospektive benötigt.
  • Liegt die Aussage „Es gibt nichts zu besprechen“ daran, dass das Team nicht gut reflektieren kann und wirklich das eigene Potenzial aber auch die eigenen Fehler und Wissenslücken nicht sieht, so ist dies oft auf fehlende Entwicklungserfahrungen und fehlende Reflektionskompetenz zurückzuführen.
  • Aber auch ein fehlendes Verständnis und Wissen über Scrum und die Sprint Retrospektive können hier hinderlich sein.
  • Oft schlägt in diesen Situationen der Dunning Kruger Effekt1 zu. Dieser führt dazu, dass wir uns heillos Überschätzen, weil wir zu wenig Ahnung von einem Thema haben und uns nicht in der Tiefe mit dem Thema beschäftigt haben.
  • Liegt das Problem also im fehlenden Verständnis für Scrum und der Sprint Retrospektive, so sollte der Scrum-Master das Team zunächst schulen und für dieses Verständnis sorgen.
  • Sollte das Problem aber an der fehlenden Kompetenz und Selbsteinschätzung liegen, muss zunächst der psychologische Mechanismus hinter dieser Fehleinschätzung bewusst gemacht werden. Ist dies dem Team dann klar, kann es sinnvoll sein, dem Team Zeit für Aus- und Weiterbildung zu geben. Zusätzlich sollte auch ein erfahrenen Softwareentwickler und Mentor dem Team beiseitegestellt werden, der dann das Team auf technische Weise unterstützt und coacht.

1https://www.quarks.de/gesellschaft/psychologie/warum-wir-uns-oft-selbst-ueberschaetzen/

2. Retrospektiven bringen nichts

Beschreibung des Antipatterns:

  • Das Team ist nicht davon überzeugt, dass Retrospektiven etwas bringen, es hält das Meeting für reinste Zeitverschwendung.

Warum ist das schlecht?

  • Gelangt das Team zu dieser Einschätzung, ist dies meist ein Zeichen dafür, dass bereits viel zu lange Retrospektiven falsch oder schlecht gemacht wurden.
  • Die Sprint Retrospektive ist ein wichtiges Inspect-Meeting, welches dem Team die Möglichkeit bietet, aus dem vergangenen Sprint zu lernen und besser zu werden. Das Team passt sich durch die Retrospektive an veränderte Bedingungen oder neue Erkenntnisse an. Wird keine Retrospektive abgehalten, oder wird diese als nicht sinnvoll erachtet, führt dies dazu, dass sich das Team nicht weiterentwickeln kann und nicht aus seinen Erfahrungen und Fehlern lernt.
  • Im schlechtesten Fall wird dann das Retrospektivenmeeting weitergeführt, um konform zu Scrum zu sein, aber die Teammitglieder sitzen teilnahmslos dabei, ziehen keinen Nutzen oder machen aus der Retrospektive ein lustiges Event und sabotieren somit den Erfolg des Meetings.

Verbesserungen:

  • Zunächst einmal sollte das Problem offen vom Scrum-Master angesprochen werden. Der beste Platz dies zu tun ist die Retrospektive.
  • Hat der Scrum-Master das Problem also erkannt, so muss die Ursache für diese Einstellung gefunden werden.
  • Nur wenn die Retrospektive einen Mehrwert für das Team und das Projekt liefert, wird sie gerne vom Team gemacht. Um dies zu erreichen, sollte der Scrum-Master das Team fragen, was es sich von der Retro erwartet.
  • Der Scrum-Master muss dann versuchen, die nächsten Retrospektivenmeetings mit dem Team so zu gestalten, dass alle auf ihre Kosten kommen und ihre Erwartungshaltungen erfüllt werden.

3. Auf die nächste Retrospektive verschieben

Beschreibung des Antipatterns:

  • Das Team will keine Retrospektive machen, weil es gerade sehr viel zu tun hat und lässt für diesen Sprint die Retrospektive ausfallen, denn die nächste Retrospektive kommt sowieso nach dem nächsten Sprint somit ist es ja nicht so wichtig.

Warum ist das schlecht?

  • Fängt das Team einmal mit dieser Argumentation an, gibt es kein Halten mehr.
  • Die Retrospektive kann dann immer wieder mal ausfallen und verschoben werden.
  • Dabei ist die Retrospektive eines der Kernelemente von Scrum und eine Möglichkeit für das Team dazuzulernen, die eigene Arbeit und die Teamarbeit zu verbessern.
  • Wird keine Retrospektive abgehalten, können größere Probleme im Projekt entstehen und gegebenenfalls nicht verhindert werden, dies kostet dann unnötig Zeit.
  • Es kann auch sein, dass das Team nicht so effizient arbeitet und deswegen den Zeitstress in erster Linie überhaupt hat. Um das aufzudecken, ist eine Retrospektive notwendig, somit sollte diese auf keinen Fall ausgelassen werden, weil sonst das Team nie aus dieser Endlosschleife ausbrechen kann.
  • Ist die Zeit aufgrund externer Faktoren eingeschränkt, sollte die Retrospektive ebenfalls gemacht werden, weil dadurch Konflikte verhindert werden und Psychohygiene betrieben werden kann. Verhindert das Team durch das Abhalten der Retrospektive nur einen einzigen Konflikt oder ein Problem eines Kollegen, ist die Zeit schon wieder gewonnen.

Verbesserungen:

  • Retrospektiven-Meetings sollten immer zum selben Zeitpunkt im Sprint durchgeführt werden. Diese Regelmäßigkeit verschafft dem Team die notwendige Routine, um sich an das Abhalten der Retrospektive zu gewöhnen und diese effizient durchzuführen.
  • Der Scrum-Master sollte sich auf jeden Fall dafür einsetzen, die Retrospektive abzuhalten.
  • Er sollte einen fixen Serientermin planen, der am Ende eines jeden Sprints automatisch abgehalten wird.
  • Es gibt im Sprint immer etwas zu verbessern oder zu diskutieren und es sollte nicht einziehen, dass diese Verbesserung auf die lange Bank geschoben wird und nicht stattfindet. Statt dessen sollte der Scrum-Master dem Team bewusst machen, welch ein Fehler es wäre hier sich die Zeit nicht zu nehmen.
  • Folgende Argumente können dem Team nähergebracht werden:
    • Wenn nur ein Fehler oder ein Konflikt in stressigen Zeiten vermieden werden kann, so kann dies viel mehr Zeit sparen, als das abhalten der Retrospektive kostet.
    • Gerade in stressigeren Zeiten ist oft auch das Konfliktpotenzial höher, also ist das Abhalten der Retrospektive auf jeden Fall wichtig.

4. Retrospektive die entbehrliche Pufferzeit

Beschreibung des Antipatterns:

  • Dieses Antipattern ist ähnlich zu dem Antipattern „Auf den nächsten Sprint verschieben“, es unterscheidet sich allerdings im Mindset der betroffenen Akteure. Während beim oberen Antipattern das Team an der Wichtigkeit der Retrospektive zweifelt, wird hier die Retrospektive als Pufferzeit verwendet.
  • Meist wird bei einem derartigen Antipattern der Sprint bis zur letzten Minute verplant, um Output zu generieren. (Outputfokus)

Warum ist das schlecht?

  • Wer ein derartiges Puffermindset hat, macht einiges im Sinne von Scrum falsch. Ein Sprint ist kein Projekt, welches bis auf die letzte Minute durchgeplant wird und die Retrospektive hat einen wertvollen Sinn. Hier liegt der Verdacht nahe, dass das Team sehr Output getrieben und weniger Outcome fokussiert ist.
  • Wird keine Retrospektive gemacht, so kann das Team nie etwas an diesen Fehlern ändern.
  • Weiters ist dieses Antipattern ein starkes Indiz dafür, dass das Team die grundlegenden Bausteine von Scrum und vom agilen Arbeiten nicht verstanden hat, vor allem, was die zwei Aspekte empirisches Arbeiten und kontinuierliche Verbesserung angeht. Im schlimmsten Fall wird also wasserfallartig gearbeitet und ein Produkt entwickelt, welches am Markt keine Zustimmung und Abnahme findet.

Verbesserungen:

  • Zunächst muss der Scrum-Master herausfinden, wo dieses Mindset herkommt und wie weit Scrum und das Schaffen von Outcome im Team verankert ist.
  • Das Team muss verstehen, dass Output generieren nicht das Ziel ist.
  • Der Scrum-Master muss beim Team ein Verständnis für die agilen Vorgehensmethoden und das empirische Arbeiten schaffen.
  • Es muss jedem im Team klar sein, warum es eine schlechte Idee ist, die Retrospektive ausfallen zu lassen.
  • So kann es auch hilfreich sein, die Retrospektive ans absolute Ende des Sprints zu legen, also nach dem Review. Das ist ohnehin eine gute Idee, weil dadurch auch das Review in der Retrospektive besser inspiziert, diskutiert und verbessert werden kann.
  • Durch das Wegfallen der „Pufferzeit“ kann es auch sein, dass das Team die Sprintziele nicht mehr gut erreicht. Dann ist dies die perfekte Gelegenheit, diese Situation zu inspizieren und herauszufinden, was im Sprint schief läuft und was verbessert werden kann.

5. Übereilte Retrospektive

Beschreibung des Antipatterns:

  • Bei der übereilten Retrospektive nimmt sich das Team nicht genügend Zeit für eine ordentliche Reflexion, um den nächsten Sprint und die Arbeit des Teams zu verbessern.
  • Entweder wird das Meeting gleich nur sehr kurz geplant, oder die Mitglieder verhalten sich sehr kurz angebunden und wollen eigentlich gar keine Retrospektive machen, um schnell an neuen Themen weiterarbeiten zu können.
  • Oft wird das Meeting auch aktiv von einem oder mehreren Mitgliedern kurzgehalten, indem Suggestivfragen gestellt werden wie „Es gibt nichts zu besprechen, oder?“ oder „Es ist doch alles OK, oder?“

Warum ist das schlecht?

  • Wer die Retrospektive übereilt, der kann am Ende des Tages mit großem Mehraufwand abgestraft werden. Nämlich genau dann, (1) wenn wichtige Dinge nicht besprochen werden, (2) das Team ineffizient arbeitet oder (3) es Konflikte im Team gibt, die nicht besprochen werden.
  • Oftmals wird in der Retrospektive dieser Druck aufgebaut, weil das Projekt oder die Entwicklung in einer sehr stressigen heißen Phase ist und Zeit gerade besonders kostbar ist.
  • Doch genau dann sollte nicht bei der Retrospektive gespart werden, weil es genau diese Phasen sind, in denen Fehler passieren und das Team besonders belastet ist. Durch diese Belastung kann es zu Konflikten kommen und diese kosten oft extrem viel Zeit.
  • Des Weiteren sollte immer beachtet werden, dass dieses Verhalten schnell dazu führt, das die gesamte Retrospektive an Mehrwert verliert und dadurch auch immer weniger gerne von den Teammitgliedern gemacht wird.

Verbesserungen:

  • Der Scrum Master kann, gerade wenn er mitbekommt, dass extremer Zeitdruck auf dem Team liegt, versuchen eine Atmosphäre des Ankommens und der Entschleunigung zu schaffen.
  • Es sollte darauf geachtet werden, dass für die Retrospektive genügend Zeit eingeplant wird und auch wirklich jeder im Team teilnehmen kann.
  • Es kann auch helfen, eine strukturierte Retrospektive durchzuführen, welche immer nach dem selben Schema abgehalten wird. Dazu kann beispielsweise die DAKI Methode (Drop, Add, Keep, Improve) verwendet werden.
  • Unterstützend kann auch ein Moderator (oft der Scrum-Master) oder die Verwendung eines Tools dabei helfen, das Meeting mit Mehrwert für alle abzuhalten und nichts zu überstürzen.

6. Gebrochene Las Vegas Regel

Beschreibung des Antipatterns:

  • Was in Las Vegas passiert, bleibt in Las Vegas – das selbe gilt für die Retro! Bei diesem Antipattern verrät ein Teammitglied sensible Informationen an jemanden Außenstehenden wie beispielsweise einen Linienmanager, anderen Mitarbeiter oder einen anderen Vorgesetzten.

Warum ist das schlecht?

  • Bei der Retrospektive werden teilweise sehr persönliche und sensible Dinge besprochen, es werden beispielsweise Konflikte, die im Team vorherrschen, diskutiert und behoben.
  • Für diese Art von Informationen müssen sich alle Teammitglieder öffnen können und dementsprechend ein Vertrauen haben, dass sie sich öffnen können.
  • Besteht kein Vertrauen, oder ist dieses verletzt, werden keine Konflikte angesprochen und können somit nicht behoben werden. Dies kann dann wiederum zu einer verminderten Leistung des Teams führen, weil Probleme und Konflikte viel Zeit und Energie brauchen.
  • Außerdem lässt es das Team unprofessionell und inkompetent erscheinen, wenn Konflikte nach außen dringen. Das wiederum kann dazu führen, dass Stakeholder wie beispielsweise Linienmanager ins Projekt eingreifen und somit Konflikte verstärken und die Leistung weiter minimieren. (Es kann natürlich vom Team aktiv beschlossen werden, dass Linienmanager eingeschaltet werden und dies kann eine sehr effiziente Möglichkeit sein, mit Konflikten umzugehen, es ist aber entscheidend, dass das Team diese Entscheidung von sich aus trifft.)

Verbesserungen:

  • Vorbeugung ist die hier beste Variante, mit dem Antipattern umzugehen, denn dieses Antipattern zu vermeiden ist einfacher, als im Nachhinein den Brand zu löschen. Zunächst muss also sichergestellt werden, dass jeder weiß, dass nichts unkoordiniert aus der Retrospektive nach außen an Dritte dringen soll.
  • Dazu ist es am besten, die Regeln für die Retrospektive in einem gemeinsamen Retrospektiven-Meeting zu erfassen und allgemein zugänglich zu machen. Wenn es das Team will, kann es diese symbolisch auch unterschreiben, um dem Ganzen mehr Bedeutung zuzuweisen.
  • Neue Teammitglieder müssen auf diese Regeln noch vor der ersten Retrospektive aufmerksam gemacht werden.
  • Sollte es aus welchem Grund auch immer wirklich dazu gekommen sein, dass jemand Informationen nach Außen getragen hat, so muss dies unbedingt sofort, oder spätestens bei der nächsten Retrospektive angesprochen werden und unterbunden werden.
  • Ist ein Schaden entstanden, sollte der Scrum-Master als Moderator und Mediator versuchen, alle Beteiligten an einem Tisch zu bekommen und darüber zu reden.

7. Das Team in der Opferrolle

Beschreibung des Antipatterns:

  • Das Team nutzt die Retrospektive nicht, um etwas zu verbessern, sondern nur, um über die aktuelle Situation zu jammern und Ausflüchte zu finden, warum andere für alles Schlechte verantwortlich sind und sie nichts daran ändern können.
  • Das Team setzt sich somit bequem in die Opferrolle und ergreift die Opposition bei vielen Punkte.

Warum ist das schlecht?

  • Wird in der Retrospektive immer nur gejammert und nichts geändert, so geht das Meeting am Sinn und Zweck vorbei.
  • Dadurch wird die Stimmung des gesamten Teams hinuntergezogen und die Produktivität leidet extrem unter diesem Mindset.
  • Wer sich nur in der Opferrolle sieht und andere für dieses Schicksal verantwortlich macht, wird nie etwas an der Situation ändern können.

Verbesserungen:

  • Der Scrum-Master sollte das Team in die Verantwortung ziehen und darauf achten, dass bei jeder Retrospektive klare Action-Items identifiziert werden, die das Team umsetzen muss.
  • Es müssen klare Aufgaben und Verbesserungen aufgeschrieben und im Sprint verplant werden.
  • Am besten managed und moderiert der Scrum-Master auch die Diskussion und dreht negative Gespräche ab und stellt gewisse Schwerpunkte zur Diskussion.
  • Beispielfragen: „Wie habt ihr das Planning empfunden und was können wir daran verbessern?“ „Woran ist es gelegen, dass wir mit Ticket XY nicht so effizient waren und dies nicht abschließen konnten?“,…
  • Es können auch strukturiert Retrospektiven-Methoden wie die DAKI-Methode eingesetzt werden, bei denen jedes Teammitglied Positives, Negatives und Verbesserungen sucht und daraus dann 2-3 Action-Items fürs Team abgeleitet werden.
  • Positives und negatives Feedback kann auch damit gesteuert werden, indem jedes Teammitglied nur fünf grüne und fünf rote Karten bekommt, auf denen positive und negative Ereignisse des letzten Sprints aufgeschrieben werden können.

8. Action-Items sind nicht SMART

Beschreibung des Antipatterns:

  • Die vom Team gesetzten Action-Items erfüllen die SMART Regel nicht.
  • Bill Wake hat in seinem Artikel 2003 die Akronyme INVEST und SMART begründet.1
  • SMART steht für S-Spezifisch M-Messbar, A-Achievable (erreichbar) R-Relevant, T-Time-Boxed.
  • Somit befriedigen die Action-Items einen oder mehrere dieser Punkte der SMART-Regel nicht. Beispiele: Es ist nicht spezifisch genug beschrieben, was zu tun ist, oder die Ergebnisse sind nicht messbar oder erreichbar, oder die Aufgabe ist nicht relevant oder zeitlich nicht gesetzt und somit offen.

Warum ist das schlecht?

  • Werden keine konkreten Vorhaben in der Retrospektive vereinbart, bleiben die Verbesserungen meinst unerledigt.
  • Wenn keine Verbesserungen gemacht werden, ist die in die Retrospektive investierte Zeit nicht mehr so wertvoll und der Mehrwert für das Team und das Projekt schwindet.
  • Zu wenig Mehrwert wiederum kann dazu führen, dass andere Antipattern im Bezug auf die Retrospektive entstehen oder das Team die Retrospektive gleich gar nicht mehr machen möchte.
  • Werden keine Verbesserungen im Projekt gemacht, kann dies auch kritisch für den Projekterfolg werden und letzten Endes zu Mehrkosten und dem Projektabbruch führen.

Verbesserungen:

  • Das Team sollte die Action-Items zusätzlich zum Backlog führen. Einige Teams führen auch gerne die Action-Items im Backlog des Sprints oder dem Product-Backlog mit.
  • Dabei sollten die Action-Items auch einen gewissen Mindeststandard erfüllen, den sich das Team vorab wie die Definition of Ready gemeinsam überlegt, schriftlich festhält und verwendet. Das Mindestmaß sollte dabei die Erfüllung der SMART-Regel sein.

1https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

9. Keine Verantwortlichen und keine Verbindlichkeit

Beschreibung des Antipatterns:

  • Bei diesem Antipattern werden zwar die Action-Items identifiziert, sauber erfasst und die Umsetzung geplant. Das Team committet sich sogar auf die Umsetzung. Doch die Action-Items werden dennoch nicht umgesetzt.
  • Es fühlt sich keiner für die Umsetzung direkt verantwortlich und jeder denkt, ein anderes Teammitglied soll das Action-Item umsetzen.
  • Denn die Umsetzung von Action-Items aus der Retrospektive ist meist nicht so spannend wie die Implementierung neuer Features für das Produkt.

Warum ist das schlecht?

  • Wurden Action-Items in den Sprint eingeplant und hat sich das Team darauf committet, so wurde bereits viel Energie in die ganze Organisation des Action-Items gesteckt. Ein Investment, das sich also auszahlen soll. Das Team hat entschieden, dass es das Action-Item braucht, um effizienter und besser zu werden. Daher wäre eine möglichst rasche Umsetzung viel sinnvollen, weil dann die positiven Effekte früher eintreten und die Verbesserungen früher stattfinden. Setzt sie das Team nicht oder später um, finden diese Verbesserungen nicht statt und es entstehen mehr und mehr Kosten.
  • Dies wiederum verzögert das Projekt und lässt die Probleme nur größer werden.

Verbesserungen:

  • Damit sich das Investment rentiert, sollten Action-Items möglichst schnell umgesetzt werden.
  • Um Missverständnisse und Spielräume für das Aufschieben der Action-Items zu minimieren, empfiehlt es sich, diese gleich in der Sprint-Planung einzelnen Teammitglieder zuzuweisen.
  • Diese sind dann für die Umsetzung hauptverantwortlich, müssen die Action-Items jedoch nicht im Alleingang umsetzen, sondern lediglich die Umsetzung koordinieren und dafür eintreten, dass diese auch wirklich umgesetzt werden.

10. Kein Abschließen von Action-Items

Beschreibung des Antipatterns:

  • Das Team bespricht nicht die Umsetzung der Action-Items des vergangenen Sprints und schließt diese nicht gemeinsam in der Retrospektive ab.

Warum ist das schlecht?

  • Werden die Action-Items des vergangenen Sprints nicht gemeinsam abgeschlossen, so kann es schnell passieren, dass die Motivation des Teams, neue Action-Items umzusetzen, langsam schwindet.
  • Fehlt die Anerkennung des Teams für die getane Arbeit, so kann dies auch sehr schnell negative Konsequenzen haben. Es kann dann sein, dass sich beim nächsten Sprint niemand mehr findet, der neue Action-Items umsetzen möchte.
  • Wird die Umsetzung der Action-Items außerdem nicht besprochen und vom Team noch einmal reviewed und somit die Ergebnisse und Effekte, die die Umsetzung gebracht hat, nicht reflektiert, so kann es sein, dass Fehler, die bei der Umsetzung entstanden sind, nicht auffallen und gewünschte Effekte nicht eintreten.

Verbesserungen:

  • Zu Beginn einer jeden Retrospektive sollte das Team die alten umgesetzten Action-Items auf ihre Umsetzung und die eingetretenen Effekte untersuchen.
  • Sind die erhofften positiven Effekte eingetreten?
  • Wurde die Umsetzung auch richtig gemacht?
  • Wo viel Selbstorganisation herrscht, muss auch die gemeinsame gegenseitige Kontrolle gelebt werden, nur so entstehen auch Verbindlichkeiten und kann eine gewisse Qualität garantiert werden.
  • Wenn die Effekte eines Action-Items nicht spürbar sind und nicht nochmal diskutiert werden, dann ist fraglich, warum die Umsetzung überhaupt zu Beginn notwendig war. Daher sollte das Team immer über die jeweiligen Effekte reflektieren und wenn nötig nachbessern.

Referenzen

1 https://www.quarks.de/gesellschaft/psychologie/warum-wir-uns-oft-selbst-ueberschaetzen/

2 https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Mehr agile Antipattern und Scrum Antipattern lesen Sie im Buch „100+ agile Antipattern“

100+ agile Antipattern – Ein Rezept, um jedes agile Projekt zum Scheitern zu bringen (oder zu retten) ab € 9,99 auf Amazon kaufen (affiliate-Link)

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

Create a website or blog at WordPress.com

Nach oben ↑

%d Bloggern gefällt das: