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

Inhalt

  1. Feature-Injection
  2. Keine Remaining-Work/ Kein Burndown-Chart
  3. Zu viele Meetings
  4. Hardening Sprints
  5. Das falsche Feature bekommen
  6. Keinen Antrieb
  7. Der Neue
  8. Variable Sprintlänge
  9. Variable Teilzeit Teammitglieder

Beschreibung des Anitpattern:

  • Jemand fügt ohne die zuvor mit dem Team zu besprechen ein neues Feature ins Backlog hinzu.
  • Der Sprint Scope erhöht sich dadurch, ohne dass dies dem Umsetzungsteam bewusst ist.
  • Das Team findet diesen Umstand entweder heraus und wundert sich, warum ein zusätzliches PBI im Sprint verplant ist, oder es fällt nicht auf und das Team versucht den erhöhten Aufwand im Sprint zu stemmen.

Warum ist das schlecht?

  • Grundsätzlich ist das Umsetzungsteam für das Sprintbacklog verantwortlich, es darf somit niemand ein PBI zum Sprintboard hinzufügen, passiert dies doch so wird dieses Recht stark untergraben und dies führt zu einem Vertrauensverlust des Teams.
  • Fällt dem Team nicht auf, dass zusätzliche PBIs in den Sprint hinzugefügt wurden, so führt dies dazu, dass das Sprintziel nicht erreicht wird und das Team dabei glaubt, es habe schlechte Arbeit geleistet und sich bei der Planung oder der Schätzung des Aufwands verkalkuliert.
  • Wird der Umstand des zusätzlichen Aufwands entdeckt, so kann es passieren, dass sich Team vor den Kopf gestoßen fühlt und somit kann ein Konflikt entstehen.
  • Oftmals wenn einzelne Teammitglieder PBIs in den Sprint hinein ziehen, missachten sie dabei, dass sie ggf. auch Teammitgliedern bei der Umsetzung anderer Tasks helfen können

Verbesserungen:

  • Es kann sein, dass es demjenigen, der das PBI hinzugefügt hat, nicht bewusst ist, dass dies ein No-Go ist. Sollte dies so sein, so sollte der Scrum-Master die Person in Scrum und den Umgang mit dem Sprintboard ausbilden.
  • Der Scope wird zwischen dem Umsetzungsteam und dem Product-Owner verhandelt es darf also auch kein einzelnes Umsetzungsteam-Mitglied PBIs in den Sprint hineinziehen ohne zuvor dies mit dem restlichen Team und dem Product-Owner abzusprechen.
  • Zieht ein Teammitglied ein PBI in den Sprint ohne dies zuvor mit den Anderen Teammitgliedern und dem Product-Owner zu besprechen, so kann dies dazu führen dass ggf. andere aufgaben die das Teammitglied ebenfalls erledigen könnte nicht gemacht werden. Ein zusätzliches Hineinziehen kann also auf eine schwäche des Teams in der Selbstorganisation hindeuten. Somit sollte nie einfach eine zusätzliche Aufgabe in den Sprint ohne Besprechung mit den Kollegen hineingezogen werden sonder viel mehr nach offenen Themen gesucht werden die ursprünglich geplant waren.
  • Es können zum Beispiel qualitätssichernde Maßnahmen gemacht werden, getestet werden oder technische Schulden angegangen werden.
  • Der Scrum-Master sollte dies besonders genau beobachten und ggf. mit dem Team über Selbstorganisation sprechen.
  • Oft werden dies schnellen Features gegen Ende des Sprint von Teammitgliedern in den Sprint gezogen, zu dieser Zeit sollten alle aber vor allem der Scrum-Master das Sprintboard und die Burndown-Charts im Auge behalten, brennt die Remaining Work nicht einheitlich runter, oder steigt sie sogar kurzfristig wieder an, so ist dies ein Zeichen dass zusätzlicher Aufwand im Sprint aufgetaucht ist. Also beispielsweise ein neues Feature in den Sprint gezogen wurde.
  • Will ein Stakeholder oder der Product-Owner ein zusätzliches Feature oder einen Bug in den Sprint schieben, so kann er dies nicht ohne zuvor durchgeführte Absprache mit dem gesamten Umsetzungsteam. In diesem Fall muss das Team entscheiden ob es noch zusätzliche Kapazitäten frei hat, weil beispielsweise einige PBIs vor der geplanten Zeit fertiggestellt wurden, oder ob statt dem neuen Feature ein gleich hoch geschätztes anderes Feature aus dem Sprint genommen werden muss.
  • Wenn das neue Feature oder der Bug zuviel Raum im aktuellen Sprint einnehmen würde und dadurch essentielle PBIs aus dem Sprint fallen würden. Und dadurch das Sprintziel stark verändert werden würde, so muss der Sprint abgebrochen und neu aufgesetzt werden. In diesem Fall steht es aber nur dem Product-Owner zu den Sprint abzubrechen und gemeinsam mit dem Umsetzungsteam einen neuen Sprint zu planen.

