Donnerstag, 30. Juni 2016

Kommentierte Links (XIV)

Grafik: Pixabay / Geralt - Lizenz
  • Haufe.de: Wie Unternehmen agil werden

  • Den Namen dieses Artikels muss man nicht beachten, darüber wie Unternehmen agil werden wird man hier nicht viel finden. Wesentlich interessanter sind dagegen zwei an dieser Stelle veröffentlichte Zahlen aus der von Haufe durchgeführten Studie "Agilität in deutschen Unternehmen". Denen zufolge halten zwar 70 Prozent der Führungskräfte ihr Unternehmen für agil, von den Mitarbeitern sehen das aber nur 31 Prozent so. Diese Ergebnisse decken sich in etwa mit dem was ich auch angenommen hätte und was ich in verschiedenen Unternehmen bereits gesehen habe: die oberen Hierarchieebenen sind so weit weg von der tatsächlichen Arbeit, dass die blosse Existenz von Sprints oder User Stories sie an die eigene Agilität glauben lässt. Die unteren Dienstränge wissen es besser, werden aber nicht gehört oder ernstgenommen.

  • Georg Meck: Wie wollen wir morgen arbeiten?

  • Zu den in vielen Firmen noch immer unterschätzten Voraussetzungen für agiles Arbeiten gehört die passende Architektur. Die klassischen Einzel- oder Doppelbüros sind im wahrsten Sinne des Wortes betonierte Kommunikationsbarrieren, verschlossene Türen sorgen für Intransparenz, Wohnzimmer-Arbeitsplätze mit Büropflanzen, Bildern und Festnetztelefonen befördern die Herausbildung von Unternehmensbewohnern. Neuartige Open Space-Büros wie in der in diesem Artikel vorgestellten neuen Siemens-Zentrale wirken dem entgegen. Wunder bewirken können sie nicht (einige der unagilsten Unternehmen die ich kennenlernen durfte residieren in luftigen Glaspalästen), aber alleine durch ihre Offenheit und Durchlässigkeit vereinfachen sie die Zusammenarbeit und bringen die Mitarbeiter zusammen. Das ist viel wert.

  • Noah Lorang: Real-time dashboards considered harmful

    Was Noah Lorang da beschreibt kann ein echtes Problem sein: Wenn ein Team die falschen Kennzahlen auf den großen Wandmonitoren abbildet besteht die Gefahr, dass es in Aktionismus verfällt sobald diese zu schwanken beginnen. Dabei ist es grundsätzlich richtig, die richtigen KPIs zu monitoren und dafür zu sorgen, dass sie stabil bleiben. Die Kunst besteht darin, herauszufinden welches die richtigen sind. Einige gute Ansätze werden in dem Artikel genannt: längere Darstellungszeiträume, Interaktionsraten, relative statt absolute Werte und Focus auf hohe statt auf niedrige Abweichungen. Unwichtige Metriken werden dadurch weggefiltert und man sicher sein, dass die angezeigten Zahlen so bedeutsam sind, dass man auf Schwankungen schnell reagieren sollte.

  • Adam Taylor: Why login isn’t the first thing you build

  • Ich gestehe: auch ich habe schon einmal einem Product Owner geraten, die Login-Funktion zum Thema seiner ersten User Story zu machen. Wenn man davon ausgeht, dass man möglichst früh ein Minimum Viable Product will, ist das aber sehr wahrscheinlich falsch. Nach den ersten Stories ist noch so gut wie kein Produkt marktreif und das muss es auch noch gar nicht sein. Es sollte aber bereits so weit sein, dass es dem Auftraggeber, dem Kunden oder einer Testgruppe vorführbar ist, und für diese Zwecke ist ein möglichst großer initialer Funktionsumfang wichtiger als ein vorgeschalteter Login. Dass der später noch gebaut werden muss steht bei den meisten Produkten außer Frage, aber als erstes Feature empfiehlt sich definitiv etwas mit größeren Aha-Effekt.

  • Lafable.com: Large Agile Framework Appropriate for Big, Lumbering Enterprises

  • Eine großartige Parodie auf (pseudo)agile Skalierungsframeworks. In der Theorie klingt das alles nicht schlecht, in der Realität ist es oft nur ein Feigenblatt für Großkonzerne die agil erscheinen möchten ohne ihre "traditionellen" Vorgehensweisen aufzugeben. Wer beide Welten kennt wird es schnell merken - wir sehen hier das klassische Wasserfall/Chaos-Vorgehen mit potemkinscher agiler Fassade.

