Software-Architektur und Agilität

Dieser Blog Artikel ist „Work in Progress“ und könnte sich bisweilen ändern…

Auslöser

Der Impuls meine Gedanken zum Thema aufzuschreiben, entsprang einer lebhaften Diskussion auf Twitter zwischen Leonid Lezner und Boris Gloger: Thread . Herzlichen Dank dafür! Da meine Gedanken zu umfangreich sind auch zu lange „gegärt“ haben, jetzt als Blogeintrag und nicht als Twitterantwort.

Der Architekturbegriff

„Architektur“ ist ein Begriff, der für die Softwareerstellung eine Metapher ist. Im Ursprünglichen Sinn bezeichnet Architektur „Den Aufbau und die Gestaltung von Bauwerken“. Die Assoziation mit dem Bauwerk ist nach wie vor tief verankert, und so sickern weitere Metaphern aus dem „Bauwerk“-Kontext in unsere Vorstellung von „Softwarearchitektur“ ein, die heute vielleicht eher schädlich als nützlich sind: Fundamente die gelegt werden und auf denen alles aufbaut, die Vorstellung von einer langfristigen Stabilität und Nutzung. Das „Big Picture“, der große Gesamtplan der Überblick und Sinnhaftigkeit deutlich macht.

Allerdings ist die Softwarelandschaft heute schnelllebiger geworden. Statt langlebiger Denkmäler ist schnelle, dynamische Reaktion auf wechselnde Prioritäten und veränderliche Märkte und Kunden gefragt. Das Bild des großen Bauwerkes beschränkt dabei unnötig unsere denkbaren Assoziationen. Der Mensch tendiert dazu, innerhalb einer Metapher weiterzudenken. Ich persönlich halte das Architekturbild daher nicht mehr für hilfreich, sondern für hinderlich.

Die Architektur in großen Organisationen

In Konzernen wird geredet von „Pflege der Softwarelandschaft“ oder „Bebauungsplänen“. Es wird viel Zeit und Geld investiert, um die gewachsenen Strukturen zu erfassen, verstehen, konsolidieren und einem zentral gesteuerten Strategie zu unterwerfen. Ich habe allerdings noch nie erlebt, das es funktioniert und belegbar die herbeipostulierten „Business-Cases“ dieser Zentralisierung auch realisiert werden.

Was ich aber erlebe, ist das aus „Zustand A“ ein neuer „Zustand B“ geplant wird, budgetiert wird und in die Umsetzung geht. Drei Jahre später, ist die Umsetzung so auf halbem weg, 20% der alten Landschaft ist weg, der Rest läuft noch weil er ja noch nicht vollständig umgesetzt wird. Das Budget ist zu Ende, die Umsetzung wird langsamer weil 70% der Leute nicht mehr weitermachen dürfen, als man feststellt das die neueste Gartner-Studie den „Zustand B“ als Legacy-Lösung einstuft und man anfängt, den „Zustand C“ mit der aktuell angesagten Technologie zu planen. Also Zeit für einen neuen Bebauungsplan, neues Budget und neue Initiativen, die das aktuelle „Big Picture“ in die Umsetzung bringen sollen. Die Geschichte wiederholt sich…

Ganze Abteilungen werden dem Thema gewidmet. Aus meiner Wahrnehmung ist der Einfluss auf das Tagesgeschäft der Entwickler minimal und wird selten als hilfreiche Unterstützung wahrgenommen, sonder eher als sinnentleerte Belastung.

Wozu eigentlich Architektur?

Die Aufgabe einer „Softwarearchitektur“ ist es, bestimmte Eigenschaften in der Software sicherzustellen. Das ist, allgemein gesprochen, ein Ausschnitt aus den nichtfunktionalen Anforderungen (NFR), wie z.B. Wartbarkeit, Betreibbarkeit, Interoperabilität, Veränderbarkeit und Modularität, Wiederverwendbarkeit, etc.pp. Für viele dieser NFRs bietet sich der Begriff der Architektur gar nicht mal direkt an, da die Anforderungen eher Richtung eines kleinen, temporären, und vielseitig Verwendbaren „Etwas“ gehen, Eigenschaften die man mit einem Bauwerk nicht unbedingt verbindet.

Was könnte man anders machen?

