Als wir einmal aus Versehen Scrum machten…

Manche Wochenenden sind wirklich hart, aber manche sind auch härter. Ein normales Wochenende beginnt irgendwann Freitag abends, man kommt aus dem Büro, schnuppert zum ersten Mal an diesem Tag den Duft und die Luft der Freiheit und freut sich auf zweieinhalb entspannte Tage.

Manche Wochenenden starten aber auch so, dass man am Freitag aus dem Büro kommt und genau weiß, dass ein sehr, sehr anstrengendes Wochenende bevorsteht.

So ein Wochenende war beispielsweise dieses. Folgendes ist passiert.

Das Projekt

Meine Schwägerin Sandra (die Schwester meine Frau) und deren Mann Steffen bauen ein Haus (Projekt!).

Normalerweise ist das Projekt fast ausschließlich mit externen Mitarbeitern besetzt (Bauarbeiter,Technische Zeichner, Maurer, Zimmermänner).

Um Kosten zu sparen werden jedoch kleinere Teilprojekte durch interne Teams vom Projektleiter (mein Schwiegervater) besetzt.

Eines dieser Teilprojekte sollte dieses Wochenende durchgeführt werden.

Die Vision

Das neue Haus bekommt einen vollständig aus Holz gebauten Dachgiebel mit Sichtbrettern (Epic). Um diesen Dachgiebel bauen zu können müssen gewisse Vorarbeiten geleistet werden.

Der technische Projektleiter und Architekt (Gerhard, der Zimmerermeister) hat bereits einige technische Stories mit seinem Team von externen (Zimmerersleut) abgeschlossen. Natürlich alles in Time und Budget. Zuletzt wurden die entsprechenden Stütz- und Sichtbalken angefertigt, genauso wie die Bretter zur Verkleidung des Daches zurechtgeschnitten.

Da das Errichten des Dachgiebels einen festen Abgabetermin hat, musste ein Team von internen (Schwager + Geschwister) aus anderen Projekten (Wochenend-Entspannung) abgezogen werden, in der Hoffnung durch die Erhöhung von Ressourcen Zeit- und Budget einsparen zu können.

Das Epic “Errichten des Dachgiebels nebst Dach” wurde vom Projektleiter in mehrere Stories mit festem Scope unterteilt. Eine dieser Stories wird dem frisch zusammengestellten Team vom technischen Projektleiter vorgestellt.

Das Team besteht aus Sandra + Steffen (Product-Owner, Häuslebauer und Arbeiter), Martin (Scrummaster + Arbeiter), Anita und Christine (Schwestern + Arbeiterinnen). Wir befinden uns also in der wunderbaren Position, dass die Product-Owner Teil des Teams sind und so für fachliche Fragen jederzeit zur Verfügung stehen.

Es sind zwei Sprints geplant (Dauer jeweils 1 Tag, Samstag + Sonntag) mit folgenden Stories im Scope:

Story 1: Als Häuslebauer möchte ich, dass meine Bretter für das Dach mit einem Schutzlack bestrichen werden, damit sie vor der Witterung geschützt sind.

Story 2: Als Häuslebauer möchte ich, dass alle nach außen sichtbaren Balken des Dachgiebels mit Schutzlack bestrichen werden, damit auch sie vor der Witterung geschützt sind.

Zunächst wird vom Team eine Estimation-Runde für die kommenden Sprints abgehalten (vor Sprintbeginn, Freitag abend). Leider jedoch mangels Pokerkarten nicht durch Planning-Poker:).

Das Team einigt sich auf die entsprechenden Tasks und gibt das Commitment ab, den Scope bis Sonntagabend zu schaffen.

Jede Story soll in einem eigenen Sprint abgearbeitet werden.

Zusätzlich werden noch die Verfügbarkeiten für den kommen Sprint geprüft, hierbei stellt sich heraus, dass die beiden Product-Owner am Samstag mindestens 3 Stunden nicht verfügbar sein werden, da sie bereits Stories für kommende Sprints planen werden (Beratung im Möbelhaus bzgl. neues Bad).

