Agile Entwicklung und Scrum in tschechischen Unternehmen

Die Wasserfallmethode in der Softwareentwicklung stirbt in Tschechien langsam aus. In den letzten zwei Jahren haben wir einen massiven Umstieg auf agile Methoden beobachtet — und Scrum ist mit Abstand die beliebteste Wahl. Doch der Wechsel von Wasserfall zu Scrum bedeutet nicht einfach nur, Meetings umzubenennen. Es ist ein kultureller Wandel, der schmerzt.

Warum tschechische Unternehmen den Kurs ändern¶

Klassisches Wasserfall — Analyse, Entwurf, Implementierung, Test, Deployment — hat in der Theorie eine logische Struktur. In der Praxis führt es jedoch dazu, dass der Kunde monatelang keine Ergebnisse sieht. Und wenn er sie sieht, stellt er fest, dass es nicht das ist, was er wollte. Was folgt, ist ein Karussell aus Change Requests, Scope-Streitigkeiten und frustrierten Teams auf beiden Seiten.

Große tschechische IT-Unternehmen wie Profinit, Unicorn und Asseco erkannten dies um 2010. Heute ist Scrum der De-facto-Standard für neue Projekte. Aber kleinere Unternehmen und interne IT-Abteilungen von Banken und Versicherungen fangen gerade erst an — und genau dort sehen wir die meisten Fehler.

Der häufigste Fehler: Scrum ohne Product Owner¶

In einem Unternehmensumfeld passiert typischerweise Folgendes: Das Management entscheidet, „wir arbeiten jetzt agil.” Das Entwicklungsteam beginnt mit Sprints. Aber niemand bestimmt einen Product Owner — eine Person mit dem Mandat, das Backlog zu priorisieren. Stattdessen werden Prioritäten von einem Steering Committee festgelegt, das sich einmal im Monat trifft.

Das Ergebnis? Das Team hat zweiwöchige Sprints, aber das Backlog ändert sich nur alle vier Wochen. Die Hälfte der Sprint-Planung ist verschwendete Zeit, weil niemand weiß, was wirklich wichtig ist. Das Team gibt auf und kehrt zum Pseudo-Wasserfall zurück, nur mit kürzeren Iterationen.

Lösung: Der Product Owner muss eine einzelne Person mit echter Entscheidungsbefugnis sein. Kein Komitee, kein Koordinator. Jemand, der sagt „das machen wir im nächsten Sprint” und den niemand überstimmt.

Scrum Master ist kein Projektmanager¶

Der zweite typische Fehler: Unternehmen benennen ihren bestehenden Projektmanager zum Scrum Master um. Doch diese Rollen sind grundlegend verschieden. Ein Projektmanager leitet, verteilt Aufgaben und kontrolliert. Ein Scrum Master moderiert, beseitigt Hindernisse und schützt das Team.

In einem Projekt für eine große Bank sind wir auf einen „Scrum Master” gestoßen, der im Daily Standup Aufgaben an einzelne Entwickler verteilte. Das ist das genaue Gegenteil davon, wie Scrum funktioniert. Das Team teilt die Arbeit selbst auf. Der Scrum Master fragt „was hindert euch an der Arbeit?” und beseitigt dann diese Hindernisse.

Schätzung: Story Points vs. Personentage¶

Tschechische Konzerne lieben Personentage. Reports, Timesheets, Auslastungszahlen. Scrum führt Story Points ein — eine relative Einheit der Komplexität. Und das Management hasst es, weil sich ein Story Point nicht direkt in Geld umrechnen lässt.

Dennoch funktionieren Story Points besser. Wenn ein Team eine Aufgabe auf 5 Story Points schätzt, sagt es nicht „das dauert 5 Tage.” Es sagt „das ist ungefähr so komplex wie die Sache, die wir beim letzten Mal auf 5 geschätzt haben.” Nach drei Sprints weiß man, dass das Team durchschnittlich 40 Story Points pro Sprint schafft (Velocity). Und das ist eine wesentlich zuverlässigere Prognose als jedes Gantt-Diagramm.

Ein Kompromiss, der funktioniert: Das Team schätzt in Story Points, aber für das Management wird die Velocity in ein voraussichtliches Fertigstellungsdatum umgerechnet. Ein Burndown-Chart verkauft Scrum besser als jede Präsentation.

Retrospektive ist die wichtigste Zeremonie¶

Sprint Planning, Daily Standup, Review — all das ist wichtig. Aber die Retrospektive ist es, die Scrum wirklich agil macht. Nach jedem Sprint hält das Team inne und sagt: was hat funktioniert, was nicht, und was werden wir ändern.

In tschechischen Unternehmen wird die Retrospektive häufig übersprungen. „Wir haben keine Zeit — wir müssen liefern.” Das ist wie zu sagen „wir haben keine Zeit für Autowartung, wir müssen fahren.” Es funktioniert — bis der Motor kaputtgeht.

Die besten Retrospektiven, die wir gesehen haben, nutzen das Start–Stop–Continue-Format: Was werden wir anfangen zu tun, was werden wir aufhören zu tun, und was werden wir weiterhin tun. Konkrete Maßnahmen, ein konkreter Verantwortlicher, Überprüfung in der nächsten Retro. Ohne das ist eine Retrospektive nur Beschwerden beim Kaffee.

Werkzeuge: JIRA gewinnt¶

Was die Werkzeuge betrifft, dominiert Atlassian JIRA mit dem GreenHopper-Plugin (heute JIRA Agile) in Tschechien im Jahr 2012. Karten an der Wand sind toll für kleine Teams, aber für verteilte oder größere Teams braucht man ein digitales Board.

Alternativen gibt es — Rally, VersionOne, Target Process — aber JIRA hat in Tschechien die stärkste Community und integriert sich mit Confluence, Bamboo und anderen Atlassian-Produkten. Für 10 Dollar für 10 Benutzer ist es außerdem unglaublich günstig.

Scrum in regulierten Branchen¶

Banken und Versicherungen haben ein spezielles Problem: Regulierung. Die Tschechische Nationalbank verlangt Dokumentation, einen Audit-Trail und formale Genehmigungsprozesse. Wie bringt man das mit Scrum in Einklang?

In der Praxis lösen wir dies, indem wir regulatorische Anforderungen in die Definition of Done aufnehmen. Eine User Story ist nicht fertig, bis sie gemäß internen Standards dokumentiert ist. Automatisierte Tests dienen als Nachweis für Audits. Und zu Sprint Reviews wird das Compliance-Team eingeladen, das alle zwei Wochen funktionierende Software sieht statt einmal alle sechs Monate.

Zusammenfassung¶

Scrum funktioniert in tschechischen Unternehmen — aber nur, wenn man es richtig macht. Investieren Sie in Schulungen, geben Sie dem Product Owner echte Entscheidungsbefugnis, überspringen Sie keine Retrospektiven und versuchen Sie nicht, Scrum in die Form eines Wasserfalls zu biegen. Kultureller Wandel ist schwieriger als technischer Wandel, aber die Ergebnisse sind es wert: schnellere Lieferung, zufriedenere Kunden und motivierte Teams.