Vielleicht ist eine andere Metapher hilfreicher als das Architekturbild. Ein Garten, in dem man Bäume und Büsche pflanzt? Oder ein Baukasten, in dem man die Steine immer wieder neu zusammensetzen kann? Oder ein Orchester, in dem viele Musiker und Komponisten gemeinsam großartige Musik machen? Oder ein Vogelschwarm, der Schwarmverhalten und Individualverhalten unter einen Hut bringt? Ich habe da noch nicht DIE EINE kraftvolle Metapher gefunden, die für viele Menschen gleichermaßen funktionieren würde, aber andere Begrifflichkeiten auszuprobieren könnte helfen, an das Thema heranzugehen.

Man sollte sich von der Vorstellung verabschieden, ein „Big Picture“ wäre hilfreich. Es braucht immer wieder Anpassungen und Korrekturen, bevor auch nur Teile des Big Picture umgesetzt sind, warum sollte man also so viel Energie in die Erschaffung dieses Bildes investieren? Was man braucht, sind die Rahmenbedingungen innerhalb derer Entscheidungen getroffen werden können, und die Ziele, an denen die Entscheidungen ausgerichtet und bewertet werden können.

Teams und Architektur — Architektur und Teams

Häufig wird Architektur als eine sehr technische Angelegenheit verstanden. Systeme und Technologie stehen im Fordergrund. Dabei ist dieser Aspekt gar nicht mehr der spannendste, da es für viele Aufgabenstellungen gute und bewährte Musterlösungen gibt. Mit Microservice-Konzepten rückt ein anderer Aspekt mehr ins Blickfeld: Die Aufteilung der Teams entlang von fachlichen Abgrenzungen. Da eine Stabilität der Teams eine nicht unerhebliche Rolle bei der „Performance“ von Teams spielt, ist es sinnvoll bei größeren Vorhaben die mehrere oder viele Teams umfassen die fachliche Aufteilung in den Vordergrund zu stellen gegenüber technischen Faktoren. Domain Driven Design kann helfen, das große Vorhaben in „self contained“-Einzelteile zu zerlegen, und entlang dieser Einzelteile können sich die Teams formieren.

Und die Architekten?

Das ist im Moment ein Problem, da Software-Architekt ein „natürlicher“ Karriereschritt für einen Software-Ingenieur zu sein scheint. Raus aus dem Tagesgeschäft von Coding und dem Leidensdruck schlechter Projektentscheidungen, endlich selber am großen Rad drehen und dafür sorgen das es endlich einmal richtig gemacht wird. Leider erfüllt sich dieser Wunsch selten. Die Projekte machen doch was sie wollen, da die Architekten nur lose zugeordnet sind. Die Entwickler empfinden die Architektur als untauglich, als veraltet oder als zu umständlich. Die Architekten ziehen sich in ihren Elfenbeinturm zurück und reden erst gar nicht mehr mit den Entwicklern, sondern produzieren Schaubilder ohne Relevanz. In verschiedenen Konzernen habe ich solche Entwicklungen beobachtet oder das Ergebnis beobachten können.

Was wir statt Menschen in der Rolle „Architekt“ brauchen, sind Menschen in den Teams (also vorwiegend Entwickler) die das Wissen und die Erfahrung und den Gestaltungswillen mitbringen, die Lösungen ihrer Teams mit einem Blick über die Grenzen des Teams hinaus zu Gestalten, für Interoperabilität, der Ausrichtung an strategischen Zielen, und anderen nichtfunktionalen Anforderungen.

Und wenn sich die Rolle des Architekten in der Organisation noch wiederfindet, muss sich das Selbstverständnis deutlich verändern: Vom „Senior Oberchecker“ der den ganzen Junior-Devs die Regeln vorgibt, hin zu einem Mentor der die Entwickler dabei begleitet selber sinnvolle Entscheidungen zu treffen.

Fazit

Aus meiner Sicht ist die Vorstellung einer Softwarearchitektur überholt und in weiten Teilen nicht mehr hilfreich, da er unser Denken ein eine nicht hilfreiche Richtung lenkt. Es ist an der Zeit, eine neue Metapher zu suchen, unter der wir eine Reihe von NFRs zusammenfassen und beschreiben wollen. Insbesonders agile Methoden in der Softwareentwicklung könnten von einer neuen Metapher profitieren.

