Sollten User Stories mündlich vermittelt werden?

Bei Agilität ist es eine gute Idee, zuerst an die gewünschten Ergebnisse zu denken und dann über die Methoden nachzudenken, mit denen Sie diese Ergebnisse erzielen können.

Wenn wir einen agilen Ansatz verfolgen, wollen wir großartige Software liefern, aber auch bereit sein, mit eventuellen Änderungen umzugehen. Eine Sache, die dabei helfen kann, ist, nicht zu viel Zeit in das Hinzufügen von Details zu Anforderungen zu investieren, bis sie kurz vor der Bearbeitung stehen. Wir wissen auch, dass wir eine gute Kommunikation und ein gutes gemeinsames Verständnis brauchen, um gut auf Veränderungen reagieren zu können.

Die Idee von User Stories ist es, diese Ergebnisse zu erreichen. Wir können eine User Story mit einer einzigen Textzeile erstellen. Dadurch wird die User Story leicht und kann leicht verstanden werden (für den Product Owner, Stakeholder usw.). Irgendwann möchten wir jedoch, dass das Entwicklungsteam die Funktion erstellt, und sie benötigen weitere Informationen.

Hier kommt der agile Just-in-Time -Ansatz ins Spiel: Wir fügen der Geschichte Details hinzu, bevor wir mit der Erstellung des Features beginnen. Das Timing ist etwas, mit dem das Team experimentiert, bis es das Gefühl hat, ein angenehmes Gleichgewicht zwischen der Anpassungsfähigkeit an Änderungen und der Sicherstellung, dass die Feature-Entwicklung reibungslos funktioniert, gefunden zu haben.

Eine typische Möglichkeit, einer Story Details hinzuzufügen, besteht darin, ein oder mehrere Gespräche zwischen dem Product Owner und dem Entwicklungsteam zu führen. Dieser Prozess kann auch das Hinzufügen schriftlicher Details beinhalten (z. B. Akzeptanzkriterien, UX-Designs usw.).

Dennoch denkt das Management, dass wir ein leuchtendes Beispiel für agile Praxis sind.

Ihr Managementteam glaubt, dass es durch die Übernahme agiler Methoden agil wird. Sie haben gelesen, dass eine User Story nur eine Textzeile ist und dass Gespräche wichtiger sind als eine ausführliche Dokumentation. Sie haben jedoch nicht darüber nachgedacht, warum diese Dinge wichtig sind, oder sie würden ihren derzeitigen Ansatz nicht verwenden.

Was kann ich also vernünftigerweise in der realen Welt von Unternehmen verlangen, die agile Best Practices befolgen?

Es gibt hochkarätige agile Unternehmen (wie Spotify und Salesforce) und zahlreiche weniger bekannte Unternehmen, die einen echten agilen Ansatz verfolgen.

Sie haben die Wahl, entweder diese Unternehmen aufzusuchen oder zu versuchen, einen agileren Ansatz in Ihrem aktuellen Unternehmen zu fördern. Wenn Sie sich entscheiden zu bleiben, würde ich mich darauf konzentrieren, sie dazu zu bringen, über Ergebnisse nachzudenken (und diese zu messen), anstatt blind agilen Methoden zu folgen.

Eine User Story ist ein Versprechen einer Konversation.

Dieser berühmte Satz wurde von einem der Autoren des Agilen Manifests, Alistair Cockburn*, gesagt. Also ja, eine User Story kann ein Einzeiler sein .

Aber sollten Stories nicht spezifisch und umfassend sein, zusammen mit den Entwicklern verfeinert (ready to work, um Mehrdeutigkeiten zu beseitigen) und klar definierte Akzeptanzkriterien haben (Definition of Done)? Und vielleicht eine UX-Spezifikation/Screenshots/Skizzenzeichnungen?

Dies sind keine sich gegenseitig ausschließenden Argumente. Der Schlüssel ist, wann dies jeweils geschieht. Der Produktmanager kann einen Einzeiler schreiben – als Versprechen für ein Gespräch , dieses Gespräch mit dem Team führen und diesen Einzeiler dann gemeinsam zu einer Liste vereinbarter Akzeptanzkriterien erweitern.

