Teamentwicklungs-Retrospektive - Die Tageszeitung


prozesse teams casestudy

In diesem Artikel betrachte ich rückblickend die langjährige Arbeit am, in und mit einem Softwareentwicklungsteam im Publishing-Umfeld.

In der Theorie der Teamentwicklung klingt vieles so einfach. Die Umsetzung in die Praxis sieht gern anders aus. Deshalb versuche ich neben den positiven Punkten in der folgenden Retrospektive auch, ehrlich und offen die schlechten Seiten zu beleuchten - um ein realistisches Gesamtbild auf den Alltag der Teamentwicklung zu zeigen.

Beginnen wir zum besseren Verständnis mit einer Erklärung des Umfelds.

Die Situation

Das betroffene Team wurde von einem IT-Dienstleister für maßgeschneiderte Softwarelösungen gestellt. Die Kundin war eine überregionale deutsche Tageszeitung. Ziel des initialen Projekts war die Migration des Online-Auftritts und des Online-Redaktionssystems von intern betriebenen Systemen hin zu einer extern gehosteten Cloud-Lösung.

Während dieser Umstellung und noch einige Zeit danach wurde das Team straff geführt durch einen Projektleiter, dessen Stärken und Führungsstil perfekt für die heiße Migrationsphase geeignet waren. In 2018 suchten sowohl der noch amtierende Projektleiter als auch ich neue Herausforderungen und so kam es zur Übergabe des Staffelstabs. Mein offizieller Rollentitel war Projektleiter aufseiten des IT-Dienstleisters.

Unsere Hauptaufgabe nach der Migration waren Betrieb und Weiterentwicklung der o. g. Systeme. Die Weiterentwicklung bezog sich von der Serverlandschaft über neue Anforderungen an das Redaktionssystem und Anbindung von Drittsystemen bis zur Arbeit an der Auslieferung und dem Layout der Webseite. Die Sicherstellung des Betriebs erfolgte rund um die Uhr - außerhalb der Bürozeiten per "Pager Duty"-Bereitschaft.

Alle diese Aufgaben wurden vom hier besprochenen Team gestemmt. Dessen Größe variierte über die Laufzeit je nach Lage und Aufgaben zwischen 12 und 16 Menschen. Drei davon waren feste Admins. Der Rest die unterschiedlichsten Devs. Von Azubi, Werkstudentin, Junior bis Senior war alles dabei und diese deckten fachlich den gesamten Stack ab von Frontend bis Backend.

Das Gesamtteam war dabei in zwei grobe Blöcke geteilt. Das Kernteam - bestehend aus den drei Admins, drei Devs und mir - kümmerte sich hauptsächlich um den täglichen Betrieb, Bugfixes und kleinere Features. Die restlichen Devs bildeten einen Pool, aus dem Projekte verschiedener Größe bedient wurden.

Und all diese großartigen Menschen begleitete ich von 2018 bis 2022. Wie oben bereits beschrieben, war mein offizieller Titel der des Projektleiters. Allerdings mag ich diesen Titel nach wie vor nicht und legte stets mehr Wert auf die Bezeichnungen Organisator und Teamentwickler.

Als Erstes betrachten wir, welche Maßnahmen erfolgreich waren bzw. eine positive Wirkung zeigten.

Was lief gut?

Abgrenzung meiner Rolle

Meine erste Aktion im Team war es, glasklar zu machen, wo die Grenzen meiner Aufgaben und meiner Rolle sind. Obwohl ich ehemaliger Softwareentwickler bin, stellte ich von Anfang an klar, dass ich keinerlei technische Entscheidungen treffen werde. Die Systemlandschaft und die darauf laufende Software sind die Verantwortung und das Ergebnis der Expertise der Devs. Und ich machte deutlich, dass ich mich nicht in ihr "wie" der Umsetzung einmischen werde. Das legte einen wichtigen Grundstein in Hinsicht auf einen Teil der Teamautonomie.

Symbolik des Arbeitsplatzes

Die zweite unmittelbare Änderung betraf meinen Platz im Teamraum. Das Team konnte bis zur Pandemie in nur zwei Räumen zusammensitzen. Mein PL-Vorgänger saß im Zentrum eines der beiden Räume und somit wurde in meinen Augen auch überdeutlich, wie die Kommunikationswege verliefen. Ich verlegte meinen Tisch in eine Ecke. Dadurch konnte ich zum einen besser den gesamten Raum und die Interaktionen beobachten. Zum anderen wollte ich meine Herangehensweise per "leading from the back of the room" buchstäblich sichtbar machen.

Der Prozess

Die dritte Sofortmaßnahme war wieder eine Klarstellung. Da ich vor dem direkten Übergang an mich einige Zeit parallel zu meinem Altprojekt aufgegleist wurde, konnte ich bereits vorab beobachten, wie das Team prozesstechnisch vorging. Und diese Basis erlaubte mir, entsprechend früh zu verdeutlichen, dass der bisherige und zukünftige Prozess weder Scrum ist noch sein wird.

Stattdessen entwickelten wir gemeinsam eine Lösung, die unsere Probleme und Ziele am besten adressierte. Aus Scrum behielten wir die Backlogs, das Daily, feste Iterationen von zwei Wochen samt Review und regelmäßige Retrospektiven. Die Priorisierung und Planung erfolgte kontinuierlich auf täglicher Basis. Abhängig von der Komplexität neuer Anforderungen erfolgte deren Besprechungen entweder ad hoc direkt mit den anfordernden Personen oder in dedizierten Terminen.

Zum Daily gab es zwei interessante Punkte. Zunächst gab es vor meiner Zeit zwei Dailys - je eines für das Kern- und das Projektteam. Das hielt ich für Zeitverschwendung und ein Hindernis beim Teilen von Wissen. Aus diesen Gründen schlug ich dem Team vor, die Termine zusammenzulegen, was wir dann auch gerne umsetzten. Diese Zusammenlegung führte dazu, dass jede:r im Team täglich unsere direkten Ansprechpartner bei der Kundin sprachen. Das waren in Spitze bis zu vier zusätzliche Teilnehmer, die sogar selbst darüber sprachen, was sie an diesem Tag planten und wo sie Hilfe brauchten. Und ja, auch mit 20 Menschen ist es möglich, in den allermeisten Fällen ein Daily in einer Timebox von 20 Minuten unterzubringen. Detaildiskussionen wurden ausgelagert und die sog. "After Daily" für die entsprechenden Besprechungen konnten von allen angemeldet oder eingefordert werden.

Werte, Prinzipien und Zusammensetzung des Teams

Eine themenbezogene Retrospektive nutzte ich für die Manifestation der Werte und Prinzipien des Teams. Ich trat dabei lediglich als Facilitator und Moderator auf. Die kompletten Inhalte entstanden durch die Admins und Devs - am Ende 13 Paare aus Wert und Prinzip, wie das Team mit sich und der Kundin zusammenarbeiten will. Ja, die Ergebnisse kamen als das berühmt-berüchtigte Poster an die Wand und prominent auf die Einstiegsseite unseres Wikis. Es gab weder von mir noch vom Team einen Impuls, diese Grundlage nach einer gewissen Zeit neu zu bewerten. Zudem kann ich mich nicht erinnern, jemals ein Teammitglied explizit auf die Verletzung der Werte und Prinzipien hinweisen zu müssen. Mein Eindruck war, dass wir wirklich "nur" aufschrieben, wie wir tickten und diese Einstellung auch bei Teamänderungen an die Neuen weitergaben.

Denn stabile Teams im Dienstleistungsgeschäft sind leider eine Illusion und so kam es auch zu mehr oder weniger regelmäßigen Änderungen an der Besetzung. Durch eine immerwährende Diskussion mit meiner Führungskraft versuchte ich, diese Veränderungen auf ein Minimum zu begrenzen. Dabei können Teamänderungen Vorteile mit sich bringen. Beispielsweise können dadurch persönliche Weiterentwicklungswünsche bedient werden. Auch bringen frische Blickwinkel und Erfahrungen eine gesunde Unruhe ins Team und können Verkrustetes aufbrechen.

Und Teamänderungen fördern die Diversität. Neben der weiter oben bereits beschriebenen Vielfalt im Team in Hinsicht auf Fachlichkeit und Erfahrung gab es einen Punkt, der mir bei der Einsatzplanung wichtig war: Ich wollte möglichst viele Frauen im Team. Das ist in der IT kein leichtes Unterfangen. Immerhin schafften wir es in der Spitze auf 25 % Frauenanteil. Der Unterschied eines solchen Teams ist deutlich positiv spürbar.

Lernwille und Retrospektiven

Retrospektiven fanden nicht nach jeder Iteration statt, sondern einmal im Monat. Dabei war das Team offen für Variationen der Inhalte. Ich nutzte verschiedene Standardformate, wenn eine grundlegende "gut/ schlecht"-Betrachtung notwendig war. Wenn ein einzelnes Teammitglied, das ganze Team oder ich selbst ein spezielles Thema zu bearbeiten hatten, verwendete ich eine thematische Retro für die genaue Betrachtung. Grundsätzlich hatte ich einen Ablaufplan für jede Retro. Wenn jedoch aufgrund von "Umständen" oder interessanten Entwicklungen die Notwendigkeit oder Chance entstand, wich ich vom Plan ab. Meistens sagte ich dem Team sofort, dass ich den Plan ändern will oder warum ich es getan habe. Die Diskussion darüber, ob das eine gute Sache ist oder nicht, wurde damit Teil der Retrospektive.

Der Lernwille im Team zeigte sich nicht nur im Rahmen der stets zielführenden Retros, sondern auch in verschiedenen anderen Formaten. Neben Branchenstandards wie Code Reviews und situationsbedingtem Pair Programming stachen zwei Initiativen hervor.

Das ist zum einen der von mir initiierte "Lernplan". Dabei handelt es sich um einen vom Team erstellten und sortierten Katalog von Themen, über die das Team mehr lernen möchte. Das reichte von Soft Skills über Prozessthemen bis hin zu technischen Dingen. Jede Session wurde dabei von einem Teammitglied vorbereitet und abgehalten. Den nötigen Raum für diese nicht unmittelbar wertschöpfenden Tätigkeiten schuf ich in meiner Rolle als Projektleiter.

Zum anderen gab es die von einem Teammitglied vorgeschlagenen und konsequent durchgezogenen sog. "Post Mortems". Nach jedem systemkritischen Vorfall, der zu ernsten Problemen und/ oder Ausfällen führte, wurde eine dieser Besprechungen am Folgetag einberufen. Darin besprach das gesamte Team strukturiert, was vorgefallen ist, wie das Problem gelöst wurde, warum es zum Vorfall kam und wie das Problem in Zukunft vermieden wird.

Was in allen Lernformaten auffiel, war das hohe Maß an Sicherheit, die es dem Team erlaubte, offen und sachlich Themen zu besprechen, ohne sich angreifbar zu machen. Besonders stark war dies in den Post Mortems zu spüren, die ausnahmslos vollkommen vorwurfsfrei verliefen.

Übernahme von Verantwortung

Wie weiter oben bereits beschrieben, war in der anfänglichen Migrationsphase ein starker Projektleiter nötig, über den zentral die meiste Kommunikation mit der Kundin lief. Zusammen mit meiner Klarstellung zu meiner Haltung gegenüber technischen Themen versuchte ich sehr früh, diesen Flaschenhals zu beseitigen und dem Team klarzumachen, dass ich gerne über alles Bescheid weiß, jedoch nicht alles entscheide, geschweige denn eine Art Postbote spielen muss.

Meine Botschaft war im Grunde stets, dass Fehler naturgemäß auftreten und wir in einem solchen Fall an einer konstruktiven Lösung arbeiten. (Nur Schlamperei und Schludrigkeit sind Punkte, die ich nicht akzeptiere.) Die Gesamtverantwortung lag schlussendlich bei mir als formalen Projektleiter und damit öffnete ich dem Team einen sicheren Raum zur Entfaltung.

Mit der Zeit, als das Team merkte, dass ich es ernst meinte mit den gegebenen Freiräumen, übernahmen einzelne Devs gerne eigenständig die Verantwortung für Aufgaben und Projekte. Sie kümmerten sich um die Klärung von Anforderungen, die Umsetzung selbst und den Projektfortschritt generell. Natürlich war hier ein wichtiger Faktor, dass auch unsere direkten Ansprechpartner aufseiten der Kundin die direkte Kommunikation mit dem Fachbereich zuließ.

Durch diese ehrliche, offene und partnerschaftliche Zusammenarbeit - siehe hierzu auch die Ausführung zu Werten und Prinzipien - hat sich über die Zeit ein starkes Vertrauensverhältnis aufgebaut. Dies ging teilweise so weit, dass die Devs als Expert:innen zurate gezogen wurden, um Themen Dritter zu besprechen, zu bewerten und zu steuern.

Es ist unser System

Fangen wir mal so an: Der Leitsatz "you build it, you run it" war nicht immer gerne gesehen. Das Team hat das System zu großen Teilen von Dritten übernommen und musste mit entsprechenden Altlasten umgehen lernen. Doch über die Zeit war zu merken, dass die Devs dies auch als Ansporn sahen, unbekannte Gebiete zu erkunden und zu verstehen - und somit Schritt für Schritt die Ownership übernahmen.

Ein wichtiger Schritt hierzu war auch die Übernahme des 24/7-Betriebs durch das Team. Selbstverständlich hat jede Bereitschaftsperson ein hohes Interesse an einem stabilen System, um nicht spätnachts aus dem Bett geklingelt zu werden 😉

Besonders interessant war zu beobachten, dass das Team die Grenzen zwischen dem Kernteam und den Projektteam(s) nicht als starr ansah, wenn es um gegenseitige Hilfe ging. Aus Dienstleistungssicht bringt dies zwar ggf. Klärungsbedarf bei der Abrechnung mit sich, doch das ist ein Schmerz, den ich gerne in meiner Rolle als Projektleiter aushielt, um das Team als Ganzes weiterzubringen.

Das Thema Ownership hatte zudem eine interessante Ausprägung, die ich in Anlehnung an Mob Programming als Mob Bugfixing bezeichne. Erfolgte ein kritisches Betriebsproblem zu normalen Bürozeiten, hat sich stets sehr schnell ein Gruppencall geöffnet, in dem große Teile des Teams zusammenkamen, um an einer Lösung zu arbeiten. Meist waren ein:e Dev und ein Admin dabei in ihren Sachgebieten die Driver, während das restliche Team als Navigator fungierte - oder auch einfach nur zuhörte, um zu lernen.

In Summe entstand so ein Gesamtteam, dass ein System dieser Größe, Komplexität und Kritikalität erfolgreich weiterentwickeln und betreiben konnte. Releases mit entsprechenden neuen Funktionen und Fehlerbehebungen gab es mindestens alle 14 Tage.

Und natürlich gibt es auch Lehren aus Punkten, die nicht gut liefen.

Was lief schlecht?

Fehlende Allparteilichkeit

Das in meinen Augen größte Manko war, dass ich - bedingt durch das Verhältnis von Auftraggeber und Auftragnehmer - die offizielle Rolle des Projektleiters innehatte. Somit war es meine Aufgabe, für eine wirtschaftlich sinnvolle Abarbeitung zu sorgen und auf die Bedürfnisse aller beteiligten Parteien zu achten.

Durch ein hohes Maß an Verantwortungsgefühl führte dies dazu, nicht so sehr loslassen zu können, wie es oft für die Teamentwicklung besser gewesen wäre. Streng genommen konnte ich als Projektleiter nicht als "echter" Teamcoach fungieren, da mir die Allparteilichkeit fehlte.

Besonders deutlich wurde dies durch zwei Punkte. Der erste davon wird etwas weiter unten bei den Prozessen aufgegriffen. Der Zweite betraf das teaminterne Staffing von Projekten.

Ein Dauerthema im vorliegenden Setup war die Besetzung des Kernteams und der verschiedenen Aufgaben mit Projektcharakter. Zu berücksichtigende Faktoren dabei waren u. a. die Einbindung in laufende oder bereits geplante Projekte, Expertise, Wünsche des Kunden und persönliche Entwicklungspfade der Menschen im Team.

Diese Einsatzplanung übernahm ich - selbstverständlich nach diversen Absprachen - selbst. Bei der Kommunikation meiner Entscheidungen war es mir immer wichtig, den Rahmen und die Anforderungen darzustellen und damit die Hintergründe und Beweggründe zu erklären.

Und es war eine vertane Chance zu mehr Teamautonomie. Bedeutend interessanter wäre der Versuch gewesen, dem Team einen Rahmen zu geben und einen entsprechenden Event zu facilitieren, in dem es selbstorganisiert die Besetzung bestimmt.

Feiern von Erfolgen

Ich wuchs in einer Gegend auf, in der die Einstellung "nicht geschimpft ist Lob genug" stark verbreitet ist und man generell nicht mit Erfolgen angibt. Das klingt jetzt wie eine Ausrede, oder?

Fakt ist, dass ich zu wenig selbst Events organisiert habe - bzw. dem Team verdeutlichte, dies selbst zu übernehmen - um die zahlreichen Erfolge angemessen zu feiern oder auch einfach nur so zusammenzukommen.

Das ist auch kein reines Thema der Pandemie. Dieser Zustand war schon vorher sichtbar und physische Distanz ist kein Argument. Es ist einfach ein offener persönlicher Entwicklungspunkt.

9 von 9 auf der Glasl-Skala

Konflikte in einem Team sind vollkommen normal und in meinen Augen für eine gesunde Zusammenarbeit nötig. Wichtig ist, sie rechtzeitig zu erkennen und zu adressieren. In den meisten Fällen ist dies meiner Kenntnis nach mir/ uns im Team gelungen. Bis auf eine Ausnahme.

Die Details dieser Ausnahme bleiben im Team und ich werde sie hier nicht ausbreiten. Tatsache ist, dass ein Konflikt zwischen zwei Devs innerhalb kürzester Zeit so weit eskaliert ist, dass eine Partei bereit war, die Selbstvernichtung in Kauf zu nehmen, um die andere Partei zu schädigen.

Ich bin generell der Meinung, dass ein Teamcoach seine Grenzen kennen muss, wenn es um Konfliktlösung geht. Wir müssen, können und dürfen nicht alles selbst lösen. Wir können zwischen den Parteien moderieren. Die wenigen von uns, die eine echte Mediationsausbildung haben - und ich rede hier von mehreren Wochen oder Monaten Ausbildung und nicht zwei Tagen Workshop - können selbstverständlich auch dieses Mittel nutzen. Ansonsten gilt: Kenne Deine Limitationen und hole Dir externe Hilfe!

Im Fall dieser Eskalation habe ich die Anfangssignale erkannt und in Einzelgesprächen auch adressiert. Doch unter der Oberfläche hat es trotzdem weiter gegärt und explodierte dann sehr schnell. Auch die als Unterstützung hinzugezogenen Dritten versuchten vergebens, eine Lösung zu finden. Schlussendlich vergebens, da eine der beteiligten Konfliktparteien keinerlei Kompromissbereitschaft zeigte bzw. nur die Vernichtung des Gegners als akzeptables Mittel sah.

Die Lösung war letztendlich die Trennung der Parteien und Verteilung in andere Bereiche der Firma. Und zum Glück hatte diese Episode keinen Einfluss auf das restliche Teamgefüge.

Prozesse und Werkzeuge über Individuen und Interaktionen

Es gab zwei Punkte, von denen ich rückblickend denke, dass sie tatsächlich nur mich störten und für den Erfolg des Teams nicht maßgeblich waren.

Punkt 1 war der Ablaufprozess in Jira und die Board-Disziplin der Devs. Ich initiierte mehrere Events, um die Zustände in Jira gut ausgeglichen zwischen "zu grob" und "zu detailliert" auszuarbeiten. Nur: Wozu? Mit welchem Ziel? Mein Argument gegenüber dem Team war stets die Transparenz gegenüber der Kundin, die Sichtbarkeit von Blockaden und der generelle Flow. Wir erreichten nie den Status eines Boards, das "gut genug" ausgearbeitet war und den top-aktuellen Zustand zeigte. Trotzdem hatten wir genug Output und Outcome, um die Stakeholder zufriedenzustellen. Und wenn dem nicht so war, konnten wir offen darüber diskutieren.

Punkt 2 war das Format des Dailys. Das dominierende Vorgehen war nahe am klassischen "gemacht/ geplant/ Unterstützung". Auch hier habe ich mehrmals das Team gefragt, ob sie damit zufrieden sind - was sie waren und keine Notwendigkeit zur Änderung sahen. Im Nachhinein verstehe ich dies auch. Denn das Daily war, auch wenn es zunächst den Anschein hatte, kein reines Reporting-Meeting. Es gab aufgrund der Gesamtteamgröße allen Teilnehmenden eine bessere Übersicht des Gesamtzustandes und trotz der engen allgemeinen Zusammenarbeit gab es Aha-Momente - sei es eine neue Erkenntnis, die Vermeidung eines Konflikts oder das Angebot von Hilfe.

Zusammenfassend muss ich mir die Frage stellen, ob mir hier jeweils der Prozess wichtiger war oder das eigentliche Ziel eines guten Teams. Eine bessere Lösung wäre ein höherer Coaching- statt Beratungsanteil gewesen. Sprich, das Team durch gezielte Frage zu leiten, anstatt durch aktive Eigenarbeit an diesen Themen.

Rast und Rost

Retrospektiv wäre eine intensive Betreuung von 6 Monaten gut gewesen. Gefolgt von einer Phase, in der ich das Team punktuell coache oder berate, um es anschließend wieder eigenständig arbeiten zu lassen. Dieses Modell ist schwer umzusetzen, wenn ein Projekt einen offiziellen Projektleiter braucht - oder genau das wäre die Lösung gewesen: die personelle Trennung der Rollen Projektleitung und Teamcoach.

Alles in allem sind vier Jahre in einem Projekt zu lange. Nach einer so langen Zeit ist man zu sehr Teil des Systems, um noch vernünftig auf das Gesamtkonstrukt blicken zu können. Auch die Wirkung eines Teamentwicklers folgt einer S-Kurve und man muss sich die Frage des Grenznutzens stellen.

Und trotzdem will ich keine Minute mit diesem Team missen, auf das ich wirklich sehr stolz bin.

Fazit

Diese Retrospektive habe ich alleine für mich vorgenommen und entsprechend bin ich mir sicher, dass noch viele Punkte und Details fehlen.

Ich habe in diesen vier Jahren unheimlich viel gelernt und ausprobieren können. Ja, selbstverständlich würde ich heute vieles anders machen. Das gehört auch dazu! Sei es auf fachlicher wie persönlicher Ebene.

Und wenn ich einen einzigen Punkt herauslösen müsste? Diese eine Kernerkenntnis, die mir am wichtigsten erscheint? Dann ist es diese: Nimm Dich selbst nicht zu wichtig. Mache Dich entbehrlich. Das Ziel ist nicht Dein persönlicher Ruhm. Dein Ziel ist ein großartiges Team, das eigenverantwortlich und nachhaltig Wert schafft.

PS

Es gibt eine Geschichte, die ich nicht mehr vergessen werde und die deutlich macht, was das Ergebnis der Arbeit an "meinem" Team bei der Tageszeitung kennzeichnet.

Mit den dedizierten Devs saß ich im Kickoff für ein neues Teilprojekt. Der Auftraggeber dieses neuen Vorhabens bei der Kundin hatte vorher noch nicht direkt mit uns zusammengearbeitet. Nachdem alle fachlichen und technischen Fragen geklärt waren, ging es noch in den organisatorischen Teil über.

Da sagt mir der Projektansprechpartner: "Marco, von Dir erwarte ich dann bald einen Meilensteinplan und wöchentliche Reportings zu Fortschritt und Budget". Ich war zunächst kurz sprachlos. Das war ein Projektsprech, denn ich so schon lange nicht mehr gehört hatte.

Das eröffnete mir die Möglichkeit, etwas auszuprobieren, was ich schon lange mal vorhatte. Es war eine einfache Frage: "Wovor hast Du Angst? Dass wir nicht liefern? Oder zu spät? Dass die Qualität nicht passt? Oder wir das Budget reißen?".

Und die offene wie kurze Antwort: "Ja. Alles davon."

Damit konnten wir arbeiten. Auf das Reporting zum Budget ging ich gerne ein, da ich es aus Gründen der Transparenz sowieso anbiete. Für die restlichen Punkte hatten wir Glück, dass vonseiten der Kundin noch unsere direkten Ansprechpartner dabei waren, die versichern konnten, dass unsere Arbeitsweise kein stringentes, klassisches Projektvorgehen nötig macht.

Schlussendlich "machten wir unser Ding" und führten das Projekt zum Erfolg. Einige Monate später saßen wir in derselben Konstellation wieder im Kickoff zum direkten Anschlussprojekt. Nach der fachlichen und technischen Klärung folgte wieder der Block zur Organisation.

Und von exakt der kritischen Person, die vor einiger Zeit noch ein enges Projektmanagementkorsett von uns verlangte, kam nun diese Aussage: "Ihr macht das schon. Wir vertrauen euch ja."

Buchen Sie jetzt einen unverbindlichen Termin und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.

Vorheriger Beitrag Nächster Beitrag