Der große Bauplan hat sich erübrigt, da auch moderne Lösungsarchitekturen andere und viel dynamischere Möglichkeiten bietet, als es vor 35 oder 40 Jahren der Fall war, als der Begriff der „großen Planung“ in das Software-Engineering Einzug gehalten hat.

Heute ist die Aufteilung eines großen Systems auf handlungsfähige Teams wesentlich bedeutsamer geworden gegenüber der lange vorherrschenden technologischen Betrachtung von System-Design.

Coach Reflection Day

Dieser Beitrag ist „Work in Progress“ und wird sich gelegentlich ändern!

Was ist ein CoRe-Day?

Warum CoRe Day?

Menschen die mit Menschen arbeiten brauchen einen sicheren Raum zur Reflektion und zum Austausch. In vielen „sozialpflegerischen Umfeldern“ wie Pflegeberufe oder Sozialarbeit ist seit Jahrzehnten eine entsprechen berufsbegleitende Arbeit unter dem Begriff „Supervision“ etabliert, die unter ausgebildeter Begleitung einen solchen Rahmen bietet.

In der eher technischen Umfeldern (wie kommerzielle Produkt oder Softwareentwicklung) ist solcher Austausch bislang unüblich. Mit der Veränderung hin zu agilen Arbeitsweisen haben sich auch neue Rollen etabliert, die Menschen in Veränderungen begleiten und Veränderungen in Organisationen gestalten, aber in der Regel keinen geschützten Raum haben um ihre eigenen Themen dabei zu bearbeiten und zu reflektieren. Nachdem dieser Mangel erkannt wurde, haben sich Menschen aus der agilen Community Gedanken gemacht und das Format „Coach Reflection Day“ entwickelt, um diesen Rahmen anzubieten.

Zeitaufwand und Kosten sollten dabei so gestaltet werden, das es den Teilnehmern auch ohne Unterstützung des Arbeitgebers ermöglicht wird, einen solchen Termin wahrzunehmen. Die Kosten liegen daher deutlich unter den üblichen Kosten für einen ganztägigen Workshop in IT-Umfeldern.

Wie läuft ein CoRe Day ab?

Das Intro

Eine kurze Einstimmung ins Thema, oft begleitet von einem kurzen Impulsvortrag mit Coachingbezug

Kollegiale Fallberatung

Ein stark strukturiertes Format zur Gewinnung von neuen Perspektiven zu einem gegebenen Fall. Das Format gewinnt neue Hypothesen und Lösungsoptionen aus der Aussensicht unbeteiligter Kollegen, die häufig sehr konkret helfen Handlungsblockaden aufzulösen.

Coaching Dojo

Das Coaching Dojo ist ein Übungsformat aus verschiedenen Coaching-Ausbildungen. Mit einem echten Fall können Menschen üben, Coaching-Gespräche zu führen.

Walk and Talk

Eine Übung um die Fähigkeiten als Zuhörer zu verbessen.

Open Space / Lean Coffee

Zum Tagesabschluss eine offene Runde, die zur Reflektion oder zur weiteren Bearbeitung von Coaching-Verwandten Themen in kleineren Gruppen genutzt werden kann.

Was kann ich von einem CoRe Day mitnehmen?

Die „Fallgeber“ bekommen in aller Regel hilfreiche und wertvolle Anstöße für den weiteren Umgang mit ihrem „Fall“ aus dem beruflichen Umfeld.

Die Coaches können ihre Fähigkeiten trainieren Coaching-Gespräche zu führen, bekommen dazu wertvolle Rückmeldungen mit denen sie lernen können. Sie können sich trauen, neue Dinge auszuprobieren oder erstmalig gezielt in die Rolle als Coach zu schlüpfen und erfahren wie sie sich darin fühlen.

Die Beobachter lernen auch aus der Beobachtung, und helfen dem Coach sich weiter zu entwickeln. Viele Teilnehmer äußern sich im Anschluss so, das sie aus der Rolle als Beobachter am meisten für ihre eigene Arbeit als Coach mitnehmen.

Links und Verweise

Coach Reflection Day

3. CoRe Day Ruhr am 18. Oktober 2019

 

Organisations-Reverse-Engineering

oder wie Mitarbeiter ihre Zeit damit vertüddeln zu verstehen, wie ihr Unternehmen eigentlich funktioniert.

„Ich habe keine Ahnung“ ist eine Antwort, die ich häufig von meinen Kollegen und Ansprechpartnern in Konzernen bekomme, wenn ich danach Frage wie X oder Y funktioniert. Wie bestelle ich einen großen Monitor oder ein VC-System für den Teamraum? Wie können wir zwei überflüssige Schreibtische entsorgen lassen? Wie bekommen wir einen permanenten Teamraum, statt untauglicher Meetingräume? Mit wem müssen wir reden, wenn wir im Rahmen unseres Projektes einen Prozess ändern wollen, an dem wir andocken oder zu dem wir beitragen?

Dieser Effekt begegnet mir immer wieder. In verschiedenen Branchen. In verschiedenen Ebenen. In Bereichen, die das Arbeitsumfeld unmittelbar betreffen, von Beschaffungen, Einrichtung, und grundlegenden und eigentlich simplen Bedürfnissen.

Für den Alltag der Kollegen hat das leider auf allen Ebenen unerfreuliche Konsequenzen. Sobald sich etwas verändern soll, findet sich niemand, der simple Fragen zur Verantwortung oder dem „richtigen“ Vorgehen beantworten kann. In dem natürlichen Bemühen es richtig zu machen wird dann mehr oder weniger Zeit investiert, um herauszufinden ob und wie das gewünschte Ziel zu erreichen ist. Oder anders formuliert: die Mitarbeiter des Konzerns „reverse-engineeren“ die Abläufe, um herauszubekommen wie sie zum Ziel kommen. Und wenn es immer weniger „operative Routine“ gibt, wie in Projektgetriebenen Organisationen üblich, dann verbringen sie mitunter auch die Hälfte ihrer Arbeitszeit damit, solches organisatorisches Reverseengineering zu betreiben. Die Zeiten, in denen eine Sekretärin als „gute Seele“ Bescheid wusste, oder eben der nächste Vorgesetzte erklären konnte wie es richtig geht, sind lange vorbei.

Ich postuliere: Der Verlust an Wissen über die Prozesse mit seinen Konsequenzen frisst alle Effizienzgewinne durch zentrale Lösungen (Prozesse/Tools) restlos auf.

CAL1 (Certified Agile Leadership 1) Training mit Olaf Lewitz und Alex Kylburg

Dieser Blogbeitrag ist in Arbeit, und mag sich gelegentlich noch ändern, ergänzt oder erweitert werden. Rückmeldungen und Fragen und Kommentare sind jederzeit willkommen!

Vorgeschichte

Mit dem Begriff „Leader“ habe ich ein leichtes Magengrummeln. Ich habe mich selber nie als solcher wahrgenommen und auch wahrnehmen wollen. Selber habe ich mich als Coach und Berater verstanden, aber nie als Leader. Da es in meiner Beratungspraxis aber natürlich immer mal wieder Konflike mit „unagilen“ Abteilungsleitern oder anderen Managern gab, war ich sehr begeistert als ich gesehen habe das die Scrum Alliance an einem entsprechenden Programm arbeitet und erste Trainings zum „Certified Agile Leadership 1“ im Kalender auftauchten. Endlich ein Training für alle die Abteilungsleiter, Gruppenleiter und Management-Menschen, die in einem Scrum Master Training ohnehin fehl am Platz sind.

Als Olaf Lewitz dann seine ersten Trainings angeboten hat, sprach er mich verschiedentlich darauf an, erst für Nürnberg, und dann natürlich erst recht als er in Köln in Zusammenarbeit mit Paragraph 1 ein entsprechendes Training plante. Und nach etwa einem Jahr „Gärungszeit“ war es dann bei mir so weit – Termin, Zeit und Ort waren passend, und ich habe mich kurzerhand mit Alex Kylburg kurzgeschlossen und signalisiert, das ich das Training am 10. und 11. Juli 2018 im Startplatz in Anspruch nehmen wollte und ihn gebeten mir einen Platz freizuhalten. Das CAL1 Training findet sich auch weiterhin im Angebot von Paragraph 1.

Das Training

Die Location „Startplatz“ in Köln kannte ich bereits von anderen Veranstaltungen und habe mich gefreut dort mal wieder zu Gast zu sein. Die Teilnehmer trafen grösstenteils

ein paar Minuten früher ein, und man machte sich bei einer Tasse Kaffee schon mal miteinander bekannt.

Da hing erst mal ein straffes Programm an der Wand als Agenda — gefühlte 25 Arbeitspunkte für die zwei Tage.

 

 

Und kurz nach dem wir gestartet sind ein eine erste Vorstellungsrunde,  eine kleine Gruppenarbeit, ging es auch schon in die erste Reflexion.  Und das war ein Element, das uns erhalten bleiben sollte: immer wieder Reflexion in der Gruppe zum gerade erlebten und gelernten. Immer wieder mit der Triggerfrage „was ist jetzt anders?“ um uns in der Gruppe eine Hilfestellung zu geben, wie wir auch in kleinen Schritten lernen.

Ein weiteres Element, das sich in verschiedenen Aspekten wiederholen sollte, waren „Maps“ – mit einer sehr offenen Visualisierung verschiedener Themen im Bezug auf den Teilnehmer und danach einem Austausch in Paaren entwickelte sich zum einen zunehmend ein wenig Routine im schnellen Visualisieren, und in der Erklärung an den Arbeitspartner eine intensive Reflexion über das gezeigte.

IMG_5932

Die Themen waren breit gestreut, mein Eindruck war das es mehr darum ging eine Idee zu vermitteln, welche Breite Themen rund um „Agile Leadership“ haben und zu inspirieren, als eines der Themen in der Tiefe erschöpfend auszuloten.

Ja, und wie war es jetzt so, das CAL1 Training?

Eine bunte Gruppe von sehr unterschiedlichen Menschen hat ist sich dort begegnet und hat in immer wieder neuen Konstellationen verschiedene Themen bearbeitet. In Maps. In Gesprächen. Verschiedene Modelle zu Leadership-Themen wurden angerissen – zu jedem dieser Modelle hätte man wohl alleine 2 Tage Workshop veranstalten können.

Bodenarbeit

Wir haben sehr viel über das Gelernte reflektiert und es damit greifbar gemacht.

Wir haben viel gelacht.

Wir haben selber Verantwortung für unsere Themen übernommen, und einen Teil des Workshops ausgestaltet.

Was habe ich für mich mitgenommen

  • meine Kontexte bewusst und mit Intention managen: Zeit, Ressourcen, Aufmerksamkeit
  • Temenos: Mein geschützter Raum, in dem Ich sein kann. Und in dem Ich werden kann.
  • Meine Intention macht einen signifikanten Unterschied.

Nach(t)gedanken

Nach den zwei Tagen war ich dann erst mal platt, und habe die Nacht geschlafen wie ein Stein. Ich bin nicht der Mensch, der mit einer neuen Idee unmittelbar losrennt und Neues ausprobiert. In Summe waren viele kleine Details und einige große Anstöße dabei, die nachwirken und auch noch weiter nachwirken werden.

Ein Punkt zum Beispiel, den ich nach einem Mapping mit deutlich mehr Klarheit sehe, ist mein Umgang mit Zeit und mit Zeitplanung: Um Dinge zu tun (egal was), muss man ihnen Zeit einräumen. Wenn ich also etwas tun möchte, fängt es damit an zu überlegen WANN ich es tun möchte, und wie viel ZEIT ich der Aktivität initial einräumen werde. Ein Haltung im Sinne von „ich maches es wenn ich mal Zeit habe“ KANN nicht dazu führen, zielgerichtet und ergebnisorientiert irgendwas anzugehen, egal was.

Nachgedanken 2, im April 2019

Ich habe mich entschieden, auch den umfangreicheren und längeren Weg zum CAL 2 zu beschreiten, auch mit Olaf Lewitz im Rahmen seiner Trust Temenos Academy.

Der interne Kunde

Bei vielen meiner Beratungskunden, die ich als agile Coach oder Scrum Master unterstütze, treffe ich auf den Begriff des „internen Kunden“. Das Entwicklungsteam aus der „Unternehmens-IT“ (oder ein von der IT beauftragter und gesteuerter Dienstleister) baut also irgend etwas, was eine andere Abteilung oder ein anderes Team braucht. Der Begriff „interner Kunde“ wird benutzt, um in der IT deutlich zu machen: Wir arbeiten nicht für uns selber (die Diskussion warum man das für notwendig hält, ist eine andere Geschichte). An sich also keine schlechte Sache, leider ist das nur eine Facette des Systems. Andere Facetten sind z.B. die folgenden:

  • Interne Kunden haben häufig kein Wahlrecht. Sie haben noch nicht mal die Entscheidung über „make or buy“. Sie MÜSSEN die hausinterne IT-Abteilung beauftragen, weil das im Unternehmen halt so läuft, und die IT-Abteilung auch keine externe Konkurrenz bekommen soll (hat der IT-Vorstand so entschieden).
  • Sie müssen das Produkt was erstellt wird auch nicht bezahlen. Das wird in der jährlichen Budget-Planung der IT-Abteilung eingeplant. Eine Kosten-Nutzen Rechnung wie sie ein Kunde normalerweise machen würde, findet nicht ernsthaft statt, eine Auseinandersetzung darüber findet nicht statt und ist auch oft nicht gewollt (Betriebsfrieden und so)
  • Auch ein benachbartes IT-Team in der Wertschöpfungskette wird auch oft als interner Kunde bezeichnet und betrachtet. Das führt häufig zu Systemen, die Lehrbeispiele für Conways Law sind.

Nur weil die Nachbarabteilung jetzt „Kunde“ genannt wird, ändert sich erst mal nix, im Gegenteil: der Begriff verschleiert, das man nach wie vor in Silos denkt und arbeitet, und NICHTS unternommen hat, gemeinsam Probleme zu bearbeiten und zu lösen, die man im Unternehmen hat. Ich beobachte dabei, das der Begriff dazu führt das eine Distanz aufgebaut wird („Die wissen sowieso nicht was sie wollen oder brauchen, wir machen das schon“) und der Begriff zur Abgrenzung genutzt wird, als das die Zusammenarbeit mit den Kollegen davon profitiert. Eine gemeiname Sicht auf Unternehmensinteressen oder die Wertschöpfungskette wird verhindert, jeder denkt nur bis zum Tellerrand.

Wie erlebt ihr den Begriff „interner Kunde“ in eurem Alltag, ist das ein hilfreiches Konstrukt oder ein klassisches Beispiel für Neusprech? Ich freue mich, wenn ihr einen Kommentar hinterlasst.

Es ist in Ordnung…

Inspiriert von dem großartigen Impuls von „Its ok to say what is ok“ der GDS, habe ich die Liste ins Deutsche übersetzt. Es kann einem neuen Mitarbeiter helfen zu verstehen, wie ihr neues Umfeld funktioniert, und es machte alle darauf aufmerksam, wie viele Dinge wir implizit annehmen, ohne das sie irgendwo explizit vereinbart sind. Diese Liste kann ein Beispiel für eine solche Vereinbarung sein.

Es ist in Ordnung…

  • zu sagen „ich weiß es nicht“
  • um mehr Klarheit zu bitten
  • zu Hause zu bleiben, wenn ich mich krank fühle
  • zu sagen „ich verstehe das nicht“
  • zu fragen wofür Abkürzungen stehen
  • zu fragen warum, und warum nicht
  • Dinge zu vergessen
  • sich selber vorzustellen
  • vom Team abhängig zu sein
  • um Hilfe zu bitten
  • nicht alles zu wissen
  • einen stillen Tag zu haben
  • einen lauten Tag zu haben, zu lachen, zu reden und Späße zu machen
  • die Kopfhörer aufzusetzen
  • „Nein“ zu sagen, wenn Du zu beschäftigt bist
  • Fehler zu machen
  • zu singen
  • zu seufzen
  • nach Feierabend keine E-Mails zu lesen oder zu bearbeiten
  • während der Arbeitszeit nicht ununterbrochen E-Mails zu lesen
  • mal Leerlauf zu haben
  • herüberzukommen und jemanden persönlich anzusprechen
  • irgendwo anders hinzugehen, um sich zu konzentrieren
  • Feedback zur Arbeit anderer Menschen anzubieten
  • Dinge zu hinterfragen, mit denen man sich nicht wohlfühlt
  • „ich auch“ zu sagen, wenn jemand Kaffee holt
  • lieber Tee zu trinken
  • einen Snack zu essen
  • einen unaufgeräumten Schreibtisch zu haben
  • einen aufgeräumten Schreibtisch zu haben
  • zu arbeiten wie Du es gern hast
  • das Management zu bitten Probleme zu beheben
  • Pechtage zu haben an denen nichts läuft wie geplant
  • freie Tage zu haben