Das Team plant die Stories und definiert erste Tasks:

  • Beschaffung von Ressourcen (Pinsel, Lack, Malerkleidung, Folien)
  • Bereitstellung eines Repositories zur Lagerung von lackierten Brettern
  • Lackieren von gekennzeichneten Brettern
  • Qualitätssicherung
  • Pair-Lackiering zwecks Know-How-Verteilung

Der Sprint startet

Das Team trifft sich Samstag früh zum Daily Scrum (Frühstück) und bespricht die Aufgaben für den heutigen Tag.

Hierbei stellt sich zunächst heraus, dass der Technische Projektleiter Gerhard zunächst eine Einweisung für das Team geben wird, da Gerhard die technische Expertise hat und hierdurch Zeit und Kosten gespart werden können.

Zunächst erklärt Gerhard fachlich,was überhaupt gemacht werden muss (ich wundere mich sehr, denn die Expertise hier liegt tatsächlich beim Projektleiter und nicht bei den Product-Ownern).

Die Bretter müssen jeweils auf der Oberseite und den zwei Seitenkanten gestrichen werden. Hierfür stellt uns Gerhard die notwendigen Tools (2 Böcke um die Bretter aufzulegen, Lack-Eimer, Pinsel und eine Vorrichtung zum Trocknen der Bretter zur Verfügung).

Der Sprint startet, leider verlassen die zwei Team-Mitglieder (und Product-Owner) sofort den Ort des Geschehens und widmen sich der Bad-Beratung.

Das restliche Team (Martin, Anita und Christine) starten mit der Umsetzung. Es ist keine großartige Analyse notwendig, denn nach kurzer Beratung im Team ist klar, dass die Aufgabe verstanden ist und das Team sich auf ein gemeinsames Design geeinigt hat.

Die ersten Tasks sind schnell erledigt, denn für das Aufsetzen des Repositories wird einfach die leerstehende Lagerhalle des Projektleiters verwendet.

Das Team startet also zunächst zu dritt. Die Ressourcen (Bretter) wurden bereits angeliefert, aber bisher noch in Folie verschweist. Sofort beginnt das Team selbstverantwortlich damit, die entsprechenden Rollen zu verteilen. Martin organisiert zunächst einen Schraubenzieher und einen Holzstab um die Lackeimer zu öffnen und den Lack durchzurühren.

In der Zwischenzeit kümmern sich Anita und Christine darum, die Folie der verpackten Bretterstapel zu öffnen, so dass im weiteren Sprint sehr schnell auf die Ressourcen zugegriffen werden kann. Es wurde sehr wohl darüber diskutiert, welche Variante die performanteste ist (Öffnen der Folie erst direkt vor Verwendung oder Öffnen aller Folien). Da Martin aber ungefähr so lange brauchen wird, um den Lack vorzubereiten wir Anita und Christine um alle Folien zu öffnen einigt sich das Team auf diesen Weg.

Nachdem der Lack angerührt ist, starten Martin und Christine damit, Bretter auf die vorbereiteten Böcke zu legen.

Zunächst startet das Team mit 3 Brettern, die gleichzeitig bearbeitet werden. Das Team einigt sich darauf, dass Anita und Christine gemeinsam auf einer Seite anfangen (Pair-Lackiering) und Martin auf der anderen Seite. Sobald sich das Team in der Mitte trifft sind die Bretter fertig.

Martin, der Scrummaster fängt sofort an, die Geschwindigkeit des Teams zu messen und misst die Dauer für das Lackieren von 3 Brettern (WIP-Limit!). Die Dauer von 8 Minuten ist alles andere als zufriedenstellend. Martin macht eine Hochrechnung, zählt alle zu lackierenden Bretter und kommt auf 210 Stück, was an einem perfekten Tag (ohne Unterbrechungen) in ca. 9,5 Stunden zu erledigen wäre.

Der Arbeitsablauf gliedert sich in folgende Schritte:

  • Bretter auf die Böcke platzieren
  • 3 Seiten lackieren (obere Seite + 2 Seiten)
  • Bretter in die Trockenvorrichtung einbringen

Martin weiß aber auch, dass es keine perfekten Tage gibt, also wäre wohl eher mit 11 Stunden zu rechnen. Dies ist für keines der Teammitglieder akzeptabel und so wird bereits über mögliche Refactorings nachgedacht.

Eine Möglichkeit wäre, die Anzahl der Bretter zu erhöhen (WIP-Limit erhöhen), eine Erhöhung der Ressourcen (Teammitglieder) wäre leider erst in einigen Stunden möglich, sobald die Product-Owner zurückkommen. So lange will das Team aber nicht warten, also einigen sich alle gemeinsam ( mit dem Scrummaster), die WIP-Limits hochzusetzen auf 6 Bretter, die gleichzeitig bearbeitet werden.

Zusätzlich möchte das Team die Arbeit besser aufteilen, so dass das Teammitglied Anita sich darum kümmert, die dünneren aber schwieriger zu streichenden Seitenteile zu streichen, währendessen Christine und Martin die großen Flächen der Bretter lackieren. Die Arbeit wird also besser aufgeteilt und die Teammitglieder kommen sich weniger in die Quere.

Nach dem zweiten Durchlauf misst der Scrummaster erneut die Durchlaufzeit und kommt auf ca. 10 Minuten für 6 Bretter, was hochgerechnet eine Dauer von ca. 6 Stunden beträgt. Das Team hat also durch eine einfache Anpassung eine Steigerung um grob 30% erreicht.

Das Team legt los und merkt mit der Zeit richtig, wie sich die einzelnen Teammitglieder aufeinander einspielen. Nach vier Iterationen macht Anita ein (Code-) Review der bereits abgeschlossenen Bretter und stellt signifikante Qualitätsmängel fest, so dass hier leider nochmals nachgearbeitet werden muss.

Das Team beschließt, sofort eine Retrospektive zu machen um über die Mängel zu diskutieren (das Team ist sich natürlich im Klaren darüber, dass es sehr früh ist, nach ca. einer Stunde Sprintdauer eine Retrospektive durchzuführen, es spricht aber absolut nichts dagegen, wenn das Team sich gemeinsam darauf einigt.)

Das Team stellt sich also folgende Fragen:

Was lief gut?

  • Aufteilung der Aufgaben auf einzelne Teammitglieder
  • WIP Limits

Was lief nicht gut?

  • Qualitätssicherung
  • Ein Teil des Teams nicht verfügbar

An der Verfügbarkeit der Teammitglieder kann derzeit leider weder der Scrummaster noch der Projektleiter etwas ändern. An der Qualität jedoch durchaus. Das Team vereinbart, eine zusätzliche Qualitätssicherung nach jedem Durchgang. Dies soll zunächst von Anita durchgeführt werden, die nochmals ein kurzes Review für jedes Brett macht und ggf. nacharbeitet. Jedes Brett, dass durch das Review gekommen ist, wird von Martin und Christine auf die Trockungsvorrichtung gebracht.

Definition of Done

Das Team einigt sich hierfür zu folgender Definition of Done:

  • Jedes Brettoberseite ist vollständig mit Lack bedeckt
  • Die Seiten sind vollständig gestrichen
  • Es befinden sich keine Lack-Ansammlungen mehr auf Brettern, sondern diese sind sauber verstrichen.

Dadurch, dass das Team mittlerweile sehr gut aufeinander eingespielt ist, führt dieser zusätzliche Schritt zu keiner Verzögerung beim Fertigstellen der Story und doch wird eine signifikante und messbare Steigerung der Qualität erreicht.

Das Team arbeitet weiter für zwei Stunden und schafft es immer besser, die anstehenden Tasks abzuarbeiten als plötzlich Steffen (der vermisste Product-Owner) das Büro (also die Halle) betritt.

Zunächst stellt sich die Frage, ob eine Erhöhung der Teamstärke überhaupt Sinn macht, zumal das Team in der jetzigen Konstellation sehr gut aufeinander eingespielt ist und eine zusätzliche unerfahrene Ressource zunächst den Fluss bremsen dürfte. Ein weiteres Problem, das auftritt ist das Fehlen eines Pinsels, da momentan nur 3 verfügbar sind.

Das Team entscheidet sich dennoch, dass es Sinn macht, dass Steffen in die Story einsteigt. Das Fehlen eines Pinsels wird vom Team als Impediment an den Scrummaster (Martin) kommuniziert, der löst das Impediment temporär, indem er seinen Pinsel an Steffen abgibt, und so dafür sorgt, dass das Team zunächst problemlos weiterarbeiten kann.

Martin sucht in der Zwischenzeit den Projektleiter (Schwiegervater) auf, und bittet diesen um weitere Ressourcen. Der Projektleiter hat schnell ein einsehen, denn der Scrummaster argumentiert, dass er überzeugt ist, dass eine Erhöhung der Teamstärke sich positiv auf die Velocity auswirkt.

Die beiden lösen das Problem durch einen weiteren Pinsel (leider einen ziemlich schmalen), den der Scrummaster zurück zum Team bringt. Es stellt sich heraus, dass der schmale Pinsel ideal geeignet ist, um die Seiten der Bretter zu streichen, so dass sich jetzt 4 Teammitglieder aktiv am Sprint beteiligen können.

Das fünfte Teammitglied (Product-Owner Sandra) fragt zwar an, ob weitere Ressourcen benötigt werden, dies wird vom Team aber verneint, da dies die Koordination innerhalb des Teams stark erschweren würde. Das Team einigt sich also darauf, dass Sandra sich darum kümmern soll, das Team anderweitig zu supporten (Kaffee kochen, Kuchen bringen sowie schon mal das Abendessen vorbereiten).

Das Team einigt sich in der Zwischenzeit darauf, dass es besser ist, angefangene Aufgaben (einzelne Bretter) so schnell wie möglich fertig zu stellen und nicht alle Bretter gleichzeitig anzufangen. Sind zwei Bretter fertiggestellt, bringen die Teammitglieder die zuletzt an diesen gearbeitet haben diese auf die Trockenstation, während die anderen Teammitglieder weiterarbeiten und dann die nächsten Bretter auf die Trockenstation bringen.

Zwischendurch misst Martin der Scrummaster immer wieder die Performance des Teams (in der Zwischenzeit bei 4:40 für 6 Bretter), was das ganze Team zufrieden stellt.

Burn-Down-Trockenstation

An der Burn-Down-Trockenstation ist für jeden jederzeit ersichtlich, wieviel Tasks (Bretter) bereits abgeschlossen sind, was der Projektleiter auch des öfteren in Anspruch nimmt.

Scrum-Board

Weiterhin ist das Scrum-Board (Lager von nicht bearbeiteten Brettern) jederzeit ersichtlich, wieviele Tasks noch abzuarbeiten sind, um den Sprint-Scope zu erreichen.

Der erste Sprint endet…

Der erste Sprint endet und das Team schafft alle Tasks (Bretter) für diesen Sprint.

Am Ende des Tages macht das Team ein Review zusammen mit den Product-Ownern (Steffen und Sandra) sowie dem Projektleiter (Schwiegervater).

Hierbei führt das Team vor, wieviele Bretter lackiert wurden und wie diese zum Trocknen gelagert wurden. Sowohl Product-Owner, Projektleiter und technischer Projektleiter (Gerhard) erteilen die Abnahme und erklären den Sprint zum Erfolg.

Zur Feier des Tages treffen sich alle Projektbeteiligten und feiern den gelungenen Sprint (bei Brotzeit und Weißbier).

Sprint 2 startet

Allen Teammitgliedern sind zum Ende des Sprints die Strapazen anzumerken. Der Scrummaster macht sich Sorgen um sein Team und mahnt die Einhaltung des Sustainable Pace an. Das Team einigt sich darauf, dass es den Tag etwas später angeht (geplant war Sprint-Start um 08:00, das Team verschiebt zusammen mit den Product-Ownern und dem Projektleiter auf 09:00).

Zunächst trifft sich das Team wieder zum Daily Scrum (Frühstück) und bespricht die Aufgaben des Tages.

Hier nochmals die Story, die in diesem Sprint umgesetzt werden soll:

Story 2: Als Häuslebauer möchte ich, dass alle nach außen sichtbaren Balken des Dachgiebels mit Schutzlack bestrichen werden, damit auch sie vor der Witterung geschützt sind.

Das Team wird diesen Sprint nicht vor Ort arbeiten sondern in den Räumlichkeiten des technischen Projektleiters Gerhard (er ist der Zimmerermeister und hat die Balken bei sich im Holzlager).

Der Projektleiter organisiert also eine Mitfahrgelegenheit für das Team (mit beiden Familienautos) und das Team macht sich auf den Weg.

Vor Ort stellt sich sofort heraus, dass dem Team für den Sprint-Start nicht genügend Ressourcen zur Verfügung stehen. Der technische Projektleiter hatte 3 Eimer Lack organisiert mit der Zusicherung, dass diese für beide Stories reichen würden. Leider wurden durch fehlende Erfahrung im Team zu viel Ressourcen (Lack) im letzten Sprint verbraucht, so dass der Scope von Sprint 2 gefährdet scheint. Dies scheint zunächst ein großes Problem zu sein, denn es ist Sonntag und die Ressourcenbeschaffung scheint zunächst unmöglich.

Der Scrummaster und das Team sowie der technische Projektleiter einigen sich darauf, dass dieses Problem im Anschluss geklärt wird, da noch genügend Lack zur Verfügung steht, um zunächst mit dem Sprint zu starten.

Zunächst erläutert der technische Projektleiter, was genau zu tun ist (schon wieder ist es so, dass nicht die Productowner die fachlichen Anforderungen kennen, sondern der technische Projektleiter).

Gerhard erklärt, dass alle Balken an bestimmten Stellen mit Kerben versehen sind, an denen die Balken später am Dachgiebel ineinandergesteckt werden. Ausserdem sind alle Balken an den Stellen, an denen sie der Witterung ausgesetzt sind abgeschliffen. Diese Stellen sind leicht erkennbar, und Gerhard erklärt, dass genau diese Stellen lackiert werden müssen. Es gibt jedoch einige Ausnahmen, die Gerhard dem Team erklärt, so müssen manche Balken nur auf bestimmten Seiten, andere jedoch gar nicht lackiert werden).

Das Team (heute bestehend aus beiden Product-Ownern Steffen und Sandra, Martin, Anita und Christine) diskutiert kurz und stellt fest, dass die Anforderungen so weit klar sind und das mit dem Sprint gestartet werden kann.

Das Scrum-Board

Das Scrum-Board visualisiert die anstehenden Aufgaben für den Sprint.

Während das Team also beginnt, die ersten Tasks auf (aus) dem Scrum-Board (Stapel von unlackierten Balken) in die “In Progress”-Spalte (vorbereitete Böcke für die Balken zum Streichen) zieht, klärt der Scrummaster mit dem technischen Projektleiter, wie das Impediment des fehlenden Lacks gelöst werden kann.

Es findet sich eine einfache Lösung, da ein Projektleiter in einem anderen Projekt (ein Kollege von Gerhard, der ganz in der Nähe wohnt) Ressourcen zur Verfügung hat, die noch nicht direkt benötigt werden. Gerhard macht sich also schnell auf den Weg, und besorgt zwei weitere Eimer Lack.

Die Aufgabenverteilung im Team ist in diesem Sprint relativ klar, denn es gibt Aufgaben, die nur von Spezialisten im Team erledigt werden können (das Hin- und Herstapeln von fertigen bzw. neuen Balken können nur die Männer) während der Rest des Teams sich darauf konzentriert, die geschliffenen Stellen zu lackieren.

Es dauert nur ca. 15 Min. und der technische Projektleiter kommt mit den fehlenden Ressourcen, so dass auf jedenfall genügend für den Sprint vorhanden sind. Dieser verlässt dann aber das Teambüro (Hof) mit der Aussage, dass wichtige andere Aufgaben auf ihn warten (es ist Sonntag, und da gibts haufenweise besseres zu tun, als zuzuschauen, wie ein Haufen Balken lackiert wird).

Das Team arbeitet konzentriert ca. eine Stunde an den anstehenden Aufgaben, bis ein Teammitglied sich per Handzeichen meldet und über ein mögliches Problem informiert.

Impediment

Das Teammitglied ist sich nicht mehr sicher, wie und ob ein bestimmter Balken zu streichen ist. Das Team kommt zusammen, und diskutiert das Problem. Hierbei kommen folgende Lösungsvorschläge zusammen:

  • Gerhard meinte, der Balken muss gar nicht gestrichen werden
  • Gerhard meinte, der Balken muss komplett gestrichen werden
  • Gerhard meinte, der Balken muss nur am vorderen Ende gestrichen werden
  • Ich habe keine Ahnung

Es findet sich leider keine Lösung, da scheinbar niemand im Briefing des technischen Projektleiters besonders aufmerksam war. Der Scrummaster nimmt sich des Problems an und versucht, den technischen Projektleiter telefonisch zu erreichen. Martin versucht Gerhard zu erklären, welcher Balken genau gemeint ist (was sehr schwierig über das Telefon ist, da im Prinzip alle Balken genau gleich aussehen), aber er schafft es, sich technischen Rat einzuholen und so das Problem zu lösen (der Balken war komplett zu streichen).

Refactoring

Was bei dem Telefongespräch auch herauskommt ist, dass die gestrichenen Balken wieder genauso aufgestapelt werden müssen, wie sie vor dem Streichen gestapelt waren, damit sie mit kompatibel mit den Bestandssystemen (dem Gabelstapler) sind, um eine spätere Integration (das Verladen der Balken auf einen Ladehänger) zu ermöglichen.

Dies hatte das Team nicht bedacht, und so ist es nötig, bereits abgeschlossene Tasks im laufenden Sprint zu refactoren. Der Scrummaster ist damit zunächst nicht einverstanden, und bespricht mit dem technischen Projektleiter, wie damit umzugehen wäre – und sie einigen sich darauf, dass das Refactoring notwendig ist, damit die Tasks der Definition of Done genügen.

Definition of Done

  • Alle Balken sind nach den Vorgaben des technischen Projektleiters lackiert
  • Die Balken sind nach dem Lackieren wieder genauso gestapelt wie vor dem Lackieren

Die zwei Spezialisten im Team machen sich also sofort daran, die notwendigen Refactorings vorzunehmen. Der Scrummaster versichert sich beim Team, ob der Scope des Sprints trotzdem noch geschafft werden kann. Das Team ist sich sicher, den Scope trotzdem zu halten, da das Refactoring das Team nicht allzu lange aufhalten sollte.

Sprintabschluss und Review

Nach 6 Stunden mit 5 Personen ist die Story und der Sprint abgeschlossen. Pünktlich zum Sprintabschluss kommt der technische Projektleiter, um zusammen mit den Productownern eine Abnahme zu machen. Alle Aufgaben wurden erledigt und genügen der Definition of Done.

Das Scrum-Team hat einen weiteren Sprint erfolgreich abgeschlossen.

Retrospektive

Das Team veranstaltet eine letzte Retrospektive (Abendessen mit Hendl, Kartoffeln und Weißbier) und diskutiert die vergangenen Sprints. Das Team bemerkt vor allem, dass durch den letzten Sprint (das Streichen der Bretter) ein sehr guter Teamzusammenhalt entstanden ist und alle gemeinsam darauf hinarbeiten, das Sprintziel zu erreichen.

Der Projektleiter und die Product-Owner informieren das Team, dass die nächsten Sprints wieder von externen Teams (Bauarbeiter und Zimmerer) durchgeführt werden, dass aber mit Sicherheit schon sehr, sehr bald wieder die Schlagkraft des gut eingespielten internen Teams gebraucht wird.

Nachtrag:

Inzwischen hat das externe Scrum Team (Gerhard, der Zimmerermeister mit seinem eingespielten Team) nachgearbeitet und hat die vorbereiteten Bretter und Balken in einem Sprint von 6 Tagen in einen voll funktionierenden Dachstuhl verwandelt, das Projekt scheint relativ stabil zu sein. Ich gehe davon aus, dass das Team Test-Driven gearbeitet hat, weitere Refactorings sind derzeit nicht eingeplant.

 

 

 

 

 

 

 

 

 

 

 


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Effective Trainings & Consulting - Martin Dilger



Hat Ihnen dieser Blog-Eintrag gefallen? Ich stelle in diesem Blog Informationen über Tools, Frameworks und Werkzeuge zur Verfügung, die mich produktiver machen. Vielleicht kann ich auch Ihnen helfen, produktiver zu werden.


Ich unterstütze Sie als freier Mitarbeiter bei der Entwicklung von Software-Projekten, Agiler Arbeit sowie Schulungen / Fortbildungen.


Jeden Tag ein bisschen produktiver - ab heute