Alle Artikel mit dem Schlagwort: scrum

Die modernen Hofnarren

Veröffentlicht von Marcus Raitner

Ursprünglich waren Hofnarren keine Unterhalter oder Spaßmacher, sondern ernste Figuren. Sie hatten eine wichtige Aufgabe und und waren fester Bestandteil des Hofstaats. Durch ihre Narrheit waren sie allerdings von den gesellschaftlichen Normen entbunden und konnten so auf mehr oder weniger subtile und witzige Weise Missstände und (religiöse) Verfehlungen zur Sprache bringen und so die Mächtigen zum Nachdenken und Umdenken anregen. Durch diese „Narrenfreiheit“ waren sie „eine soziale Institution zulässiger Kritik.“ (Wikipedia) Die Gewaltenteilung in agilen Organisationen bedeutet in letzter Konsequenz auch eine Renaissance dieser ehrwürdigen sozialen Institution des Hofnarren in From der Rolle des Scrum Masters.

Agilität und Gewaltenteilung. Oder: Was macht eigentlich der Chef?

Veröffentlicht von Marcus Raitner

In den meisten hierarchischen Organisationen herrscht immer noch der Geist des Absolutismus. Alle Macht liegt beim Chef. Er oder sie verwaltet und steuert, erlässt Regeln, überwacht deren Einhaltung und sanktioniert Fehlverhalten. Auch heute gibt es noch genug kleine und große Sonnenkönige: L‘état c‘est moi! Weil die Menschen natürlich immer noch anfällig sind für übermäßige Machtfülle einerseits und andererseits weil die Aufklärung offenbar nur geringen Einfluss auf die Gestaltung moderner Organisationen hatte. Der Vormarsch der Wissensarbeit und das zunehmende Streben nach Agilität führt auch zu einer neuen Aufklärung mit einer ausgeprägteren Gewaltenteilung in den Organisationen.

Der Scrum Master: Drei Anti-Patterns

Veröffentlicht von Marcus Raitner

Scrum ist als Rahmenwerk für agile Produktentwicklung trügerisch einfach. Neben dem Entwicklungsteam gibt es nur die Rollen Product Owner und Scrum Master. Der Prozess ist schlank und kommt mit wenigen Artefakten und Events (wie die Meetings in Scrum heißen) aus. Diese Einfachheit führt in der Praxis zu allerlei Fake-Agile und Cargo-Kult – nettes, aber wirkungsloses Theater. Damit genau das nicht passiert, gibt es eigentlich den Scrum Master. Leider kommt es gerade bei dieser wichtigen Rolle zu vielen Fehlinterpretationen, wie die folgenden drei Anti-Patterns beispielhaft zeigen.

Das Team, das Produkt und der ganze Rest

Veröffentlicht von Marcus Raitner

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

Veröffentlicht von Marcus Raitner

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.