Beschreibung des Antipatterns:

  • Das Team führt keine Remaining-Work Aufzeichnung pro geplanten PBI und weiß somit nicht wie lange es noch voraussichtlich dauern wird, bis das PBI fertig ist.
  • Dadurch weiß das Team auch insgesamt nicht ob das Sprint-Ziel realistischer weise erreicht werden kann oder nicht.
  • Das Team führt auch kein Burndown-Chart weil als Ausgangsbasis für das Burndown die Remaining-Work in allen geplanten PBIs gepflegt sein muss.

Warum ist das schlecht?

  • Wenn das Team die Remaining-Work nicht pflegt, kann niemand wissen ob ein geplantes PBI in der Zeit liegt oder nicht. Wenn es über der geplanten Zeit ist, kann das bedeuten, dass andere geplante Features im Sprint nicht fertiggestellt werden können. Dies führt dazu dass das Sprintziel gefährdet wird und gegebenenfalls nicht erreicht werden kann.
  • Das Team kann folglich nicht frühzeitig kommunizieren, dass das Sprintziel in Gefahr gerät. Schafft das Team dann Sprintziele nicht, kann schnell das Vertrauen in agile Methoden, Scrum und das Team in Frage gestellt werden.
  • Durch das fehlende Monitoring der Remaining-Work und die fehlende Gesamtsumme an Remaining-Work können Probleme die bei der Umsetzung entstehen von Anderen nicht bemerkt werden. So können andere Antipattern wie beispielsweise die Fehlende Unterstützung, Task-Assignment, oder Feature-Injection nicht vom Scrum-Master oder anderen Teammitgliedern bemerkt werden.

Verbesserungen:

  • Das Team sollte beim Planning bereits die Remaining-Work aller Tickets schätzen und das Burndown-Chart einrichten.
  • Die Remaining-Work sollte möglichst oft angepasst werden, im Idealfall mehrmals täglich, mindestens aber wenn ein Ticket in eine andere Arbeitsphase übergeht, oder fertig gestellt wird.
  • Mindestens einmal täglich vor dem Standup sollte allerdings bei allen PBIs die Remaining-Work angepasst werden.
  • Im Idealfall wird ein Tool zur Verwaltung der Tickets und der Remaining-Work bzw. des Burndown-Charts verwendet. Wenn allerdings mit einem physischen Sprintboard gearbeitet wird sollte das Team und der Scrum-Master die Zahlen und die Statistiken selbst täglich aktualisieren.
  • Wird die Remaining-Work getrackt und fallen Unregelmäßigkeiten oder Probleme auf so sollte diese sofort mit dem restlichen Team samt Product-Owner und Scrum-Master besprochen werden und Gegenmaßnahmen ergriffen werden.

Beschreibung des Antipattern:

  • Das Umsetzungsteam wird zu oft in Meetings eingebunden.
  • Oft werden technische Fragen von Stakeholdern oder fragen zum Projekte mit Meetings geklärt. Das Team muss sich Zeit nehmen und bei den Meetings mit den Stakeholdern dabei sein.
  • Weiter wichtige Meetings können von Vertrieb, Marketing, dem Management, der IT oder anderen Abteilungen/Stakeholdern kommen.
  • Neben den Ablenkungen durch Stakeholder benötigt auch der Product-Owner oft Meetings mit dem Team um Anforderungen zu spezifizieren und Fragen zu klären.
  • Oftmals werden diese Meetings auch sehr Spontan gemacht.
  • Die Meetings an sich sind oft nicht relevant. Fragen hätten auf anderen Kanälen gelöst werden können.

