Montag, 31. August 2015

Kommentierte Links (IV)

Grafik: Pixabay / Elisa Riva - Lizenz

Daniel Ek: Sorry

[Edit: alter Link ist tot, neue Verlinkung führt zu einem Medienbericht] Wer schon einmal dabei war als eine größere Anwendung agil (weiter)entwickelt wurde kennt das folgende Vorgehensmuster: Statt wie im Wasserfall-Modell von Anfang an alle Funktionen und damit auch alle dafür nötigen Berechtigungen festlegen zu wollen geht man schrittweise vor - Features werden nach und nach erdacht und implementiert, weshalb auch immer wieder die Berechtigungen angepasst werden müssen. Im schlimmsten Fall passiert dann das was diesen Monat Spotify zugestoßen ist: Journalisten die ohne technisches Verständnis aber dafür mit großen Vorteilen unterwegs sind erfahren davon, verzichten zugunsten des schnellen Skandals auf Recherche und feuern eine sachlich falsche "Enthüllungsgeschichte" in die Öffentlichkeit. In diesem Fall die, dass Spotify zukünftig nur noch für diejenigen Kunden nutzbar sein wird, die dem Unternehmen Zugriff auf private Fotos, Adressbücher und ähnliche persönliche Daten geben (Beispiel hier). Als Reaktion auf diesen de facto-Rufmord bleiben nur noch öffentliche Erklärunge wie diese hier von Spotify CEO Daniel Ek.

Wirtschaftswoche: So geht gute Führung

Ohne explizit auf Scrum & Co einzugehen beschreibt Daniel Rettig einen zentralen, aber wenig beachteten Aspekt agiler Methodiken: eine schnelle Reaktion auf sich ändernde Bedingungen schließt nicht nur die Softwareentwicklung ein sondern auch die Personalführung. Statt über ein ganzes Jahr hin Wohl- und Fehlverhalten zu sammeln und zu dokumentieren um sie dann zum Jahresende dem Angestellten massiert unter die Nase zu reiben sollten derartige Gespräche immer sofort dann geführt werden wenn ein Bedarf erkennbar ist. Es gibt sogar einen eigenen, regelmässig stattfindenen Meeting-Typ dafür, die Retrospektive. Und um Selbstorganisation zu fördern und demütigende Momente zu vermeiden sitzt hier auch nicht ein Untergebener seinem Meister gegenüber sondern es wird auf Augenhöhe diskutiert. Das führt nicht nur dazu, dass Verbesserungen schneller erreicht werden, es verhindert auch die vergiftete Atmosphäre, die während der Zeit der Jahresgespräche ganze Abteilungen und Unternehmen verpesten kann.

Visage.co: Mind the Burndown, Comrade [Edit: Link ist mittlerweile tot]

Retro geht immer. In diesem Fall Scrum-Poster, die den politischen Propaganda-Plakaten der 20er bis 50er Jahre nachempfunden sind. Große Buchstaben, einfache Slogans, kantige Optik und starke Farbkontraste sind großartig geeignet um die schlichten aber tiefgreifenden Leitlinien der Agilität zu vermitteln und präsent zu halten. Plakativ im wahrsten Sinne des Wortes.

Payton Consulting: The Agile Way to Fix Your Documentation Problems [Edit: Link ist mittlerweile tot]

Ich mag diesen Eintrag aus mehreren Gründen: Zum Einen gibt er einen guten Überblick über das Elend der Dokumentation in den meisten IT-Projekten, in denen Dokumente nicht erstellt werden weil sie von irgendwem gebraucht werden, sondern weil es "Pflichtergebnistypen" sind, bei denen es auch egal ist wenn es es sich um aufgeblähten, unleserlichen Mist handelt. Zum Anderen widerspricht er dem häufigen Missverständnis, dass in Scrum nicht dokumentiert wird (das Gegenteil ist der Fall: wenn zum Minimum Viable Product Dokumentation gehört muss sie im Sprint erstellt werden, aber eben auch nur dann). Zum Dritten zeigt er Lösungswege auf wie diese Arbeit besser und effektiver erledigt werden kann und zuletzt ist er wunderbar grafisch aufbereitet, selbst wenn das dazu führt, dass man ewig scrollen muss.

Gidion Peters: Warning: #agile may break if not handled with care!

Ich musste lachen.

