Jetzt bin ich also auch ScrumMaster. Habe zumindest die passende Schulung hinter mir. Bei Boris Gloger, nach eigener Aussage einer der ersten seiner Art. Was hats mir gebracht? Was ändert sich?
Scrum ist ja heute Commodity, state of the art, fast schon langweilig, auf jeden Fall muss man aber danach arbeiten. Jedenfalls in der agilen Web-Szene. Erklären braucht man wohl nicht mehr. Alle kennen die Stichwörter von Estimation bis Retrospective Meeting, von Product Owner bis Team Member und von Task Board bis Burndown Chart. Dennoch: Jenseits dieser formalisierten Prozessbestandteile: Was ist der Kern? Was muss man verinnerlichen? Was ist wirklich das Mindset?
Natürlich: Eine Schulung macht noch keinen Master. Da werde ich wohl das eine oder andere Projekt... stop, schon der erste Fehler. Also das ein oder andere Produkt betreuen und ein paar Sprints mitmachen müssen.
Aber die Grundidee, die ist nicht so neu: Softwaresysteme werden sehr schnell sehr kompliziert. Oft viel zu kompliziert für die Benutzer, die manchmal mit sehr viel weniger Funktionen auskommen würden. Die richtigen Features erkennt man aber viel leichter, wenn man schon mit dem System arbeiten kann. Sie abstrakt anhand einer Anforderungsbeschreibung herauszulesen, ist anspruchsvoll.
Also: Gar nicht das komplette System erstellen, sondern den kleinsten nutzbaren Teil davon. Dann die kleinste mögliche Erweiterung. Und so weiter. Und darauf spekulieren, dass irgendwann der Funktionsumfang schon als ausreichend beurteilt wird, obwohl im Fachkonzept vielleicht noch ein paar hundert Anforderungen stehen.
Ausserdem ist dann schon sehr früh klar, wie gut Schätzung und Realität übereinstimmen. Dann kann man rasch gegensteuern (das muss dann aber auch passieren!). Ach ja, die Schätzung - da gibts eben die beiden Tricks: Nicht schätzen, wie lange etwas braucht, sondern was man in einer gegebenen Zeit schafft. Und schätzen durch Vergleich zweier Aufgaben.
Und der Rest? - Entwickler direkt mit den Benutzern (oder Product Ownern) reden lassen, keine Stille Post. Ein Team durch Commitment bei der Ehre packen. Den Product Owner die Probleme der Entwickler spüren lassen. Viele gut durchdachte Tips für den alltäglichen Arbeitstalltagswahnsinn.
Das ist für mich Scrum. Doch, schon - ich freue mich auf das nächste Projekt - äh, Produkt.
