Was Prozesse tatsächlich bringen

Der meiste Widerstand gegen Prozesse kommt von Erfahrungen mit schlechten Prozessen. Entwickler, die zweistündige Statusmeetings durchgesessen, Änderungsantragsformulare für eine einzeilige Korrektur ausgefüllt oder zugesehen haben, wie ein „Transformations"-Berater das Organigramm umstellt, haben allen Grund zusammenzuzucken, wenn jemand sagt „wir brauchen mehr Prozesse."

Dieses Zusammenzucken ist rational. Schlechte Prozesse sind real, sie sind verbreitet und verschwenden enorme Mengen an Zeit. Aber die Schlussfolgerung, die die meisten Teams ziehen – „Prozesse selbst sind das Problem" – folgt daraus nicht. Ein Team, das eine schlechte Mahlzeit hatte, schwört nicht dem Essen ab. Es findet ein besseres Restaurant.

Die Neuausrichtung ist einfach: Prozesse sind nicht die Regeln, die jemand anderes deiner Arbeit auferlegt. Ein Prozess ist jedes wiederholbare Muster, das das nächste Mal einfacher macht als das letzte Mal. Eine Namenskonvention für Branches ist ein Prozess. Eine gemeinsame Checkliste vor dem Mergen eines PR ist ein Prozess. Ein fünfminütiges Standup, bei dem drei Leute sich über Blockierungen abstimmen, ist ein Prozess. Keines davon erfordert eine Zertifizierung oder einen Berater. Alle davon wirken kumulativ.

Teams, die sagen „wir brauchen keine Prozesse", haben fast immer Prozesse – sie sind nur implizit, undokumentiert und leben im Kopf einer Person. Das funktioniert, bis diese Person im Urlaub ist, das Unternehmen verlässt oder einem zweiten Projekt beitritt. Dann entdeckt das Team, dass es einen Single Point of Failure hatte, keine prozessfreie Kultur.

Jeder Prozess erzeugt entweder Hebel oder Overhead. Der Test ist einfach: Macht diese Praxis die nächste Arbeitseinheit günstiger, schneller oder sicherer als die letzte?

Eine Code-Review-Checkliste ist ein Hebel – sie fängt dieselbe Fehlerklasse jeden Sprint ab, ohne dass der Reviewer sich alles von Grund auf merken muss. Ein verpflichtendes Architecture-Review-Board, das zweiwöchentlich tagt und Änderungen 10 Tage lang in die Warteschlange stellt, ist Overhead – es verlangsamt die Lieferung ohne proportionale Risikoreduktion.

Die Unterscheidung liegt nicht in der Formalität. Formale Prozesse können hohe Hebelwirkung haben (Branch-Protection-Regeln, die Force-Pushes auf main verhindern, kosten nach der Konfiguration nichts und verhindern katastrophale Fehler auf unbestimmte Zeit). Informelle Prozesse können reiner Overhead sein (die ungeschriebene Regel, dass „man es mit Dave absprechen sollte, bevor man merged", weil Dave einmal von einem schlechten Deployment gebrannt wurde und jetzt niemand weiß, ob Daves Zustimmung erforderlich oder kulturell ist).

Drei Signale, dass ein Prozess von Hebel zu Overhead gewechselt hat:

• Leute umgehen ihn. Wenn Entwickler regelmäßig einen Schritt überspringen, weil es einfacher ist, um Vergebung zu bitten, liefert der Schritt nicht genug Wert, um seine Reibung zu rechtfertigen.
• Niemand kann erklären, warum er existiert. Wenn die Antwort auf „warum machen wir das?" lautet „das haben wir schon immer so gemacht", hat der Prozess seine Begründung überlebt.
• Er skaliert mit der Mitarbeiterzahl, nicht mit dem Risiko. Gute Prozesse skalieren sublinear – eine CI-Pipeline bedient 50 Entwickler. Schlechte Prozesse skalieren linear – jede neue Einstellung fügt eine weitere Zeile zur Genehmigungsmatrix hinzu.

Wenn du Overhead findest, entferne ihn. Wenn du Hebel findest, dokumentiere ihn, damit er Personalwechsel überlebt.

Unabhängig von Teamgröße, Domäne oder Methodikpräferenz sind drei Fähigkeiten nicht verhandelbar:

• Versionskontrolle. Jede Codezeile ist versioniert, zugeordnet und wiederherstellbar. Das ist 2026 nicht kontrovers – aber „wir nutzen Git" und „wir nutzen Git gut" sind unterschiedliche Aussagen. Modul 2 behandelt den Unterschied.
• Work-Tracking. Jede laufende Arbeit ist für das gesamte Team in einem gemeinsamen System sichtbar – nicht in einer Tabelle, nicht im Kopf von jemandem, nicht in einem Slack-Thread, der bis Dienstag vom Bildschirm scrollt. Tickets sind die Einheit des Work-Trackings, und Modul 3 behandelt, was ein gutes ausmacht.
• Absichtskommunikation. Das Team hat einen regelmäßigen, leichtgewichtigen Mechanismus, um zu teilen, woran sie arbeiten, was sie blockiert und was sie voneinander brauchen. Das kann ein fünfminütiges Daily Standup sein, ein asynchroner Post in einem Channel oder ein gemeinsames Board – das Format ist weniger wichtig als die Konsistenz.

Alles andere – Sprints, Story Points, Retrospektiven, WIP-Limits, Velocity-Charts – ist Methodik. Methodik ist wertvoll, aber sie ist die Schicht über diesen Grundlagen. Man kann Scrum ohne Kanban-Boards betreiben. Man kann Kanban ohne Story Points betreiben. Man kann keines von beiden ohne Versionskontrolle, Work-Tracking und Absichtskommunikation betreiben.

Der Rest dieses Kurses konzentriert sich auf diese drei Grundlagen. Modul 5 wird dir helfen zu entscheiden, ob du eine Methodik darüber legen solltest – und wenn ja, welche.