Donnerstag, 27. August 2015

Zu viel Zeit und zu viele Post-its

Eine verhängnisvolle Mischung.

Dienstag, 25. August 2015

Konzern-Anarchismus (und was macht man dagegen?)

Bild: Flickr/JDHancock - CC BY 2.0

Nicht alle Einführungen von Scrum oder anderen agilen Methoden sind Erfolgsgeschichten. Bereits mehrfach durfte ich aus der Nähe miterleben wie agile Transitionen gescheitert sind. Die Gründe dafür sind nicht etwa einzigartig und einzelfallbezogen (obwohl das natürlich immer wieder behauptet wird) sondern treten fast immer als die Variationen einiger weniger Grundmuster auf: ein Management das der Idee selbstverwalteter Teams nicht traut und ständig "reinregieren" will ist ein Klassiker, Stabspositionen wie der Lead Developer oder der Testmanager die die Methode sabotieren weil sie ihre Existenzberechtigung gefährdet sehen sind ein weiterer. Ein dritter entfaltet aber eine besonders verheerende Wirkung: die Unwilligkeit und Unfähigkeit praktisch aller Betroffenen sich an Regeln jeglicher Art zu halten, solange diese nicht mit Zwang und Sanktionsandrohungen eingeführt werden. Da dieses Phänomen vor allem bei den Mitarbeitern großer Unternehmen auftritt würde ich es als "Konzern-Anarchismus" bezeichnen.

Auf den ersten Blick mag das überraschend erscheinen - gerade Konzerne sind es doch, die ihre Mitarbeiter mit zahllosen Vorschriften, Vereinbarungen, Richtlinien und sonstigen Vorgaben überhäufen, und das nicht etwa aus bösem Willen, sondern aus dem Irrglauben heraus, dass derartig "angeleitete" Angestellte besonders produktiv wären. Und gerade Konzerne haben es doch perfektioniert jeden Widerstand gegen derartige Vorgaben konsequent zu brechen. Wie kann es also sein, dass ausgerechnet diese Angestellten konsequent jede Regel zu unterlaufen versuchen? Müsste nicht ihre gesamte berufliche Sozialisation in die genau andere Richtung geführt haben, in eine Art "Untertanenhaltung", in der alle Vogaben kritiklos angenommen und folgsam umgesetzt werden?

Leider nein. Die bemerkenswerte Wahrheit ist nämlich, dass sich diese Vorschriften meistens gar nicht umsetzen lassen. Es ist schlichtweg nicht möglich immer zeitgleich mit Hochleistung zu arbeiten, Leerlauf zu vermeiden, die eigenen Tätigkeiten und Produkte detailliert zu dokumentieren, zu Produkt- und Prozessverbesserungen beizutragen, Planziele zu erfüllen, Termine, Kostenrahmen und Qualitätsstandards einzuhalten, Wissen weiterzugeben, Überstunden zu vermeiden und "die Unternehmensvision zu verinnerlichen". Immer werden einige dieser Teilziele in Widerspruch zueinander stehen und sich gegenseitig verhindern. Da aber fast jedes dieser Teilziele von einer anderen Abteilung kommt (Personal, Compliance, Recht, etc.) und jede ihr Teilziel als besonders wichtig und unverhandelbar ansieht, steht am Ende der Angestellte vor der Wahl: entweder er macht heimliche und unbezahlte Überstunden (was schnell zum Burnout führt) oder er beginnt systematisch die Vorgaben zu unterlaufen und hält sich nur noch an sie wenn er explizit dazu gezwungen wird.

Natürlich bleibt das auf Dauer nicht verborgen. Anstatt in sinnvoller Weise zu reagieren und die Arbeits- und Vorschriftenlast herunterzufahren werden in vielen Firmen aber immer weitere Vorschriften und Kontrollmechanismen erdacht und zusätzlich auf die Bestehenden gepackt, um so Regelabweichungen zu verhindern. Das Problem: da die bestehenden Widersprüche so nicht aufgelöst werden stehen die neuen Regeln automatisch in Widerspruch zu einem Teil der alten. Mit jeder dieser "Verbesserungsrunden" wird es also unmöglicher alles zu tun was vorgeschrieben ist, wodurch die Mitarbeiter immer neue Wege erfinden, diesen Regeln auszuweichen. Es ist ein Wettlauf den keiner gewinnen kann. Und an dieser Stelle wird ein agiles Framework wie z.B. Scrum eingeführt.

Natürlich erscheint das den Betroffenen wie der X-te Versuch das Problem zu vieler Regeln durch die Einführung von noch mehr Regeln zu lösen. Und selbstverständlich reagieren sie darauf mit den Notwehr-Mechanismen, die sie seit langem eingeübt haben: Abblocken, Unterlaufen, Verzögern, Verwässern und Aussitzen. Das Bemerkenswerte daran - häufig ist das auch die einzig richtige Option. Dann nämlich, wenn die neue Methode die alte nicht ersetzt sondern zusätzlich zu ihr eingeführt wird. Wenn es z.B. heisst: "Wir machen schon Scrum, nur mit Konzeptionsphase und der bewährten Feinspezifikation." Oder "Wir machen schon Scrum, aber mit eigenen Test- und Hardening-Sprints als Ersatz für die Test- und Bugfixing-Phasen." Eine Scrum-Wasserfall-Kombination funktioniert nämlich genauso wenig wie der alte Überregulierungsansatz.

Aber nehmen wir nicht diese Negativ-Fälle sondern gehen vom Positiven aus: das Management hat dazugelernt, der Vorschriften-Overhead wurde abgebaut, es wird wirklich versucht agil und lean zu arbeiten. Und trotzdem stellen die Mitarbeiter sich quer, weil sie es schon zu oft gehört haben, "dass es diesesmal wirklich anders ist" und nicht mehr an solche Versprechungen glauben. Was ist jetzt zu tun? Ich würde an dieser Stelle folgende Maßnahmen empfehlen:

  • Aufzeigen klarer Grenzen. Selbstverwaltet ist etwas anderes als Beliebigkeit, und bestimmte Dinge (z.B. incrementelles Arbeiten, intensive Kommunikation und kurze Feedback-Schleifen) sind nicht verhandelbar. Dabei sollte aber auch aufgezeigt werden in welchen Bereichen das Team tatsächlich selbst entscheiden kann (z.B. bei der Frage wie viel Arbeit es in den nächsten Sprint nehmen will).
  • Visualisierung des Regel-Abbaus. Alle alten, abgeschafften Vorschriften auf ein Board, die neuen, schlanken auf ein zweites, das zum Vergleich danebensteht. Das bringt auch einen weiteren Vorteil: wenn jemand heimlich oder versehentlich wieder widersprüchliche Regeln einführen will wird das hier transparent sichtbar gemacht.
  • Thematisierung in Einführungs-Workshops und Retrospektiven. Warum machen die Regeln diesesmal wirklich Sinn und warum wird das Arbeiten durch sie diesesmal nicht unmöglich gemacht? Natürlich muss dabei zu Vergleichszwecken auch angesprochen werden warum die alte Methode Mist war. Das gefällt im Zweifel nicht jedem, lässt sich aber nicht vermeiden.

Mit diesen und ähnlichen Methoden kann es gelingen, den Konzern-Anarchismus nach und nach in eine Commitment- und Verantwortungskultur überzuführen. Man muss sich aber eines bewusst machen - es kann dauern. Eine Geisteshaltung die in Jahren, vielleicht sogar in Jahrzehnten entstanden ist ändert sich nicht in einem Sprint oder in einem Monat. Ein befreundeter Scrum Master erzählte mir einmal von einem Übergang den ein Team erst nach Jahren abgeschlossen hatte. Das mag ein Extremfall sein, aber mehrere Monate braucht man auf jeden Fall mindestens dafür. Die sind dann aber auch gut investiert.

Freitag, 21. August 2015

Einhundert mal Lean Coffee Cologne


Es gibt Jubiläen die bemerkenswert sind, und dieses gehört mit Sicherheit dazu - zum einhundertsten mal fand heute der Lean Coffee Cologne statt, der seit über zwei Jahren fast wöchentlich in Köln ausgerichtet wird. Umso bemerkenswerter wird das Ganze wenn man bedenkt, dass das alles freiwillig und ehrenamtlich organisiert wird, keinen komerziellen Hintergrund hat, pünktlich um acht Uhr morgens beginnt, auf eine Stunde timeboxed ist und trotz wachsender Popularität von niemandem zu Vertriebszwecken missbraucht wird.

Als wöchentliche Veranstaltung ist der Lean Coffee die bei weitem häufigste unter den agilen Veranstaltungen im Raum Köln/Bonn und erfüllt damit gleich mehrere Zwecke: er ist einerseits eine Verbindung zwischen den "agilen Verrückten" der Stadt, die sich hier regelmässig treffen können, zum anderen bietet er durch die ständig wechselnden Ausrichter immer neuen Leuten die Möglichkeit mit der Lean/Agile-Szene der Stadt in Verbindung zu kommen. Dass die Lean-, Scrum- und Agile-Meetups am Rhein mittlerweile eine Frequenz und Intensität erreicht hat auf die auch Hamburg, München und Frankfurt neidisch sein können hat ganz wesentlich mit dem Lean Coffee zu tun.

Vielen Dank @Boeffi für die Orga-Arbeit der letzten Jahre, Glückwunsch und viel Spass dem neuen Orga-Team und ein Toast in Vorfreude auf die nächsten 100, von denen ich sicher einige besuchen werde.

Dienstag, 18. August 2015

We code hard in these cubicles

Da mir gerade wieder ein Entwickler mit der interessanten Ansicht gegenübergetreten ist, dass sein Beruf dem eines "modernen Rockstars" (!) entsprechen würde - hier ein kleiner Einblick in seine Gedankenwelt.

Donnerstag, 13. August 2015

Ein Bild sagt mehr als 1000 Worte (V)

Eine Aufgabe an der die meisten Projektmanager scheitern

Donnerstag, 6. August 2015

Reliable Ultimate Secure Bullshit Scrum

Stellen wir uns kurz die folgende Situation vor: jemand hat noch nie in seinem Leben ein Messer benutzt und beginnt es zu erlernen. Mangels Erfahrung geht er es falsch an, nimmt die Klinge in die Hand, setzt den Griff auf ein Stück Brot und legt los. Das Ergebnis ist verheerend: die Hand ist verletzt, das Brot nicht geschnitten, der Mensch frustriert. Was sollte jetzt getan werden?
  1. man sollte ihm beibringen das Messer richtig zu benutzen oder 
  2. man sollte versuchen, für ihn ein Messer so zu modifizieren, dass der Griff schneidet und von der Klinge keine Verletzungsgefahr ausgeht.
Die Antwort ist so naheliegend, dass sie nicht verraten werden muss.

Stellen wir uns kurz eine andere Situation vor: ein Unternehmen hat noch nie agil gearbeitet und führt Scrum ein. Mangels Erfahrung geht es in den Stories nur um funktionale Anforderungen, nichtfunktionale Anforderungen wie Sicherheit oder Performance werden vergessen. Wenn das (zu spät) entdeckt wird brechen Hektik und Streit aus, Sicherheit und Lastfähigkeit werden unter Hochdruck und mit Überstunden in die Anwendung gepresst, darunter leiden Qualität und Dokumentation, das Ergebnis ist unbefriedigend. Was sollte jetzt getan werden?
  1. man sollte dem Unternehmen beibringen, dass auch nichtfunktionale Anforderungen durch die Product Owner identifiziert, als User Stories formuliert, im Backlog priorisiert und in Sprints umgesetzt werden können
  2. man sollte für dieses Unternehmen Scrum so modifizieren, dass die nichtfunktionalen Anforderungen durch zusätzliche, redundante Prozesse eingeführt und durch bürokratisches Controlling verifiziert werden
Die Anwort ist auch hier naheliegend, zumindest für jeden der größere Unternehmen von innen kennt: Option B ist richtig - mehr Prozesse und mehr Bürokratie sind eine bessere Lösung als das Anwenden der Methode so wie sie eigentlich gedacht ist (um Irritationen zu vermeiden, das war gerade Ironie).

Diese Modifikationen von Scrum haben Namen: Reliable Scrum, Ultimate Scrum oder Secure Scrum sind Beispiele, wenn es um die Skalierung geht könnte man auch weitere nennen, wie z.B. Autoscrum. Ihnen allen ist gemeinsam, dass sie auf eine falsche Verortung der Probleme zurückgehen - nicht die gestiegene technische Komplexität, die schnelleren Evolutionszyklen der IT oder die hohen und ständig wachsenden Benchmarks der Konkurrenzprodukte werden als die Ursache für sich ständig ändernde Anforderungen gesehen, stattdessen sieht man den Grund in zu geringer langfristiger Planung, zu wenig Aufgabenteilung, zu wenig Kontrolle und zu wenigen Qualitäty Gates. Verkürzt gesagt - man sieht das Problem darin, dass Scrum nicht wie die Wasserfall-Methodik ist. Es folgt die Umkehr des sinnvollen Vorgehens: statt für das Problem (gestiegene Komplexität und Änderungs-Häufigkeit) die passende Lösung (Agilität) zu finden nimmt man die neue Lösung, entkernt sie, füllt die Leerräume mit den altbekannten aber leider nur bedingt funktionierenden Methoden (Bürokratie, Kontrolle, Hierarchie, etc.) und erwartet, dass das Problem allein durch das Anbringen eines Agile-Label auf den "bewährten" Vorgehensweisen verschwindet.

Leicht verstört könnte man sich jetzt fragen, wie irgendjemand auf die Idee kommt, dass das bloße Umbenennen ineffektiver Methoden zu besseren Ergebnissen führen soll. Die Auflösung: hinter derartigen Vorgängen stecken fast immer zwei Gruppen - zum einen altgediente Mitarbeiter, die Komplexität und Agilität für vorbeigehende Moden halten, denen man durch Etikettenschwindel und "Überwinterung" entgehen kann, zum anderen Unternehmensberater, die die Sehnsüchte dieser Menschen ausnutzen indem sie ihnen vorgaukeln, ihr "verbessertes Agile" biete die Lösung aller Probleme, ohne die Notwendigkeit etwas anderes als ein paar Bezeichnungen für Meetings und Rollen ändern zu müssen.

Leider werden oftmals auf diese Weise genau die Ansätze als Lösung eingeführt, die die Probleme erst richtig befeuern: Planen für die Papiertonne, Ersticken der Produktivität in Dokumentations- und Reporting-Overhead und Verschieben der Arbeit an echten Lösungen in die Zukunft. Das Fatale - bedingt durch (z.T. verordnete) Anfangseuphorie und die Einstellung, dass man dem "neuen" Vorgehen erstmal etwas Zeit geben müsste ("bis es von allen verstanden worden ist") und so lange "die guten Seiten hervorheben sollte" häufen sich zunächst die Erfolgs- und Jubelmeldungen. Wer auf die negativen langfristigen Folgen hinweist gilt als Pessimist, Miesepeter und Blockierer. Wenn die Probleme sich dann türmen werden sie möglichst lange kleingeredet, in der Hoffnung, dass der versprochene Erfolg diese "Kinderkrankheiten" ausgleichen wird. Irgendwann geht auch das nicht mehr, es gibt einen großen Knall und der Offenbarungseid steht an - ohne Projektstop und langwierige Renovierungsarbeiten an Prozess und Produkt kann das Ergebnis der letzten Jahre nur noch weggeworfen werden.

Gut, dass für einen solchen Fall ein Plan B in der Schublade liegt: Man muss nur beim Management deutlich machen, dass man "dieses Agile" von Anfang an für obskur gehalten hat. Nur dadurch, dass man möglichst viel des guten, alten Wasserfall-Vorgehens in die neue Methode gerettet hat konnte überhaupt sichergestellt werden, dass es nur schlimm wurde, und nicht ganz schlimm. Wenn man es schafft damit gehört zu werden, steht dem großen Endziel nichts mehr im Weg - der triumphalen Rückkehr in den gemütlichen alten Betonsarg der Routinen "die wir schon immer so gemacht haben". Dann gilt es nur noch Insolvenz und Standortschließungen so lange herauszuzögern bis die Rente da ist. Und was danach mit dem Unternehmen passiert - ist das Problem anderer Leute.

Dienstag, 4. August 2015

Responding to change over following a plan does not imply not having a plan

Bild: Startup Stock Photos - CC0 1.0
Ein wunderbares Zitat, gefunden im Blog von Steve McConnel. Wunderbar deshalb weil es auf einen der beliebtesten (Pseudo)Kritikpunkte an Scrum und/oder Agile eingeht, der da lautet, dass in diesen Methodiken nicht geplant wird. Das Gegenteil ist richtig, was auch einfach zu erklären ist: ohne einen (ursprünglichen) Plan gehabt zu haben ist "responding to Change" unmöglich, denn dieses bedeutet ja nichts anderes als den (mittlerweile als ineffizient erkannten) Ursprungsplan so an die mittlerweile gewonnenen Ergebnisse anzupassen, dass er erneut die beste erkennbare Lösung darstellt - so lange bis weitere Erkenntnisse weitere Anpassungen und Optimierungen ermöglichen.


Agile Prozesse haben damit nicht nur einen Plan als Eingangs- und Ausgangswert - im Grunde ist der gesamte agile Prozess nichts weiter als ein einziger fortlaufender Planungsvorgang. Hier liegt auch der zentrale Unterschied zum klassischen Projektmanagement (PMP, Prince2 und Ähnliche) in dem zu Beginn ein Plan festgelegt wird, an den sich dann theoretisch alle zu halten haben.1

Das üblicherweise an dieser Stelle auftretende Gegenargument ist, dass ein solcher Plan (sowohl im ursprünglichen als auch im fortgeschrittenen Status) völlig mangelhaft sein muss, sonst müsste er schließlich nicht permanent geändert werden. Ein scheinbar schlagender Punkt, allerdings wirklich nur scheinbar. Denn: Zum Zeitpunkt jeder Anpassung ist das Ergebnis lediglich der in diesem Moment und auf Basis der in diesem Moment verfügbaren Informationen beste Plan. Sobald sich diese Informationen ändern ist er es nicht mehr und muss erneut angepasst werden. Erneut ein übliches Gegenargument: Wenn man denn am Anfang länger/besser geplant hätte, dann wäre auch der Plan besser, man müsste ihn nicht so oft anpassen und man wäre schneller fertig. Tatsächlich ist das sogar eine relativ häufige (und relativ verheerende) Manager-Ansicht. Im besten Fall führt sie zum unsanften Erwachen durch Konfrontation mit der bösen Realität, die sich einfach nicht an den schönen Plan halten will, im schlimmsten Fall wird die offensichtliche Unbrauchbarkeit des Plans geleugnet und das Team gezwungen eine vergleichsweise schlechte Lösung umzusetzen.

Der Normalfall liegt irgendwo dazwischen. Am Anfang steht ein angeblich präziser, in Wirklichkeit aber "hinreichend unscharf" formulierter Plan. Sobald der sich als unrealistisch herausstellt werden mit vollen Händen geplante Features über Bord geworfen, wobei bevorzugt die genommen werden "die man nicht sieht" (Qualitätssicherung, Dokumentation, Unit-Tests, einheitliche Architektur, etc.). Das Ergebnis ist ein Produkt das von Außen halbwegs ansehnlich aussieht, bei dem unter der Haube Kraut und Rüben durcheinanderliegen und über das man dem Kunden gegenüber behauptet, genau so wäre es von Anfang an geplant gewesen. Ein paar Releases bekommt man auf diese Weise sogar hin, bis das vermurkste Produkt unter der Last seiner technischen Schulden kollabiert und weggeworfen werden muss (habe ich so schon erlebt).

Der scrum-/agile Idealfall (gibt es da einen Normalfall?) ist anders. Zu Beginn lassen sich auch hier Rahmenbedingungen setzen, sei es finanzieller oder zeitlicher Art, danach geht die Entwicklung los, die immer das kleinstmögliche funktionierende Ergebnis (minimum viable product) zum Ziel hat. Sobald das erreicht ist kann auf Basis der verbleibenden Zeit und Ressourcen neu geplant werden, und zwar je nach Kundenwunsch durch Zusatzfeatures zum bisherigen Funktionsumfang oder komplett neue Funktionen. Und da in jedem Sprint durch die Definition of Done auch (Unit)Tests und (Code)Dokumentation erstellt werden müssen kommt es auch nicht zum Auftürmen technischer Schulden.2 Es gibt zwar angeblich agile Projekte in denen das nicht so läuft, aber die meisten davon sind, wie ein Bekannter letzte Woche meinte, "not even Cargo Cult".

1Die üblicherweise im Projektverlauf auftretende Häufung von Change Requests, Fast Tracking und ähnlichen Unsitten ist im Regelfall eher chaotisch als agil.
2Ja, man kann das auch weglassen. Dann ist es aber nicht Scrum oder Agile sondern Murks.