Warum ist das schlecht?

  • Wird das Team in zu viele Meetings eingebunden bleibt nur mehr wenig Zeit für die Umsetzung
  • Werden Meetings und Unterbrechungen nicht geplant sonder relativ spontan entschieden werden die Teammitglieder aus der Arbeit gerissen. Geistige Rüstzeiten müssen erneut investiert werden. Es kommt zu Fehlern und Mehraufwänden.
  • Selbst wenn nur einige Teammitglieder in Meetings verstrickt sind, schadet dies den andern Kollegen weil sich diese bei Fragen oder Abhängigkeiten nicht direkt an die Kollegen wenden können die gerade im Meeting verhindert sind.

Verbesserungen:

  • Fragen von Stakeholdern und vom Product-Owner sollten vorab zusammengetragen und in gesammelter Form geklärt werden.
  • Wenn möglich sollte der Product-Owner und der Scrum-Master das Team von direkten zugriffen durch Stakeholder abschirmen und versuchen die Anliegen der Stakeholder direkt zu klären.
  • Nur wenn es überhaupt nicht ohne einem Teammitglied möglich ist, sollte dieses in Frage-Meetings involviert werden.
  • Vertrieb, Marketing und IT sollten über die Zeit soweit educated werden, dass dies möglichst selbstständig arbeiten können und nicht wegen Kleinigkeiten das Team stören müssen.
  • Fragen von Product-Owner zum Produkt sollte dieser Sammeln und in Refinement-Meetings stellen.
  • Diese Refinement-Meetings sollten immer zur selben Uhrzeit und am selben Tag oder an den zwei selben Wochentagen (je nach Projekt) stattfinden und wenn möglich nicht länger als eine halbe Stunde dauern.
  • Generell ist es empfehlenswert vorab eine Agenda zum Termin rechtzeitig auszusenden und allen beteiligten die Chance zu bieten sich auf Meetings vorzubereiten. Gegebenenfalls kann mit einer guten Meetingvorbereitung das Meeting verhindert oder stark verkürzt werden.

Beschreibung des Antipatterns:

  • Meist werden Hardening-Sprints von Teams gemacht die über längere Zeit mehr auf Output und Quantität als auf Qualität geschaut haben.
  • Oder das Team ist noch sehr unerfahren und besteht aus unerfahrenen Software-Engineers und legt kein Augenmerk auf Qualität.
  • Dadurch ist oft die Qualität des Produkts über den Laufe der Zeit stagniert und schlechter geworden. Bis zu jenem Ausmaß, an dem ein untragbarer Status des Produkts und der Entwicklung erreicht wurde.
  • Das Team entscheidet dass es keine neuen Features mehr einbauen kann, sondern einen Hardening Sprint braucht um die technische Schuld die sich angestaut hat auszubessern und das Produkt wieder zu stabilisieren/zu härten.

Warum ist das schlecht:

  • Der Hauptgrund, warum Hardening Sprints schlecht sind, ist, weil sie eine reine Symptombekämpfung sind.
  • Scrum setzt sich zum Ziel, dass jeder Sprint ein potentiell releasebares Produktinkrement erzeugt. Dazu sollte das Team gemeinsam mit dem Product-Owner und dem Engineering-Team die Definition of Done festschreiben. Und diese gemeinsam entschlossenen Regeln zur Qualität auch in jedem einzelnen Sprint und für jedes einzelne Feature einhalten.
  • Ein weiteres gebot von Scrum ist es bei jedem einzelnen Sprint neue Features oder ein verbessertes Produktinkrement anzubieten. Und dabei ist nicht gemeint technische Schulden zu beseitigen. Diese Regelung ist wichtig, um den Usern immer wieder mehr Mehrwert zu schaffen und den Stakeholdern einen konstanten Fortschritt vorzeigen zu können. Das schafft Vertrauen ins Engineering-Team und in agile Praktiken.
  • Hardening Sprints sind üblicherweise auch ein starkes Alarmzeichen dafür, dass das Team agile Prinzipien und Scrum nicht richtig verstanden hat oder umsetzen kann.

