Software-Engineering Pattern und Antipattern: Sprint-Antipattern (Teil 2)

Inhalt:

  1. Kein Work-In-Progress Limit
  2. Cherry-Picking
  3. Nicht aktuelle Sprint-Boards
  4. Side-Gigs
  5. Goldplating
  6. Laufende Arbeitsunterbrechungen
  7. Fehlende Unterstützung
  8. Task-Assignments

Beschreibung des Antipatterns:

  • Das Entwicklungsteam setzt kein Work-In-Progress Limit und öffnet mehrere größere Features gleichzeitig.

Warum ist das schlecht?

  • Arbeitet das Team an zu vielen PBIs gleichzeitig im Sprint besteht die Gefahr, dass am Sprintende keine/zu wenige PBIs fertig sind, oder zu viele PBIs in einen halb fertigen zustand sind.
  • Es kommt außerdem zu Multitasking und vielen Reibungsverlusten, wenn zu viele PBIs gleichzeitig offen sind und die Entwickler zwischen die offenen PBIs hin und her wechseln. Denn oft bestehen Abhängigkeiten zwischen den PBIs und den Entwicklern die sie umsetzen.
  • Des weiteren wird die Fertigstellung der Produkt-Inkremente gefährdet, weil Tickets in den nächsten Sprint gezogen werden und somit nie ein Status erreicht wird bei dem die Tickets im Sprint abgeschlossen und ein potenziell auslieferbares Inkrement erzeugt wird.
  • Erhöht sich die Anzahl der PBIs die gerade bearbeitet werden, so lässt sich automatisch auch eine Erhöhung der Cycle-Time der einzelnen PBIs feststellen. Dies wiederum widerspricht der bestmöglichen Agilität, macht das Team unflexibel und verlangsamt alles.

Verbesserungen:

  • Das Team sollte ein Work-In-Progress Limit (= WIP-Limit)setzen welches klein gleich der Anzahl der Team-Mitglieder ist.
  • Im Normalfall hat sich eine deutlich kleinere Anzahl an WIP als praktikabel herausgestellt. Weil das Team meist gemeinsam an Tickets arbeitet und zumindest die Arbeit gegenseitig reviewn muss. Zu beachten ist jedoch, dass die Anzahl der Ticket die im Sprint aktiv bearbeitet werden müssen (also das WIP-Limit) abhängig ist von der generellen Granularität der PBIs, die das Team in seinem Backlog pflegt. Dies kann von Team zu Team und von Projekt zu Projekt stark unterschiedlich sein.
  • Es ist die Aufgabe des Scrum-Masters, darauf zu achten dass das Team ein WIP-Limit setzt und dieses auch einhält.
  • Da das WIP Limit nicht generell in allen Projekten gleich ist, muss das Team in den Ersten Sprints aufgrund von Erfahrungswerten ein WIP-Limit setzen und in den laufenden Sprint-Reviews und Sprint-Retrospektiven dieses Monitoren und ggf. anpassen.
  • Auch der Product-Owner ist stark daran interessiert, ein WIP-Limit zu haben, denn dies garantiert, dass die Cycle-Time der PBIs nicht zu groß werden. Es ist für den PO und das Team besser, wenn lieber einige wenige Features im Sprint ganz umgesetzt werden, als dass viele Features halb umgesetzt sind.

Beschreibung des Antipatterns:

  • Das Umsetzungsteam oder einzelne Software-Engineers suchen sich nur jene PBIs zum Umsetzen aus, die sie selbst am lustigsten interessantesten finden, allen anderen Tickets lassen sie das Team erledigen.
  • Oftmals wird den Team-Kollegen nicht geholfen sondern an seinem eigenen Task weiter gearbeitet. Der Grund für die Ablehnung dieser Hilfe ist dann meist dass die eigene Arbeit gerade wichtiger ist.
  • Zu Gunsten neuer Feature und lustiger Implementierungstask werden auf der anderen seite nicht so lustige aufgaben wie das schreiben von Testfällen, das Testen oder das Dokumentieren vernachlässigt oder hinten angestellt.