Agile Frameworks sind im Allgemeinen absichtlich nicht präskriptiv . Es ermöglicht jedem Team, den besten Weg zur Implementierung zu finden. Es ist traurig, dass die meisten Orte versuchen, das nachzuahmen, was andere Orte tun, und vergessen, dass jedes Unternehmen, jeder Kontext, jede Person einzigartig ist.

Ich habe irgendwo gelesen, dass 95 % der Unternehmen einen „hybriden“ agilen DIY-Ansatz verwenden, was wie eine nette Art zu sagen scheint, dass „wir die Regeln im Laufe der Zeit erfinden“. Unsere aktuellen Praktiken funktionieren bei mir nicht und ich frage mich, ob das Problem bei mir liegt oder ob die Praktiken nicht den Empfehlungen folgen.

Das ist wahr und passiert mehr als es sollte. Es ist jedoch wichtig zu wissen, dass dies geschieht, wenn Benutzer das Framework anpassen, ohne vollständig zu verstehen, warum das Framework einige Praktiken vorschlägt. Das Verständnis von ShuHaRi kann helfen, das Problem zu verstehen, mit dem mehrere Teams konfrontiert sind: Sie ziehen nach Ha, bevor sie das Shu erhalten.

Die Erweiterung auf die bekannten Frameworks wird von Praktikern und Autoren vorgeschlagen . Sie werden Scrum natürlich nicht mehr machen. Aber Sie können immer noch auf Ihre eigene Weise agil sein.

*Es gibt auch einen Tweet von ihm , der darüber spricht, aber der Link ist defekt.

Kurze Zusammenfassung

In meinem aktuellen Unternehmen sind alle User Stories und Aufgaben in einer einzigen Textzeile geschrieben. Alle Details werden mündlich vom Scrum Master / Team Lead geliefert, der separate Gespräche mit dem Product Owner ohne die Entwickler führt.

Aber sollten Stories nicht spezifisch und umfassend sein, zusammen mit den Entwicklern verfeinert (ready to work, um Mehrdeutigkeiten zu beseitigen) und klar definierte Akzeptanzkriterien haben (Definition of Done)?

Um den Kern Ihrer Frage zu beantworten, sollten User Stories (falls verwendet) nicht nur aus einzeiligen Titeln bestehen, es sei denn, sie sind selbsterklärend und die zusätzlichen Details sind für eine effektive Kommunikation über das Arbeitselement unnötig. Ein Großteil Ihrer restlichen Frage riecht nach einem Anti-Pattern für die Framework-Implementierung, da dies einen Mangel an Zusammenarbeit und Kommunikation des gesamten Teams impliziert, aber ich konzentriere den Großteil meiner Antwort auf Ihre Fragen zur Formatierung, Verfeinerung, reden und (am wichtigsten) Backlog Items verwenden .

Methodik für diese Antwort

Da Ihre Frage speziell mit Scrum getaggt wurde , biete ich eine kanonische Scrum-Antwort zusammen mit einigen effektiven Praktiken, die auf meiner eigenen beruflichen Erfahrung basieren. Ich gehe auch auf die Verwendung von Produkt- und Sprint-Backlog-Elementen, User Stories als eine Möglichkeit zur Darstellung von Backlog-Elementen und die Absicht hinter der Verwendung von User Stories (im Gegensatz zu Spezifikationen oder anderen Formaten) ein, um Gesprächsplatzhalter zu erstellen, die die Effektivität der die empirischen Kontrollgrundlagen des Frameworks wie emergentes Design, Just-in-Time-Planung und Inspektions- und Anpassungs-Feedback-Schleifen.

„Agile“ Frameworks anderer Art nutzen oft Scrum oder Scrum-ähnliche Praktiken, daher sollte dies auch für diese Frameworks gelten. Andere Frameworks als Scrum können jedoch eine andere Definition von User Stories verwenden oder Rückstände und Verfeinerungen anders handhaben. In solchen Fällen kann Ihr Kilometerstand variieren.

Benutzergeschichten

Scrum benötigt überhaupt keine „User Stories“. Es erfordert Product Backlog Items (PBIs), obwohl in der Praxis die meisten Scrum-Teams User Stories verwenden, wie sie von Mike Cohn in seinem Buch User Stories Defined oder im allgemein verwendeten Connextra-Format definiert sind . Das Scrum-Team (und insbesondere der Product Owner) kann jedoch jedes gewünschte und nützliche Format für das Product Backlog verwenden.

Laut dem 2020 Scrum Guide :

Product-Backlog-Elemente, die vom Scrum-Team innerhalb eines Sprints erledigt werden können, gelten als bereit für die Auswahl in einem Sprint-Planungs-Event. Dieses Maß an Transparenz erlangen sie in der Regel nach Veredelungsmaßnahmen. Product Backlog Refinement ist der Vorgang, bei dem Product Backlog-Elemente in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine fortlaufende Aktivität zum Hinzufügen von Details wie Beschreibung, Reihenfolge und Größe. Attribute variieren oft mit der Domäne der Arbeit.

Die Entwickler, die die Arbeit erledigen, sind für die Dimensionierung verantwortlich. Der Product Owner kann die Entwickler beeinflussen, indem er ihnen hilft, Kompromisse zu verstehen und auszuwählen.

Was das Scrum- Framework betrifft, ist das alles, was es zu diesem Thema zu sagen gibt. Natürlich hat die jahrelange Umsetzung zu einigen zusätzlichen Überlegungen geführt.

PBIs sollten vor der Sprint-Planung zerlegt werden

Ein PBI muss einfach ein Element sein, das im Product Backlog gespeichert ist. Der Product Owner verwaltet das Product Backlog, obwohl er auch Input von Stakeholdern oder anderen Mitgliedern des Scrum-Teams entgegennehmen kann.

Pragmatisch gesehen sollten Storys am Anfang eines geordneten Product Backlogs vor der Sprint-Planung eine „Definition of Ready“ erfüllen. Dies ist der primäre Tagesordnungspunkt für das Backlog Refinement, das kein formelles Ereignis im Scrum Guide 2020 ist, aber dennoch eine äußerst gängige Praxis ist. Während der Backlog-Verfeinerung arbeitet das gesamte Scrum-Team zusammen, um dabei zu helfen, Epics und Themen für kurzfristige Product-Backlog-Elemente in Elemente zu zerlegen, die besser für die Sprint-Planung geeignet sind. Dazu gehört im Allgemeinen, sie gemäß den Prinzipien der INVEST-Mnemonik in kleinere, besser prüfbare und besser definierte Elemente zu zerlegen .

User Storys sind Gesprächsplatzhalter

Ungeachtet des Formats sollen PBIs, Sprint Backlog-Einträge und User Stories informativ sein , aber sie sind immer noch nur Platzhalter für Gespräche.

Zum Beispiel sage ich den Teams normalerweise, dass eine gute User Story Folgendes identifizieren sollte:

1. Was getan werden sollte (auf zielorientierter Ebene), um zu einem zusammenhängenden Inkrement beizutragen, wie es durch das aktuelle Sprint-Ziel definiert ist. Gemäß dem 2020 Scrum Guide:

   Das Sprintziel ist das einzige Ziel für den Sprint. Obwohl das Sprint-Ziel eine Verpflichtung der Entwickler ist, bietet es Flexibilität in Bezug auf die genaue Arbeit, die erforderlich ist, um es zu erreichen. Das Sprint-Ziel schafft auch Kohärenz und Fokus und ermutigt das Scrum-Team, zusammenzuarbeiten, anstatt an getrennten Initiativen zu arbeiten.

2. Die Entwickler erstellen aus den PBIs ein Sprint-Backlog und legen fest, wie sie das Sprint-Ziel erreichen.

   • Das Sprint-Ziel, die für den Sprint ausgewählten Product-Backlog-Elemente sowie der Plan für deren Lieferung werden zusammen als Sprint-Backlog bezeichnet.

   • Das Sprint-Backlog besteht aus dem Sprint-Ziel (warum), den für den Sprint ausgewählten Product-Backlog-Elementen (was) sowie einem umsetzbaren Plan für die Lieferung des Inkrements (wie).

   • Obwohl das Sprint-Ziel eine Verpflichtung der Entwickler ist, bietet es Flexibilität in Bezug auf die genaue Arbeit, die erforderlich ist, um es zu erreichen. Das Sprint-Ziel schafft auch Kohärenz und Fokus und ermutigt das Scrum-Team, zusammenzuarbeiten, anstatt an getrennten Initiativen zu arbeiten.

Platzhalter unterstützen Emergent Design und Just-in-Time (JIT)-Workflows