Verbesserungen:

  • Zunächst muss das Team die Problematik dieses Antipattern verstehen. Dazu kann der Scrum-Master die negativen Konsequenzen dieses Verhaltens aufzeigen.
  • Es muss allen Teammitgliedern klar sein, dass Hardening Sprints Symptombekämpfung sind und nicht gegen die eigentliche Ursache der Probleme wirken.
  • Sollte das Team agile Methoden und Scrum nicht ganz verstanden haben, so muss der Scrum-Master durch Schulungen das Team in diesen Punkten auf neuesten stand bringen. Ein agile Mindset muss vorherrschen, und das Team muss Sprint für Sprint für guten Outcome sorgen und darf nicht im Output getriebenen Denken verhaftet sein.
  • Falls es keine oder keine ausreichend gute Definition of Done gibt, so sollte sich das Team in einen Workshop Gedanken dazu machen und eine gemeinsame Definition of Done erstellen.
  • Liegt die Ursache der schlechten Qualität des Produkts in dem Fehlenden Knowhow des Teams, oder einiger Teammitglieder, so kann es auch sinnvoll sein diese auf Workshops zu schicken.
  • In jedem Fall macht es Sinn, dass erfahrenere Software-Engineers ihr Wissen an die unerfahreneren weitergeben. Dies ist am einfachsten durch Reviews, gemeinsame Architektur- und Design-Workshops und Pairprogramming möglich.
  • Auch Grundlagen für saubere Software-Engineering Prozesse, Clean Code, und Code-Qualität sind notwendig. Testautomatisierung, Unit-Testing, Integrationstest und generell Testkonzepte sind notwendig, um Hardening-Sprints zu verhindern und eine gute Erweiterbarkeit und Qualität der Software zu gewährleisten.

Beschreibung des Antipatterns:

  • Der Product-Owner glaubt er bekommt ein Feature mit einer gewissen Funktionalität geliefert zu bekommen, das Team arbeitet jedoch an einem Feature mit einer teilweise ganz anderen Funktionalität.
  • Erst sehr spät zum Beispiel beim Review wird dieses Missverständnis entdeckt.
  • Meist rührt das Problem darin dass es das Scrum-Team nicht geschafft hat ein einheitliches gemeinsames Verständnis für die Aufgabe zu entwickeln. Das Team redet zu wenig oder gar nicht über die gewünschten PBIs und hat eine schlechte Kommunikationskultur.
  • Meist treten diese Probleme auch dann auf, wenn das Umsetzungsteam zu sehr im Lösungsraum verhaftet ist und sich nur auf die technische Lösung eines Problems konzentriert, aber eigentlich gar nicht genau weiß, was die User für Probleme haben und diese eigentlich brauchen.

Warum ist das schlecht?

  • Werden Features falsch umgesetzt, resultiert dies in einem erheblichen Kostenanstieg in der Entwicklung. Denn die Fehler müssen zurückgebaut und ausgebessert und die eigentlich gewünschte Funktionalität muss hergestellt werden. Somit fallen einerseits die Kosten für die falsche Implementierung an und dann noch die Kosten für die richtige Implementierung.

Verbesserungen:

  • Sollte das Problem aufgrund von schlecht geschriebenen oder unvollständigen Beschreibungen der PBIs bestehen, so muss der Product-Owner mehr Zeit und Leistung in die Beschreibung der Aufgaben legen. PBIs sollten immer mindesten eine User-Story aufweisen, die dem Leser der Story verständlich mach was warum zu tun ist. Zusätzlich müssen PBIs immer Akzeptanz-Kriterien aufweisen die genau beschreiben was der Product-Owner bzw. der User am Ende genau in der Lösung braucht und wie Spezialfälle gehandhabt werden sollen.
  • Das Team sollte auf jeden Fall, falls noch nicht vorhanden Refinement-Meetings machen. Bei denen das Team in regelmäßigen abständen die vorhandenen Backlog-Items gemeinsam diskutiert und ein gemeinsames Verständnis herstellt.
  • Fehlt den Software-Engineers der Einblick und das Verständnis für die Zieluser und deren Bedürfnisse, so sollt der Product-Owner dafür sorgen dass gemeinsam mit dem Umsetzungsteam User-Tests gemacht werden. Dadurch kann das Team selbst beobachten und erfahren, wie die Software von den Zielusern verwendet wird und welche Bedürfnisse und Probleme diese haben.
  • In der nächsten Retrospektive sollte das Thema auf jedenfall angesprochen werden und auch die gemeinsame Kommunikation kritisch beleutet werden.
  • Es kann beispielsweise auch oft helfen, frühzeitig Feedback vom Product-Owner einzuholen wie etwas gemeint ist oder wie etwas Umgesetzt werden soll.
  • Dazu ist es natürlich auch wichtig dass der Product-Owner seinen Job ernst nimmt und sich genügend zeit für seine Teamkollegen und seine Aufgaben nimmt.