Warum ist das Schlecht?

  • Menschen sind sehr anfällig für schnelle Belohnungen. Aus diesem Grund fühlt es sich so gut an ein Feature fertig zu bauen. Ein Sprint ist aber ein Mikroprojekt, welches alle Phasen eines herkömmlichen, großen Projekts beinhaltet. Es kann daher nicht einfach gesagt werden: „Ich mache meine lustigen Entwicklungs-Tasks und das Testen, Dokumentieren und Releasen soll jemand anderer machen.“ Es werden sonst wichtige Aufgaben die es braucht um einen erfolgreichen Sprint-Abschluss hin zu bekommen vernachlässigt. Das Sprint-Ziel wird gefährdet.
  • Wenn sich nur einige wenige Teammitglieder immer das herausnehmen was sie wollen müssen anderer die nicht so lustigen Dinge machen. Dies gefährdet den Team-Spirit und führt zu Spannungen im Team. Konflikte können entstehen, vor sich hin schwelen und ausbrechen.
  • Sprintziele und Qualitätsziele werden ggf. nicht erreicht.
  • Meist lässt sich, wenn Teams diese Spannungen haben und Cherry-Picking betrieben wird, erkennen, dass das Team nicht vollständig selbst organisiert ist oder es bei der Selbstorganisation Schwierigkeiten gibt
  • Oft entsteht auch innerhalb eines Sprints mit Cherry-Picking- Teammitgliedern ein Rückstau an Tickets. Bei denen sich Ticket um Ticket in der Umsetzung befinden aber keines fertig wird. Das ist dann meist auf fehlende Reviews oder ähnliches zurückzuführen. Die Ursache ist aber nicht fehlende Zeit sondern ein Fehlverhalten von Team-Kollegen die nicht gewillt sind Reviews und Dokumentationen abzuschließen.

Verbesserungen:

  • Der Scrum-Master sollte das Team beobachten und Coachen wie es die Arbeit im Team am besten koordinieren kann. Dabei sollte der Scrum-Master nicht selbst die Arbeit verteilen sondern das Team auf das Problem aufmerksam machen und zu einer Lösung bringen.
  • Es muss dem gesamten Team bewusst sein, dass alle arbeiten im Sprint erledigt werden müssen und jeder im Team seinen Beitrag leisten muss.
  • Die Shared-Ownership des Teams und somit die Verantwortung des Teams für die gesamte Leistung muss jedem bewusst sein.
  • Sollten Konflikte entstehen oder entstanden sein so muss der Scrum-Master dem Team helfen eine Lösung für diese Konflikte zu finden. Hier muss Moderiert werden und versucht werden dass jeder gehört und ernst genommen wird.
  • Ein guter Ort um das Thema anzusprechen ist auch die Retrospektive. Hier haben sowohl unzufriedene Team-Kollegen als auch der Scrum-Master die Gelegenheit das negative Verhalten konstruktiv anzusprechen und Verbesserungen zu suchen.

Beschreibung des Antipatterns:

  • Das Team wartet das Sprint-Board nicht ausreichend während des Sprints, und somit befinden sich Tickets im Board im falschen Status und zeigen die falsche verbleibende Zeit an.

Warum ist das Schlecht?

  • Das Sprint-Board gehört voll und ganz dem Team, es dient einerseits der Selbstorganisation des Teams, ist aber andererseits „öffentlich“ den Stakeholdern sowie dem Product-Owner zugänglich. Ist das Board nicht gepflegt schadet es also automatisch der Selbstorganisation und der Reputation des Teams.
  • Stakeholder und Product-Owner können verwirrt sein und letzten Endes auch das Vertrauen in das Team verlieren.
  • Ist kein vertrauen mehr seitens der Stakeholder oder des Product-Owners da, so werden diese Gegenmaßnahmen ergreifen, um das Chaos zu managen.
  • Ist das Board nicht gepflegt und fallen dann beispielsweise Kollegen z.B. krankheitsbedingt aus, so muss sich das Team mühsam einarbeiten und herausfinden wo der letzte stand war und in welchen Status sich ein PBI eigentlich befindet.
  • Es ist auch zu bedenken, dass moderne agile Tools wie Jira oder Microsoft Azure-DevOps auch Charts wie beispielsweise Burndown-Charts erstellen. Werden die Tickets nicht gewartet und der Restaufwand nicht täglich aktualisiert so werden die Charts auch dementsprechend schlecht aussehen. Dies kann für noch mehr Verunsicherung bei den Stakeholdern und den Product-Owner führen.