Dienstag, 28. Juni 2016

Size matters (die umgedrehte Test-Pyramide)

Beim Durchsprechen einer Präsentation für einen unserer Kunden sind ein Kollege und ich zu einer bemerkenswerten Erkenntnis gekommen: die Benutzung der "umgedrehten Test-Pyramide" kann unter Umständen das Gegenteil des gewünschten Effekt bewirken. Um das zu erklären zunächst die Grundlage - das hier ist die Pyramide in ihrer richtigen und in ihrer umgedrehten Form1:


Die richtige Form auf der linken Seite stellt dar wie die Größenverhältnisse zwischen den verschiedenen Test-Arten sein sollten: Sehr viele Unit Tests, weniger Integrationstests und ganz wenige manuelle Tests der obersten Ebene. Die Realität entspricht oft der rechten Darstellung: Viele manuelle Tests, wenige Integrationstests und kaum Unit Tests. Die Präsentation dieser beiden Grafiken soll den Managern des Kunden die Missstände aufzeigen und sie dazu bewegen etwas an ihnen zu ändern. Die Pyramidenform hat sich in diesem Zusammenhang als bewährtes Mittel der Visualisierung erwiesen. Sie lässt sich einfach aufzeichnen, stellt Ebenen und Größenverhältnisse nachvollziehbar dar und ist auch ohne technisches Vorwissen einfach verständlich.

Trotzdem haben wir in dieser Darstellung der beiden Pyramidenformen eine Quelle für Missverständnisse und Fehlentscheidungen entdeckt, und zwar die folgende - beide Pyramiden sind gleich groß. Für eher technikferne Entscheidungsrunden entsteht auf diese Weise der Eindruck, die Testabdeckung wäre in beiden Fällen gleich. Natürlich ist in diesem Zusammenhang offensichtlich, dass die manuelle Ausführung länger dauert, aber das muss ja aus Managementsicht nicht schlimm sein. Ich erinnere mich in diesem Zusammenhang an ein Berliner Startup, dass statt Testautomatisierern manuelle Tester einstellte, da es für das selbe Geld doppelt so viele von denen gab.

Was dabei völlig untergeht ist die Tatsache, dass die rechte Pyramide nicht nur auf dem Kopf steht, sondern, dass ihre Tests in Summe auch eine viel geringere Testabdeckung ergeben, und zwar auch dann noch wenn unproportional viele manuelle Tester eingestellt werden. Weder von der Menge noch von der Frequenz kann eine Ausführung von Hand auch nur in Ansätzen mit einer automatisierten mithalten. In einer guten Präsentation sollte das berücksichtigt werden, ganz einfach dadurch, dass die rechte, umgekehrte Pyramide erkennbar kleiner ist als die linke:


Das alleine kann zwar noch nicht garantieren, dass in den Managementrunden die notwendigen Erkenntnisprozesse stattfinden, es ist aber ein weiterer Baustein. Einer von mehreren die in Summe die klare Botschaft vermitteln sollen, dass die umgekehrte Pyramide etwas schlechtes ist, etwas, dass man so schnell wie möglich loswerden sollte.

1Natürlich ist das eine sehr stark vereinfachte Form, z.B. könnte es noch eine Ebene für automatisierte Oberflächentests geben.

Donnerstag, 23. Juni 2016

Teamübergreifende Konfiguration digitaler Kanban-Boards


Wer sein Board nicht nur in physischer sondern auch in digitaler Form haben will kann mittlerweile zwischen einer ganzen Reihe von Programmen wählen: Jira, Agile Manager, Redmine, Rally, ScrumDo, Trello und viele weitere können benutzt werden und sie alle funktionieren mehr oder weniger gut. Problematisch wird es aber, wenn mehr als ein Team ein gemeinsames Tool benutzt und die verschiedenen Teams unterschiedliche Konfigurationen vornehmen. Findet das ohne gegenseitige Absprachen statt kann man fest davon ausgehen, dass eines der folgenden Probleme auftreten wird:

1. Edit Wars

Der Name sagt eigentlich bereits alles. Ein Team ändert die Konfiguration und verändert damit auch alle anderen Boards. Jemand aus den anderen Teams merkt das und macht es rückgängig, jemand aus dem ersten Team wiederholt die Änderungen, etc., etc., etc. Ein solcher Edit War muss auch nicht notwendigerweise auf irrationaler Sturheit der Beteiligten beruhen - gerade in größeren Firmen, in denen 20, 50 oder noch mehr Teams ein gemeinsames Tool benutzen, kann es sein, dass gar nicht festzustellen ist wer die letzten Änderungen vorgenommen hat. Dem Verursacher sind die Folgen seines Tuns vielleicht gar nicht bewusst, und dass die veränderten Einstellungen ständig zurückgesetzt werden wird eher einem Bug zugeschrieben als einem Kollegen. Ich durfte einmal miterleben, dass die Standardkonfiguration in einer Firma über Wochen immer wieder von Story Points zu Personentagen und von Personentagen zu Story Points geändert wurden. Erst als die gesamte Belegschaft zusammengerufen wurde und alle sich melden mussten die in letzter Zeit Änderungen vorgenommen hatten hörte das Hin und Her auf.

2. Kaputtkonfigurierte Tools

Auch das habe ich bereits mitmachen müssen. Jedes von mehreren Teams hatte spezielle Workflows, die es auf seinem Board sehen wollte. Für die einen waren es Spalten für Rewiew und Release, für die anderen Akzeptanztest und Resolved, wieder andere wollten anzeigen können auf welchen Umgebungen sich die entwickelten Features befanden. Die salomonische Lösung der Admins war, dass alle Wünsche gleichzeitig umgesetzt wurden, so dass die Boards am Ende 17 (!) verschiedene Spalten hatten. Den Entwicklern wurde mitgegeben, dass sie doch einfach nur die benutzen sollten, auf die sich ihre Teams geeinigt hatten, die anderen sollten sie ignorieren. Als wäre das nicht bereits kompliziert genug enthielt die Konfiguration auch noch mehrere Workflows, die beim Verschieben der Tickets einzuhalten waren - zum Beispiel To Do-In Progress-Review-Done, To Do-Design-In Progress-Test-Resolved oder To Do-In Progress-Done-Release. Wenn jetzt ein Ticket versehentlich von In Progress auf Test geschoben wurde statt auf Review konnte der Finale Status nicht mehr Done sein sondern nur noch Resolved. Da die Reports aber nur nach einem dieser Status filtern konnten wurden sie dadurch immer wieder verfälscht.

3. Jenga-Konfigurationen

Im Grunde ein Sonderfall von kaputtkonfigurierten Tools. Vom ersten Eindruck her ist alles in Ordnung, jedes Team hat ein nach seinen Bedürfnissen konfiguriertes Board, alle Workflows funktionieren. Das verborgene Problem tritt auf sobald an irgendeiner Stelle eine zusätzliche Anpassung gemacht wird: wie bei einem Jenga-Turm führt nämlich jede einzelne Veränderung sofort zum Zusammenbruch des Gesamtkonstrukts. Verschiedene Boards benutzen in wilder Kombination verschiedene Workflows, Status, Verknüpfungen und Beschränkungen, und da das alles "historisch gewachsen" ist kann keiner mehr genau sagen welche Einstellung mit welcher anderen zusammenhängt. Irgendeinen Zusammenhang gibt es aber fast immer, im schlimmsten Fall sogar mit ganzen Kaskaden von Abhängigkeiten, so dass eine kleine Änderung ausreichen kann um das Gesamtsystem unbrauchbar zu machen.

Legacy-Systeme

Wenn diese Proble auftreten - wie geht man mit ihnen um? Im Fall von Edit Wars ist es relativ einfach: in den meisten Fällen hilft es wenn die Kommunikation verbessert wird (siehe oben), im schlimmsten Fall muss durch einen Mehrheitsendscheid oder ein Geschäftsführer-Machtwort eine Entscheidung herbeigeführt werden. Anders ist es im Fall von kaputtkonfigurierten Tools oder Jenga-Konfigurationen. In diesen Fällen führt langfristig kein Weg daran vorbei das System wieder zu vereinfachen und zu vereinheitlichen, was häufig in kleinteilige und langwierige Arbeit ausarten kann. Die dafür nötigen Aufwände fehlen dann natürlich bei der Produktentwicklung. Um dem Management begreiflich zu machen, dass sich dieses Investment lohnt empfiehlt sich der Vergleich mit Legacy-Code. Auch der muss schließlich zeitaufwändig refactored werden um wartbar und bearbeitbar zu bleiben. So verargumentiert kann nebenbei sogar noch etwas Vorteilhaftes herausspringen: selbst technikfremde Manager können an diesem Beispiel sehr schön erkennen, welche Auswirkungen technische Schulden haben können.

Montag, 20. Juni 2016

A talk that will inspire your thoughts

Ich gebe es zu, ich bin ein Blender, zumindest manchmal. Um das nötige Scrum Master-Charisma aufzubauen benutze ich von Zeit zu Zeit rhetorische und gestische Tricks um überzeugender herüberzukommen. Teams stehen auf sowas. Manager auch. Und als würde mir ein Spiegel vorgehalten - einiges davon habe ich in dem Video hier wiedergefunden. Zum Schreien komisch und absolut wahr.

Mittwoch, 15. Juni 2016

Scrum Alliance gründet German Chapter

Es geschieht gerade etwas Interessantes hier in Deutschland - die Scrum Alliance gründet eine nationale Unterorganisation, das so genannte "German Chapter".  Verkündet wurde es in dieser Woche per Email.


So wie es aussieht nimmt Deutschland damit eine Vorreiterrolle ein, schließlich wird dieses Chapter der Mail zufolge das erste seiner Art sein. Der weitere Inhalt ist denkbar banal, er enthält neben der hier gezeigten Einleitung nur einen Link zu einer Umfrage zur bevorzugten Sprache (deutsch oder englisch). Gleichzeitig wird aber auch angekündigt, es wäre nur die erste Nachricht von vielen, so dass man gespannt sein kann wie es weitergeht.

Ich bin mir noch nicht ganz sicher was ich von einer nationalen Scrum-Organisation erwarten kann oder will, stehe dem ganzen aber erstmal offen gegenüber. Eine Chance und gleichzeitig auch ein Risiko sehe ich darin, dass versucht werden könnte die Deutungshoheit über den Namen Scrum zu gewinnen. Zum einen könnte das der steigenden Anzahl der unseriösen Berater entgegenwirken, die unter diesem Label auch noch den größten Blödsinn verkaufen (Michael Küsters vergleicht sie nicht ohne Grund mit Wundermittel verkaufenden fahrenden Quacksalbern). Zum anderen besteht aber das Risiko, dass angestrebt wird ein Monopol auf den Begriff zu erheben, was ja anscheinend in Amerika bereits versucht wurde.

Aber wie gesagt, zunächst einmal bin ich offen und neugierig. "Embrace Change" heißt es ja. In dem Sinne - lassen wir uns überraschen.

Montag, 13. Juni 2016

Agile und Scrum funktionieren in diesem Land nicht [egal von welchem wir reden]

Grafik: Wikimedia Commons/Colomet - CC BY-SA 3.0
Zu den interessanten Aspekten eines Berufslebens auf großen IT-Projekten gehört unter anderem, dass man Menschen aus allen Gegenden der Welt kennenlernt. Ich habe schon mit Belgiern, Brasilianern, Chinesen, Engländern, Franzosen, Griechen, Indern, Japanern, Kamerunern, Marokkanern, Österreichern, Polen, Russen, Schweizern, Singapurern, Thailändern, Ungarn und vielen weiteren Nationalitäten zusammengearbeitet. Und so unterschiedlich sie auch waren, in einem waren sie sich oft einig - bei ihnen zu Hause (oder dort wo sie jetzt wären) würden Agile und Scrum nicht funktionieren, das würde mit der Kultur dort(™) nicht zusammenpassen.

An diese Gespräche muss ich denken, wenn ich regelmässig Artikel lese wie Why Agile does not Work In Germany oder Scrum does not work here in Asia. Sie alle (genau wie die oben genannten Kollegen) nennen immer wieder die selben Argumente: Bei uns(™) legen die Menschen zu viel Wert auf Hierarchien, die Gesellschaft ist zu traditionell, es gibt keine Fehlertoleranz, die Firmen sind zu stark durch klassisches Management geprägt. Und darum können dort(™) Scrum und andere agile Methoden nicht funktionieren. Nicht im Startup und nicht im Konzern. Grundsätzlich nicht. Aus Prinzip nicht. Nie nicht. Niemals!

Anders ist es natürlich in anderen Ländern (meistens dort wo man nicht herkommt oder ist). Da ist alles viel besser. Da(™) sind die Hierarchien flacher, die Menschen offen für den Fortschritt, aus Fehlern lernt man, die Firmen erproben neue Management-Konzepte. Aber diese tollen Zustände gibt es natürlich nicht überall, sondern nur in Amerika. Oder in Schweden. Oder in England, Frankreich, Indien, Japan, der Schweiz und Deutschland. Und spätestens jetzt wird klar: alle diese Geschichten sind nichts als grober Unfug.

Zum einen gibt es in jedem Land der Welt Menschen, die hierarchieverliebt, veränderungsablehnend, Fehler-avers und von Command & Control geprägt sind. Sogar im gelobten agilen Land Amerika gibt es sie, einige der un-agilsten Manager die ich jemals getroffen habe kamen aus dem Silicon Valley. Auf der anderen Seite kommen einige der besten Scrum Master und agile Coaches die ich erleben durfte aus Indien, Japan, Russland, Singapur oder anderen Ländern, wo es sie "kulturell bedingt" gar nicht geben dürfte. Kurz gesagt - wer behauptet, in bestimmten Ländern würden Agile und Scrum nicht funktionieren, erzählt Quatsch.

Aber wenn das so ist - warum dann diese Geschichten? Aus meiner Erfahrung gibt es dafür vor allem drei Gründe: entweder um zu erklären, warum man von zu Hause weggegangen ist, obwohl dort eigentlich "alles viel besser ist" (Wetter, Essen, Laune, Leute, etc.). Oder um das eigene Scheitern zu beschönigen. "Scrum funktioniert dort nicht" ist ein viel bequemerer Grund als "Es war von Anfang an eine schlechte Idee, nur billige Junior- und Offshore-Entwickler einzustellen". Häufig aber auch, weil man einen Grund sucht um die eigenen Beratungsdienstleitungen zu verkaufen. "Ja, Ihr habt leider ein kulturelles Problem mit agilen Methoden. Aber mit mir als Scrum Coach kommt Ihr ganz sicher darüber hinweg."

Aber ganz egal warum man erzählt, dass Scrum in einem bestimmten Land aus Prinzip nicht funktioniert - wahr wird es dadurch nicht.

Donnerstag, 9. Juni 2016

Club der toten Teams

Manchmal findet man zufällig bemerkenswerte Dinge. Über einen interessant klingenden Tweet bin ich gestern auf dieses Video hier gestoßen und saß danach eine Stunde lang auf dem Balkon um es anzusehen.



Das Thema des Vortrags ist Motivation, aber er streift auch verschiedene andere Bereiche und enthält immer wieder launige Anspielungen auf IT-Projekte. Und ganz nebenbei ist er ein gutes Beispiel für eine gelungene Powerpoint-gestützte Präsentation. Auch davon gibt es ja viel zu wenige.

Montag, 6. Juni 2016

Eine alternative Festlegung von Sprint-Längen

Bild: Wikimedia Commons/Photobobil - CC BY 2.0
Zu den Besonderheiten Deutschlands gehört sicherlich die Häufung von Feiertagen im Mai. Ostern, Tag der Arbeit, Christi Himmelfahrt, Pfingsten und Fronleichnam folgen relativ kurz aufeinander, weshalb dieser Monat signifikant weniger Arbeitstage hat als alle anderen. Nimmt man noch die Brückentage dazu kann in Summe mehr als eine Woche wegfallen, allerdings nicht auf einmal sondern verteilt.

Für Unternehmen die mit Scrum arbeiten kann das ein Problem sein. In den Mai-Sprints stehen weniger Arbeitstage zur Verfügung, es wird weniger vervollständigt, die Velocity sinkt. Und an dieser Stelle tritt ein Verfälschungseffekt ein: das Sinken der Velocity liegt nicht an sinkender Leistungsfähigkeit sondern eben an den Feier- und Brückentagen. Das lässt sich allerdings aus den Zahlen nicht herauslesen - sowohl in der kurzfristigen als auch in der langfristigen Auswertung wirkt das Absinken wie ein Leistungsabfall. Wenn man jetzt basierend auf der Velocity eine Prognose der verbleibenden Arbeitszeit machen will wird diese unrealistisch niedrig sein.

Ein Unternehmen mit dem ich vor ein paar Jahren zu tun hatte, hatte einen interessanten Weg gefunden mit diesem Effekt umzugehen: Sprint-Längen wurden dort nicht in Wochen festgelegt sondern in Arbeitstagen, z.B. 10 Arbeitstage pro Sprint. Ein Sprint im letzten Mai hätte demnach nicht einfach die Kalenderwochen 20 und 21 umfasst sondern wäre wegen des Feiertages am Pfingstmontag erst am 17. losgegangen und 10 Werktage später am Montag dem 30. beendet worden.

Für jedes Unternehmen das auf diese Weise vorgeht hat die Velocity eine wesentlich höhere Aussagekraft und Brauchbarkeit als für diejenigen, die noch mit Kalenderwochen arbeiten. Auf der Negativseite ist es dafür aber auch so, dass der "gefühlte Rhytmus" aus dem Gleichgewicht kommen kann, schließlich können Planning, Review und Retrospektive jetzt nicht mehr alle zwei Wochen stattfinden sondern gegebenenfalls etwas später. Vor allem bei der Einbindung von Stakeholdern kann das zu Problemen führen.

Andererseits - irgendwelche Probleme gibt es ja immer. Für mich kommt diese alternative Festlegung von Sprint-Längen auf jeden Fall auf die Liste der Dinge die ich irgendwann mal ausprobieren muss.

Donnerstag, 2. Juni 2016

Erziehung zur Normverletzung

Bild: Wikimedia Commons/Indeedous - CC BY 2.0
Vor kurzem hatte ich die Ehre eine Rede von Gregor Gysi anhören zu dürfen und kurz neben ihm zu sitzen. Wie viele Politiker-Reden war sie vom Vortrag her brilliant, vom Inhalt her aber etwas konfus (ich glaube, dass dahinter etwas steckt, was man als "agiles Reden halten" bezeichnen könnte. Das wäre ein Thema für sich). Was bei mir hängen geblieben ist, ist vor allem eine Passage. Sie bezieht sich zwar auf die Sexualmoral der katholischen Kirche, ist aber gut auf Unternehmensführung und Projekt-, bzw. Prozessmanagement übertragbar.

Im Kern erzählte Gysi von einer Unterhaltung mit katholischen Geistlichen, die er mit folgenden Argumenten konfrontierte: Wenn man Sex als etwas ansieht, dass nur zum Zweck des Kinder Zeugens erlaubt ist, dann reduziert sich die Anzahl der im gesamten Leben zulässigen Geschlechtsakte auf eine niedrige zweistellige Anzahl. Das ist natürlich völlig unrealistisch, den natürlichen Trieben folgend ist die Anzahl viel höher, was die Kirche auch weiß. Wenn sie trotzdem an ihren Vorschriften festhält nimmt sie bewusst in Kauf, dass praktisch jeder und jede zigfach dagegen verstößt. Gysi dachte diesen Gedankengang aber noch weiter: wenn die Kirche sehenden Auges dafür sorgt, dass die Menschen permanent gegen eine ihrer zentralen Regeln verstoßen, dann ist das nichts anderes als eine "Erziehung zur Normverletzung". Und diese hat zur Folge, dass der Respekt vor Regeln und Normen grundsätzlich beschädigt wird. Die Konsequenz ist, dass auch andere nicht mehr eingehalten werden.

In Unternehmen, vor allem in großen, kann man genau dieses Phänomen immer wieder vorfinden. Es werden Regeln aufgestellt von denen klar ist, dass sie gar nicht befolgt werden können, weshalb sie von den Mitarbeitern ständig umgangen werden. Die Folge ist dann irgendwann eine konsequente Ablehnung nahezu aller Regeln durch die Belegschaft, die strukturiertes Vorgehen jeglicher Form schwierig bis unmöglich macht (ich hatte schonmal unter dem Namen "Konzern-Anarchismus" etwas dazu geschrieben). Alleine das sollte ein ausreichender Grund sein es sich dreimal zu überlegen, bevor vorschnell irgendwelche Regeln eingeführt werden. Im Zweifel bewirken sie nämlich das Gegenteil dessen was sie bewirken sollen.