Beachten Sie, dass, obwohl das Sprint Backlog einen Plan enthält, wie die Entwickler planen, das Sprint-Ziel zu erreichen, Scrum ein empirisches Framework ist, das sich stark auf emergentes Design und JIT-Planung stützt. Folglich muss der Plan keine detaillierten Spezifikationen oder erschöpfende Details enthalten. Stattdessen enthalten gute User Stories normalerweise:

1. Eine klare Definition of Done für das Arbeitselement , die alles abdeckt, was nicht bereits Teil der umfassenderen Definition of Done ist, die für alles gilt, was das Scrum-Team liefert.
2. Eine klar definierte Gruppe von Wertkonsumenten und -mitarbeitern, wenn möglich. Gemeinsame Stellvertreter wie Rollen, Personas oder andere solche Kennungen helfen den Entwicklern, die Arbeit zu planen und zu koordinieren und ermöglichen es ihnen, sich über laufende Arbeiten zu informieren, um sicherzustellen, dass das, was während der Iteration erstellt wird, die richtigen Eingaben, externen Ressourcen, und ist letztendlich einsatzbereit. Neben der laufenden Zusammenarbeit mit dem Scrum-Team sind dies die Gespräche, die die Backlog-Items eindeutig als Platzhalter für zusätzliche Just-in-Time-Gespräche während des Sprints kennzeichnen sollten.
3. Eine klare Wertaussage, um den Entwicklern bei der Planung der Arbeit Richtlinien, Umfang und Absicht bereitzustellen. Ohne den Warum- Teil gibt es oft Dutzende von Möglichkeiten, ein bestimmtes Feature zu implementieren. Die Wertaussage (im Connextra-Format ist dies die „damit…“-Aussage) hilft dem Team, zwischen mehreren Implementierungspfaden zu wählen, um das definierte Ziel am effektivsten und effizientesten zu erreichen.

Da es sich bei diesen Arten von Backlog Items eigentlich um Platzhalter handelt, kann der Detaillierungsgrad variieren. Wenn jeder im Team bereits weiß, was „embiggen the widget“ beinhaltet, hat es keinen großen Wert, eine lange User Story zu schreiben, um die Einzelheiten zu dokumentieren. Andererseits sagt „den Frobnicator benutzerfreundlicher machen“ nicht wirklich genug darüber aus, was das bedeutet, wer betroffen ist (benutzerfreundlich für wen genau ?), oder was das Problem mit dem aktuellen Frobnicator ist oder wie die Entwickler es tun werden wissen, dass sie das Ziel für die aktuelle Iteration erreicht haben .

Konversationsplatzhalter schaffen Zustimmung und Zusammenarbeit

Da Scrum iterativ und inkrementell ist, ist es weniger üblich, das zu bauen, wonach gefragt wurde, aber nicht das, was benötigt wird, als Frameworks, die sich auf ein umfangreiches, vorab erstelltes Design mit detaillierten Spezifikationen verlassen. Ohne kontinuierliche Zusammenarbeit innerhalb des Teams und mit Stakeholdern oder Endbenutzern sollte das Ziel jedoch darin bestehen, Gesprächsplatzhalter zu nutzen, damit dies seltener vorkommt und dazu beiträgt, dass jeder weiß, dass er an dem teilgenommen hat, was in dieser Iteration geliefert wurde . Wenn sich herausstellt, dass es nicht für den Zweck geeignet ist oder anderweitig überarbeitet oder verfeinert werden muss, kommt dies in Sprint-Reviews und anderen Nicht-Framework-Gesprächen heraus und wird wieder in den Product Backlog-Prozess zurückgeführt.

Dafür sind die Feedbackschleifen des Frameworks da. Konversationsplatzhalter helfen nur dabei, den Explosionsradius von Fehlern zu reduzieren, die dadurch entstehen, dass „User Stories“ als in Stein gemeißelte Spezifikationen behandelt werden.

Mit unterschiedlichem Grad sind alle Unternehmen auf die eine oder andere Weise dysfunktional (und einige mehr als andere), aber jeder denkt, dass es ihm gut geht. Natürlich sind sie es nicht.

Gleiches gilt für Agilität. Jeder "macht" jetzt Agile (meistens die Scrum- Variante oder SAFe , wenn Sie Agile in großem Maßstab "machen"), und jeder denkt, dass er es gut und gut macht. Natürlich sind sie es nicht.

Agilität ist nicht etwas, was man tut, es ist eine Denkweise, es ist etwas, was man ist . Es ist kein ISO-Standard, der eine Formel vorschreibt, die Sie anwenden müssen, oder ein Prozess mit klar definierten Schritten, die Sie befolgen müssen ... und schwupps, das Ergebnis ist garantiert.

Um agil zu sein, muss man denken. Und viele wollen nicht denken.

Um agil zu sein, muss man sich verändern. Und viele wollen sich nicht ändern.

Sie greifen nach irgendeiner Konservenlösung (z. B. Scrum, SAFe) und folgen ihr wie Zombies, die dem Geruch von Blut nachjagen. Sie denken nicht darüber nach, was sie tun, und sie sehen sich nicht dabei zu, wie sie es tun.

Bei Agilität geht es um „Inspizieren und Anpassen“, aber ich sehe selten Leute, die inspizieren oder anpassen.

Damit Agilität erfolgreich ist, muss das obere Management die Einführung unterstützen und ein Umfeld schaffen, das Agilität förderlich ist. Aber sie tun es nicht. Weil sie sich nicht ändern wollen (sie planen immer noch jährlich oder wollen eine sechsmonatige detaillierte Roadmap in Form eines Gantt-Diagramms oder Anforderungsdokumente mit jeweils 100 Seiten, die jeweils von drei verschiedenen Managern zur Genehmigung unterzeichnet wurden, und Fristen, die auf einen bestimmten festgelegt sind Datum in der Zukunft von jemandem, der nicht einmal an der Entwicklung des Produkts beteiligt ist usw.) und sie wollen nicht denken (Funktioniert das, was wir tun? Ja? Nein? Was machen wir gut? Was machen wir nicht so gut? Woher wissen wir, wie wir zwischen den beiden unterscheiden können usw.).

Agilität ist leider zu einem Schlagwort geworden und jeder verwendet dieses Wort jetzt (zusammen mit vielen anderen Änderungen im Wortschatz mit neuen Wörtern wie Scrum Master, Product Owner, Squad, Chapter, Epic, User Story, Story Points usw.). Aber das bedeutet Kniebeugen, wenn Sie in einer starren Denkweise feststecken und sich nicht wirklich ändern wollen.

Also was du beschreibst sieht für mich dysfunktional aus. Und egal mit welchen Worten das Unternehmen beschreiben möchte, was es tut, das macht es nicht weniger dysfunktional.

Sie beschreiben nicht Scrum oder Agile. Und nein, User Stories sollten nicht mündlich überliefert werden.

Sie können ein Gespräch mündlich beginnen, aber dann müssen Sie mehr Details in der einen oder anderen Form festhalten, um sie mit anderen zu teilen (Sie haben einige Beispiele genannt), einfach weil die Leute vergessen oder die Dinge anders verstehen. Und wenn alles durch Mundpropaganda passiert, selbst wenn Sie wie durch ein Wunder bauen, was benötigt wird, wird der Code die einzige Quelle für schriftliche Informationen sein und nicht viele können Code lesen (zumal Sie 50% Manager im Team erwähnen, was eine andere ist seltsames Setup für etwas, das als agil gilt).

Wie ich bereits sagte, sind alle Unternehmen bis zu einem gewissen Grad dysfunktional in ihrer Agile-Implementierung. Sie müssen nur für diejenigen arbeiten, die es weniger sind als andere. Manchmal können Sie anhand des Interviews herausfinden, wie dysfunktional sie sind, indem Sie die richtigen Fragen stellen. Aber leider entdeckt man oft erst, wie dysfunktional sie sind, nachdem man eine Weile dort gearbeitet hat.

EDIT: nachdem die Frage aktualisiert wurde.

Wie viele Details sollten geschrieben und explizit sein? Oder ist es durchaus sinnvoll, dass alle Details implizit im kollektiven Gedächtnis des Teams gespeichert bleiben?

Es kommt auf die Geschichte an. Etwas wie "Als Benutzer möchte ich mich bei der Anwendung anmelden ..." wird wahrscheinlich als Einzeiler verwendet, wobei die Details einfach so etwas wie "Verwenden der branchenweit besten Standards" sein können. Auf der anderen Seite erfordert eine Funktion, die die Berechnung von Versicherungsprämien mit Rabatten und Treueprämien erfordert, wahrscheinlich sehr detaillierte Spezifikationen, bei denen Sie einige Zeit im Voraus verbringen, um Dinge zu klären, aufzuschreiben und sicherzustellen, dass sie richtig verstanden werden, bevor Sie überhaupt schreiben eine Codezeile.

Agile sagt : „Funktionierende Software steht vor umfassender Dokumentation“, also wird die Dokumentation in Agile nach Bedarf (oder just in time) erstellt und enthält gerade genug Details, um ein gemeinsames Verständnis dessen zu unterstützen, was erstellt werden muss. Einige Funktionen benötigen weniger Details, bevor sie erstellt werden können, andere benötigen mehr. Es gibt keine Regel, wo die Grenze zu ziehen ist. Denken Sie jedoch daran, dass die Produktion von mehr als nötig Verschwendung verursachen kann, da Sie entweder die Dokumentation aufgeben, sobald sie ihren Zweck erfüllt hat, sodass Sie weniger in diese Art von Aktivität investieren möchten, wenn Sie sie wegwerfen; oder Sie müssen es während der Entwicklung des Produkts auf dem neuesten Stand halten, und wenn es viel davon gibt, wird es viel Mühe kosten, es auf dem neuesten Stand zu halten). Hier ist also viel gesunder Menschenverstand gefragt; Sie müssen nachdenken, mit Dingen experimentieren, prüfen und anpassen.

Scrum Boards werden oft so dargestellt, als hätten sie nur Haftnotizen. Und vermutlich werden diese Haftnotizen weggeworfen, wenn der Sprint beendet ist. Pflegen solche Teams die Dokumentation also separat oder haben sie gar keine?

Dies sind "Platzhalter", um die Aktivitäten im aktuellen Sprint zu verfolgen und zu verwalten. Die Haftnotizen werden am Ende des Sprints weggeworfen, aber sie enthalten nicht alle Gespräche, die stattgefunden haben, oder alle Details und Materialien, die gesammelt oder erstellt wurden, um dieses Gespräch und das gemeinsame Verständnis zu unterstützen. Also ja, die Dokumentation wird separat gespeichert. Viele Teams verwenden Tools wie Jira oder Confluence, die die Details speichern und nachverfolgen. Selbst wenn Sie ein physisches Board haben, enthalten die Haftnotizen normalerweise nur einen kurzen Titel und eine ID zum Jira-Vorgang, mit der Sie alle anderen Details herausfinden können.

Was kann ich also vernünftigerweise in der realen Welt von Unternehmen verlangen, die agile Best Practices befolgen?

Erstens hast du Recht. Was Sie beschreiben, ist kein Scrum. Nicht einmal nach den wenigen Regeln, die Scrum hat. Wie Fußball spielen mit zwölf Leuten und einer Kettensäge pro Team, es ist knapp , aber auch schrecklich falsch . Das bist nicht du, das sind sie.

Es gibt genug Unternehmen, die Scrum richtig machen. Oder Scrum gar nicht zu machen und seinen eigenen Weg zu finden. Was auch in Ordnung ist. Scrum ist keine Wunderwaffe. Scrum erhebt keinen Anspruch darauf. Das Einzige, worum Scrum bittet, ist, es nicht Scrum zu nennen, wenn Sie sich nicht an die Regeln halten. Und selbst diese einfache Regel scheint in Ihrem Unternehmen nicht befolgt worden zu sein.

Stellen Sie in Ihrem nächsten Vorstellungsgespräch Fragen . Lassen Sie sich von ihnen ihr „Scrum“ beschreiben. Sie werden die Demokratische Volksrepublik Korea weder für eine Demokratische Republik noch für eine Republik oder für ihr Volk halten, also glauben Sie nicht einfach blind, was Ihnen ein Unternehmen über „Scrum“ erzählt. Lassen Sie sie es beschreiben. Fragen stellen. Ein Vorstellungsgespräch ist keine Einbahnstraße. Sie entscheiden, ob sie Sie einstellen wollen, Sie entscheiden, ob es sich lohnt, für sie zu arbeiten . Nutze diese Kraft. Arbeiten Sie nicht für ein Unternehmen, für das Sie nicht arbeiten möchten.

Diese Unternehmen existieren. Sie müssen sie finden.