Verbesserungen:

  • das Team sollte sich zumindest einmal täglich daran machen das Board zu aktualisieren.
  • Besser ist es wenn jedes PBI im Sprint den aktuellen Stand in dem es sich befindet widerspiegelt.
  • Vor dem Standup sollten alle PBIs an denen ein Teammitglied arbeitet in den aktuellen Status gebracht werden.
  • Zumindest vor dem Ende des Arbeitstages sollten das Sprint-Board ebenfalls aktualisiert werden, um automatisierte Charts zu ermöglichen.
  • Sollte der Scrum-Master über einen längeren Zeitraum wahrnehmen, dass das Team das Board nicht wartet so muss er mit dem Team über die etwaigen Konsequenzen sprechen und das Team coachen dies zukünftig zu machen.

Beschreibung des Antipatterns:

  • Bei einem Side-Gig arbeiten ein oder mehrere Teammitglieder an Themen die nicht im Sprint geplant und somit auch nicht im Sprintbacklog/Sprintboard sichtbar sind.

Warum ist das schlecht?

  • Wenn ein oder mehrere Teammitglieder an Themen arbeiten, die nicht mit dem Product-Owner geplant wurden, dann führt dies zu mehreren Problemen, denn einerseits können die Teammitglieder dann nicht an den eigentlich geplanten PBIs arbeiten, andererseits investieren Zeit in etwas, was nicht durch den Product-Owner erfasst und geplant wurde. Der Product-Owner ist aber für den Business-Value und letzten Endes für den Return on Investement des Produkts verantwortlich.
  • Eine weitere Frage ist, warum die Teammitglieder die, scheinbar sehr wichtigen Aufgaben nicht in erster Linie mit dem Product-Owner im Sprintplanning besprochen haben. Es kann sein dass dies ein Zeichen von schlechter Kommunikation oder Misstrauen ist, welches unbedingt gelöst gehört.
  • Ein weiteres Problem an Side-Gigs kann darin liegen, dass diese nicht im Standup besprochen sonder eher verschleiert werden. Dies führt unweigerlich dazu dass ausreden und Verschleierungstaktiken verwendet werden. Werden diese aufgedeckt kann dies zu massiven Vertrauensverlust führen.

Verbesserungen:

  • Sobald einem anderen Teammitglied, dem Product-Owner oder dem Scrum-Master der Umstand bewusst wird, dass einige Teammitglieder an anderen Themen arbeiten, muss dies im Team besprochen werden.
  • Zunächst gilt es zu hinterfragen was für Nebenthemen gerade erarbeitet werden, und welchen Zweck diese erfüllen.
  • Sind diese Nebenthemen wirklich wichtig, so ist zu klären warum diese nicht mit dem gesamten Scrum-Team besprochen wurden, sonder auf eigene Faust angefangen wurden, und ob diese weiter geführt werden sollen oder nicht.
  • Wurden die Nebenthemen als eher unwichtig eingestuft, so sollten diese unverzüglich eingestellt werden. Die Side-Gig Team-Kollegen sollten wieder an PBIs arbeiten die auf dem Sprintboard stehen und somit zum Sprintziel führen.
  • Sollte ein Misstrauensverhältnis zwischen einzelnen Teammitgliedern und dem Product-Owner bestehen, so sollte der Scrum-Master versuchen hier zu Coachen und das Team enger zusammen zu bringen.

Beschreibung des Antipattern:

  • Beim Goldplating erweitert ein Teammitglied die angestrebte Umsetzung eines Features um weitere oftmals unnötige unerwünschte Details, ohne dies zuvor mit dem Team und den Product-Owner zu besprechen. Die geplante Funktionalität wird um ein vielfaches übertroffen. Es wird mehr und mehr Zeit in Erweiterungen und Detaillierungen des Features gesteckt und kein Ende der Arbeiten gefunden.
  • Dabei wird Goldplating oft unbewusst von einem oder mehreren Teammitgliedern betrieben.
  • Die Umsetzung schießt also über das Ziel hinaus.

Warum ist das schlecht?

  • Goldplating ist schlecht weil mehr Zeit und somit Budget für Features und Featuredetails benötigt wird als ursprünglich angenommen.
  • Zudem wird der Product-Owner darüber nicht informiert oder um Erlaubnis gefragt was dazu führt, dass gegebenenfalls die Produkt-Strategie und Kostenplanung nicht mehr funktioniert.
  • Durch die zu viel investierte Zeit in das eine PBI, ist automatisch auch weniger Zeit im Sprint für alle Anderen PBIs vorhanden. Dies führt auch dazu, dass das Sprintziel bedroht wird und ggf. nicht eingehalten werden kann.
  • Nicht Eingehaltene Sprintziele und fehlende Features führen auch unweigerlich zu fragen und misstrauen der Stakeholder, das Umsetzungsteam und der Product-Owner kommen unter Druck.

Verbesserungen:

  • Goldplating kann am einfachsten erkannt werden indem im Sprintplanning solide Schätzungen gemacht werden und im Team ein Bewusstsein für Minimal Viable Products und die Probleme die durch Goldplating entstehen vorherrscht.
  • Des Weiteren empfiehlt es sich ein Burndown-Chart zu führen und die Remaining-Work immer im Auge zu halten. Brennt die Remaining-Work nicht konstant runter, und erzählen einzelne Teammember Tag für Tag im Standup vom selben PBI, so ist es möglich. dass hier gerade Goldplating betrieben wird.
  • Liegt der Verdacht von Goldplating nahe, so sollte der Product-Owner und/oder der Scrum-Master beim Teammitglied nachfragen, was die Herausforderungen und Probleme beim der Umsetzung des PBIs sind.
  • Im Team sollte regelmäßig in der Sprintplanung und im Refinement betont werden dass es nicht sinnvoll ist ein PBI eigenmächtig zu erweitern. Statt dessen sollten die Teammitglieder Ideen und Erweiterungen als Feature-Ideen im Backlog anlegen oder ihren Product-Owner übergeben.
  • Es ist auch sinnvoll, dass sich Team-Mitglieder regelmäßig Feedback zur Umsetzung vom Product-Owner einholen. Die Kommunikation zwischen Product-Owner und Team muss gut funktionieren, um derartige Fehlallokationen von Ressourcen zu vermeiden
  • Um die Kommunikation zu unterstützen sollte der Product-Owner und das Team nicht räumlich getrennt sein.

Beschreibung des Antipattern:

  • Es passiert immer wieder, dass das Umsetzungsteam im laufenden Sprint von Stakeholdern (wie beispielsweise Vorgesetzten, Marketing, Vertrieb, Backoffice etc.) unterbrochen wird und kleinere Aufgaben abseits der eigentlichen Projektarbeit durchführen muss.
  • Der Scrum-Master beschützt das Team nicht ausreichend genug vor fremden Einflüssen von außen.
  • Meist hat der Scrum-Master zu diesen Unterbrechungen eine zu lockere Grundhaltung, oder denkt sich, dass das Team sich selbst wehren kann und soll.
  • Es kann auch sein dass der Scrum-Master zu weit weg vom Team und der Umsetzung ist und daher diese Unterbrechungen überhaupt nicht mitbekommt.

Warum ist das schlecht?

  • Wird das Team von außen unterbrochen so führt das unmittelbar und unweigerlich zu einem Verlust von Umsetzungskapazität.
  • Wenn dann noch zusätzliche Arbeiten an einzelne Team-Mitglieder oder sogar das gesamte Team verteilt werden, dann wird das Sprintziel gefährdet und der ursprüngliche Plan kann nicht eingehalten werden. Es werden gegebenenfalls einige PBIs nicht umgesetzt, die für den Product-Owner und die User aber wichtig wären.
  • Zu diesen Verzögerungen kommen aber noch weitere Effekte hinzu. So kommt es beispielsweise durch zusätzliche Aufgaben unweigerlich zum Multitasking und damit zu weiteren Reibungsverlusten in der Umsetzungskapazität.
  • Das Team wird außerdem sehr stark beansprucht und unter Druck gesetzt. Denn es muss nun mehrere Ziele verfolgen und mehrere Stakeholder glücklich machen, obwohl zu wenig Zeit bleibt.
  • Das alles tritt dann in Kombination mit der Enttäuschung des Teams gegenüber dem Scrum-Master auf. So können zwischenmenschliche Spannungen zwischen dem Scrum-Master und dem Umsetzungsteam entstehen.

Verbesserungen:

  • Um hier gezielt Verbesserungen erarbeiten zu können, muss zunächst geklärt werden, warum der Scrum-Master das Team nicht beschützt. Kann er das Team nicht beschützen, weil er beispielsweise nicht in der nähe des Teams ist, Organisatorisch overruled wird, oder die Unterbrechungen einfach nicht mitbekommt, oder will er nicht an dieser Situation ändern.
  • Wenn der Scrum-Master das Team nicht beschützen will, weil er dies nicht als seine Aufgabe sieht, so muss das Team diesen Umstand schnellst möglich mit dem Scrum-Master bei einer Retrospektive oder einem Separaten Meeting besprechen. Es gehört zu den Kernaufgaben eines Scrum-Masters sein Team und den Scrum-Prozess vor negativen einfüllen zu schützen.
  • Gegebenenfalls ist dem Scrum-Master auch nicht bewusst dass diese Arbeitsunterbrechungen dem Team sehr viel Mühe und Kopfzerbrechen bescheren. Hier lohnt es sich für Verständnis und Empathie zu sorgen.
  • Oft tritt dieses Antipattern jedoch auf, ohne dass der Scrum-Master etwas von diesen Unterbrechungen mitbekommt. Dies kann beispielsweise an einer räumlichen Trennung zwischen Team und Scrum-Master liegen. Eine Verbesserung wäre also hier die räumliche Nähe zu suchen und die Büros zusammen zu legen.
  • Oder der Scrum-Master ist zu distanziert und zu wenig integriert in den Umsetzungsprozess. In diesem Fall muss der Scrum-Master intensiver in Standup-Meetings integriert werden und den Umsetzungsprozess mehr begleiten und öfter bei einzelnen Team-Kollegen nachfragen wie es ihnen geht.
  • Ein weiterer wichtiger Aspekt liegt in der Beobachtung der Remaining-Work und des Burndown-Chats. Brennt dieses nicht hinunter kann dies daran liegen, dass Teammitglieder zu oft unterbrochen werden oder andere kleine Aufgaben erledigen müssen.
  • Sollte der Scrum-Master von Linienmanagern des Teams overruled werden so sollte dies auf jeden Fall Dokumentiert und abgewogen werden. Kommt diese Unterbrechung nur sehr selten und hat gute Gründe, so wird höchstwarscheinlich die Ausnahme die Regel bestätigen und dieser Umstand vom Scrum-Master und vom Team toleriert werden. Kommt dies jedoch öfter vor und sind die Unterbrechungen vom Team nicht nachvollziehbar, so muss sich der Scrum-Master jedoch klar positionieren und Linienmanagern die grenzen aufzeigen. Ein guter Scrum-Master kann dies jedoch mit Diplomatie und der Werbung um Verständnis sehr gut lösen.
  • Wichtig ist es auch, dass das Team das Gefühl hat sich auf den Scrum-Master verlassen zu können.
  • Werden dennoch ungeplante Aufgaben notwendig, so muss das Team dafür sorge tragen, dass am Sprint-Ende die Veränderung der Kapazität dokumentiert wird und der Product-Owner rechtzeitig darüber informiert wird, dass gegebenenfalls einige Tickets nicht fertig werden und das Sprint-Ziel in Gefahr ist. So kann sich der Product-Owner auf die neuen Gegebenheiten einstellen und gegebenenfalls seinen Plan anpassen.

Beschreibung des Antipattern:

  • Der Scrum-Master unterstützt einzelne Teammitglieder nicht ausreichend, wenn diese Probleme bei der Umsetzung haben.
  • Ein Teammitglied hängt schon länger bei einem Problem in der Umsetzung. Doch weder die Teamkollegen noch der Scrum-Master helfen bei der Lösung dieses Problems.
  • Das Teammitglied ist aber leider auch zu schüchtern oder gehemmt um nach Hilfe zu fragen. Stattdessen wird Tag um Tag versucht das Problem auf eigene Faust zu lösen.