Beschreibung des Antipatterns:

  • Das Team ist gefangen in einem ewigen Trott an Sprints die nie fertig werden. Es werden pausenlos Tickets im Sprint angefangen, die nicht bis zum Ende des Sprints fertiggestellt werden können. Diese unfertigen Tickets werden dann auf den nächsten Sprint verschoben.
  • Die Produktinkremente werden auch in den meisten Sprints nicht fertig. Sodass Product-Owner und User entweder schlecht oder gar keine Releases bekommen.

Warum ist das schlecht?

  • Liefert das Team die vereinbarten Sprintziele nicht ab und kann es keine sauberen Inkremente bereitstellen, so verlieren die Stakeholder und User sehr schnell das Vertrauen in das Team und das Produkt. Dies kann massive wirtschaftliche und soziale folgen für das Team und das Unternehmen haben.
  • Durch die nicht Einhaltung der Sprintziele entsteht auch ein großer Konfliktpunkt zwischen Product-Owner und Umsetzungsteam. Die gemeinsame Arbeit und die Kommunikation miteinander kann leiden.

Verbesserungen:

  • Oft gerät ein Scrum-Team in eine derartige Abwärtsspirale wenn die Planung und das Schätzen des Sprints nicht richtig abläuft oder das Team aus anderen Gründen keinen Antrieb mehr hat. Meist führt jedoch das eine zum anderen. Denn werden Sprintziele immer wieder nicht erreicht, so leidet auch die Moral im Team.
  • Gegen die Planung und schlechte Aufwandsschätzungen kann systematisch vorgegangen werden. Am Ende des Sprints sollte das Team genügen Puffer für das Testen und Stabilisieren des Produkts mit einplanen. Geschätzt sollte am Besten gemeinsam werden, systematisch, mit Hilfe von Story-Points für die Grobschätzung und mit Hilfe von detaillierteren Stundenschätzung in der Feinplanung und Feinschätzung.
  • Für die Moral und den Antrieb sollten zunächst die strukturellen Probleme beseitigt werden und dann durch offene Gespräche, Teambuilding und Anreizsysteme vom Management/Scrum-Master gegengesteuert werden.
  • Sollten sich bei der Analyse und Verbesserung der strukturellen Probleme des Scrum-Teams und des Scrum-Prozesses immer wieder herausstellen dass es einige punkte gibt die nicht umzusetzen sind, kann dies ein Hinweis darauf sein, dass Scrum nicht die richtige Methode für dieses Team oder dieses Problem ist. Dann kann beispielsweise auf Kanban oder eine andere Vorgehensmethode umgestellt werden.

Beschreibung des Antipatterns:

  • Mitten im Sprint taucht ein neuer Kollege auf, der von nun an im Team mitarbeiten soll.
  • Der Neue Kollege und die Aufwände zum betreuen dieses neuen Kollegen sind aber nicht im Sprint eingeplant oder berücksichtigt.

Warum ist das schlecht?

  • Dieses Antipattern ist vor allem dann besonders schlecht wenn das Team unter einem hohen druck steht, beispielsweise wenn die Software schon live ist und es viele aktive User gibt, und neue Features geplant und umgesetzt werden müssen.
  • Da die zusätzlichen Aufwände für die Betreuung und Einführung des neuen Kollegen nicht berücksichtigt wurden führt dies zu einen noch höheren Druck auf das Umsetzungsteam. Dies kann einerseits dazu führen dass sich der neue Kollege nicht wohl aufgenommen fühlt und schnell frustriert wird, und andererseits dass das Team durch die zusätzliche Mehrbelastung unfreundlich und gestresst wirkt.
  • Im Schlimmsten Fall kündigt der neue Kollege oder bittet um eine Versetzung in ein anderes Team, oder die Stakeholder werden enttäuscht weil das Sprintziel nicht eingehalten wurde.

Verbesserungen:

  • Es ist gang und gebe dass neue Teammitglieder während eines laufenden Sprints in das Team aufgenommen werden, jedoch müssen die dadurch entstehenden Mehraufwände in den Sprint mit eingeplant werden und das Onboarding bereits im Vorfeld gut geplant werden. So können für diese Vorbereitungsarbeiten bereits im vorgehenden Sprint Aufwände entstehen.
  • Alle Beteiligten wollen den neuen Kollegen herzlich im Team aufnehmen damit dies möglich ist sollten die dazu benötigten Zeiten auch eingeplant werden.
  • Geraden in größeren Unternehmen weiß das Team oft nicht wirklich wann neue Kollegen zum Team hinzugefügt wurden, dies lässt dann auf ein bestehendes Organisatorisches Antipattern schließen.

Beschreibung des Antipatterns:

  • Das Scrum-Team erkennt dass es aufgrund von Verzögerungen den Sprint um einige Tage verlängern muss, oder den Sprint aufgrund von schnelleren Umsetzungen verkürzen kann und ändert kurzerhand die Sprintlänge.
  • Ein verkürzter Sprint aufgrund von Feiertagen etc. zählt explizit nicht zu diesem Antipattern.

Warum ist das schlecht?

  • Aufgrund der veränderten Sprintlänge können keine lehren aus Fehlern in Schätzung und Planung geschlossen werden.
  • Sprints sollen neben dieser Lernmöglichkeit auch deswegen immer gleich sein, damit sich Stakeholder und User auf regelmäßige Releases einstellen können. Verändert das Team die Sprintlänge so kann das Vertrauen in die Umsetzungskompetenz des Teams leiden.
  • Eine Verschiebung des Sprintendes kann auch eine Vermeidungstaktik sein, um Probleme im Team oder in der Planung nicht ansprechen zu müssen.

Verbesserungen:

  • Das Team sollte sich mit den zu Grunde liegenden Problemen beschäftigen anstatt das Problem hinaus zu schieben.
  • Der Scrum-Master sollte verhindern, dass die Sprintlänge vom Team verlängert oder verkürzt wird.
  • Die Planung und Schätzung von PBIs im Sprint sollte aufgrund der Fehler die gemacht werden verbessert werden dies ist nur dann möglich wenn die Sprints nicht variable sind.

Beschreibung des Antipatterns:

  • Einzelne Teammitglieder sind nur Teilzeit im Scrum-Team beschäftigt.
  • Die Teilzeit die sie pro Sprint dabei sind schwankt obendrein noch stark.

Warum ist das schlecht?

  • Ein Sprint baut auf Planbarkeit und Verlässlichkeit auf. Sind einige Teammitglieder unregelmäßig arbeiten und kann man deren Kapazität nur schwer oder gar nicht einplanen so kann das Team sich nicht gut auf Sprintziele festlegen.
  • Fehler in Planung und Schätzungen können ebenfalls schwerer erkannt werden weil immer die schwankende Kapazität der Kollegen mit hineinspielt.
  • Teilezeitkräfte sind generell schon schwierig in Scrum-Teams unter zu bekommen weil Scrum aus viel Absprachen, Planungen und Meetings besteht. Dies ist schwieriger wenn die benötigten Kollegen zum Zeitpunkt des Meetings oder des Bedarfs nicht erreichbar sind.
  • Außerdem sind Teilzeitkräfte dadurch auch weniger produktiv weil sie im Verhältnis mehr Zeit in Meetings und Abstimmungen verbringen als sie für Umsetzungen aufwenden.

Verbesserungen:

  • die Teilzeit Teammitglieder müssen für eine Planbarkeit pro Sprint sorgen. Dies gelingt besser bei kürzeren Sprints.
  • Somit kann beispielsweise die Sprintdauer von 4 auf 2 Wochen reduziert werden.
  • Sollten die Zeiten und Kapazitäten der Teilzeitkräfte dennoch nicht gut planbar sein, können separate Tracks im Sprint geplant werden die nicht teil des Sprintziels sind und so zu sagen als nice to have noch umgesetzt werden können. Ohne dabei jedoch eine Verpflichtung auf das Produktinkrement zu haben. Dies ist allerdings mit einigen an Schwierigkeiten verbunden und bedarf hoher Disziplin, Eigenverantwortung und Selbstorganisation der Teilzeitkräfte.

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: