Alle Artikel mit dem Schlagwort: scrum

Das Team, das Produkt und der ganze Rest

Rund um Agilität gibt es ein grundlegendes Missverständnis. Dieses Missverständnis beginnt im Titel des Manifests für agile Softwareentwicklung. Unter Softwareentwicklung verstanden viele über zu lange Zeit das Übersetzen von Spezifikationen in Code durch austauschbare Programmierer, die dadurch (und oft verstärkt durch Vertragsverhältnisse) komplett den Kontakt zu ihren Kunden und ihrem Produkt verloren hatten. Und viele verstehen unter Softwareentwicklung genau das heute noch. Nur in kürzeren Zyklen. Agil eben. Den Autoren des Manifests, die allesamt leidenschaftliche Softwareentwickler waren, ging es aber um etwas anderes. Ihnen ging es darum, die Softwareentwicklung wieder als Zentrum der Wertschöpfung zu begreifen und die ganze in schwergewichtige Prozesse gegossene und in Organisationsstrukturen erstarrte Verschwendung um dieses Zentrum herum zu eliminieren. Es ging ihnen darum, als langlebiges Team in gemeinsamer Verantwortung erfolgreiche Produkte zu entwickeln. Und dazu darf es keine Mittelsmänner zwischen Team und Kunden mit entsprechenden Artefakten und Übergaben geben. Stattdessen müssen Fachexperten und Entwickler täglich zusammenarbeiten, um den Markt, das Produkt und den Lösungsraum gemeinsam zu erforschen.

Die Vorteile von Featureteams

Agile Methoden und insbesondere Scrum sehen bei einem kleinen Produkt mit einem einzigen Team ganz einfach aus. Sobald mehrere Teams an einem Produkt arbeiten, muss die Arbeit irgendwie aufgeteilt werden. Der naheliegende, weil bekannte, Ansatz ist es, das Produkt mehr oder weniger logisch und sinnvoll in Komponenten zu zerlegen und diese mit Komponententeams zu besetzen. Aus Sicht des Kunden sind diese Komponenten allerdings völlig irrelevant. Im besten Fall merkt er davon gar nichts. In den meisten Fällen allerdings schon, weil zwischen seinem Nutzen und den dafür notwendigen Funktionen des Produkts in der Regel mehrere Komponentengrenzen und damit Übergaben oder Abstimmungen zwischen Teams stehen, die den Fluss unterbrechen. Schöner wäre es aus Kundensicht, wenn die neue Funktion, das Feature, von einem einzigen sogenannten Feature-Team umgesetzt würde ganz egal welche Komponenten betroffen sind.

Planlos agil?

Planung ersetzt Zufall durch Irrtum. Albert Einstein wird dieses Bonmot zugeschrieben. Es ist nicht das erste Mal, dass ich es hier im Blog verwende. Schon der zweite Artikel trug 2010 genau diesen Titel. Das richtige Maß an Planung und der Sinn von Plänen beschäftigte mich seither immer wieder und beschäftigt mich im Zuge der Agilen Transformation immer mehr. Schließlich steht im agilen Manifests: „Responding to change over following a plan.“ Und nicht wenige schließen daraus, dass bei Scrum und Co. nicht mehr geplant werden muss und darf. Tatsächlich ist aber das Gegenteil der Fall, es wird sogar mehr und häufiger geplant mit unterschiedlichem Horizont. Aber eben nicht um des Plans willen, sondern für das gemeinsame Verständnis des Vorhabens.

Kontinuierliche Verbesserung

Projekte sind per Definition neuartige Vorhaben durchgeführt von Individuen in mehr oder weniger unbekanntem Umfeld. Daher sind Organisation und Abläufe im Projekt prinzipiell defizitär. Best-Practice können da nur ein Anhaltspunkt sein. Essentiell ist eine Kultur der kontinuierlichen Verbesserung der Zusammenarbeit im Projekt.

Werkzeug oder Waffe?

Jede Methode, jede Technik oder jedes Werkzeug ist nicht an sich gut oder schlecht, sondern wird es erst durch die Art und Weise des Gebrauchs. Ein Hammer kann hilfreiches Werkzeug sein genauso wie zerstörerische Waffe. Was in der physischen Welt aufgrund unserer Erfahrung sofort klar ist, gilt aber für weniger greifbare Werkzeuge ebenso: Auch ein scheinbar harmloses Burndown-Chart im Scrum birgt in den falschen Händen mit zweifelhaften Absichten viel Sprengkraft.