Warum ist das schlecht?

  • Wird einem Teammitglied nicht geholfen, so gehen viel Zeit und Ressourcen verloren.
  • Hat ein Teammitglied ein Problem und niemand hilft ihm so ist dies nicht nur für das einzelne Teammitglied schlecht, sondern sogar für da Sprintziel, denn die Umsetzungskapazität wird dementsprechend weniger und somit bleiben gegebenenfalls PBIs auf der Strecke.
  • Wenn Sprintziele nicht erreicht werden führt dies allerdings wieder zu Problemen für den Product-Owner und lässt das gesamte Team schlecht da stehen. Allein dieser Grund sollte dem Teammitglieder klar gemacht werden, und somit Hemmschuhe und Schüchternheit verhindern. Es macht schlichtweg keinen Sinn nicht um Hilfe zu bitten.
  • Ein weiterer wichtiger Aspekt, warum es sinnvoll ist lieber einmal mehr zu Kommunizieren und um Hilfe zu bitten ist, dass einige aufgaben für Teammitglieder sehr leicht zum lösen sind, während andere sich bedeutend schwerer dabei tun. Das Team ist aber dazu angehalten möglichst effizient zu arbeiten.

Verbesserungen:

  • Zunächst muss geklärt werden, warum das Teammitglied nicht um Hilfe gefragt hat und warum es auch keinen aufgefallen ist dass jemand im Team sichtlich Probleme hat und an einer Aufgabe hängt.
  • Es muss allen Teammitgliedern klar gemacht werden dass es die gemeinsam getragenen Verantwortung aller ist, effizient zu arbeiten und gemeinsam Sprintziele zu erreichen.
  • Es kann sein, dass das Team das Standup nicht richtig lebt und Probleme und Hindernisse nicht richtig besprochen werden. Der Scrum-Master sollte im Standup regelmäßig Teilnehmen und dem Team dabei helfen sich besser selbst zu organisieren.
  • Insgesamt sollte das Team sich aber alleine gegenseitig helfen können. Ist das nicht der Fall, so ist es die Aufgabe des Scrum-Masters dafür zu sorgen Hindernisse und Probleme aus der Welt zu schaffen.
  • Ein wichtiges Instrument um Festzustellen ob jemand bei einem Ticket hängt und ob es wo Probleme gibt ist neben dem Standup auch das Burndownchart und die Remaining-Work. Brennt das Burndown nicht ordentlich hinunter, so kann es sein, dass ein Teammitglied Hilfe benötigt.
  • Durch das Bitten um Hilfe und die angebotene Hilfeleistung ist die Lernkurve bei demjenigen dem geholfen wird auch sehr steil. Es wird somit Wissen ausgetauscht und im Team verteilt, was wiederum zu mehr Flexibilität und Effizienz führt.

Beschreibung des Antipatterns:

  • Der Product-Owner oder andere Stakeholder weisen dem Team die Arbeitspakete zu und verhindern somit die Selbstorganisation des Teams.

Warum ist das schlecht?

  • Durch die Zuweisung von Arbeitspakten lässt der Product-Owner/Stakeholder das Team nicht nach agilen Prinzipien arbeiten
  • der Kern von Scrum und agilen Methoden wird daher untergraben. Das Team übernimmt im schlechtesten Fall weder Verantwortung für die Arbeit noch für die Effektivität
  • Die vom Product-Owner/Stakeholder gesetzten Deadlines sind zumeinst auch unrealistisch oder nicht gut durchdacht.
  • Das ganze Dilemma fügt sich dann meist in eine Plan getriebene Entwicklung ein
  • Das Umsetzungsteam wird unter starken druck gesetzt und gleichzeitig demotiviert.

Verbesserungen:

  • In diesem Fall sollten die Grundfeste der agilen Umsetzung und von Scrum wiederholt und diskutiert werden. Will das Team wirklich agil nach Scrum arbeiten oder nicht.
  • Wenn sich das Team dafür entscheidet, so sollte es sich auch dafür einsetzen und den Product-Owner/Stakeholder darüber aufklären wie agile Teamarbeit funktioniert.
  • Der Scrum-Master, sollte er vorhanden sein muss sich dafür einsetzen dass dieses Mikromanagement nicht statt findet, sondern stattdessen ein System nach Scrum aufbauen, das von alleine läuft.
  • Sollte der Scrum-Master vorhanden sein so ist es seine Verantwortung Scrum in der Organisation zu etablieren und alle beteiligten über die Rollen und deren Nutzen aufzuklären.
  • Es ist die Aufgabe des Scrum-Master das Team vor direkten eingriffen durch den Product-Owner oder durch Stakeholder zu schützen.

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: