Dark Agile Manifesto

Wir formulieren kein Manifest, um besser zu werden. Sondern um zu rechtfertigen, warum wir bleiben wie wir sind – nur mit bunten Boards und neuen Jobtiteln. Alles ist agil. Außer das Denken.

7. Retrospektive – Gruppentherapie ohne Nebenwirkungen In der Retro werden die schlimmsten Unzulänglichkeiten des vergurkten Prozesses (zu Deutsch: MURCS) so lange weichgespült, bis alle das Gefühl haben, etwas beigetragen zu haben. Am Ende steht ein Action Item: „Wir achten mehr auf Kommunikation.“ Niemand weiß, was das heißt – aber das Board hat jetzt eine neue Spalte.

6. Innovation nur, wenn sie niemanden stört Neue Ideen sind willkommen – solange sie den Sprint nicht gefährden, keine Bugs verursachen, das Budget nicht berühren und niemanden überfordern. Wer dennoch etwas ausprobiert, bekommt beim nächsten Planning eine Mahnung in Form eines Legacy-Tickets. Innovation gibt es nur auf Folien – nicht im Code.

5. Sprint-Ziel als Fragmenthaufen Wir definieren die wichtigsten verteilten Tasks – pardon, User Stories – als Sprint-Ziel. So ist garantiert, dass sich niemand damit identifiziert, weil jeder nur ein Stück davon sieht. Gemeinsame Verantwortung? Wird durch Zuteilung ersetzt. Und wenn’s nicht klappt, war das Ziel eben zu ambitioniert – nicht das System kaputt.

4. Schätzung nach Gefühl – am besten nach dem Gefühl des Chefs Storypoints sind ein demokratisches Instrument – außer, wenn der Scrum Master sie auf Basis der Deadline einfach vorgibt. Alternativ darf auch der Entwickler selbst schätzen. Aber wehe, er liegt später daneben – dann wird gefragt, warum du denn überhaupt so geschätzt hast. Und das nächste Mal wird die Zahl angepasst – an die Erwartung, nicht an den Aufwand.

3. Daily Standup – Rechtfertigungsritual unter Aufsicht Jeder darf drei Sätze sagen – aber bitte so, dass sie gut klingen. Inhaltlich egal, Hauptsache beschäftigt. Der Scrum Master notiert still, was in Wahrheit an den Linienvorgesetzten geht – mit dem er abends privat bei Slack kuschelt. Fragen stören nur. Blocker lösen sich magisch auf, sobald man sie nicht mehr erwähnt.

2. Früh planen, hart scheitern – und das am besten still Die Deadline ist festgelegt, bevor irgendjemand weiß, was überhaupt gebaut werden soll. Druck wird früh erzeugt, damit er lange wirken kann. Anpassungen am Ziel? Schwäche. Realistische Planung? Sabotage. Wer fragt, was sinnvoll wäre, gilt als unkooperativ – oder psychisch labil.

1. Vom Plan zur Story – ohne Sinn, aber mit DoD Ein fester Task aus dem bereits detailliert geplanten Projekt wird durch den technisch halbkundigen Product Owner in „User Stories“ zerlegt. Ob er versteht, wovon er redet, bleibt unklar. Der Nutzen („…so dass…“) fällt weg – dafür gibt’s eine minutiöse Definition of Done mit Checkboxen fürs Gewissen.