Alle Artikel mit dem Schlagwort: scrum

Die Dreifaltigkeit agiler Führung

Veröffentlicht von Marcus Raitner

Man kann von Scrum halten was man will, aber der Scrum Guide beschreibt sehr schön drei Aspekte von Führung im Kontext agiler Produktentwicklung. Da gibt es im Zentrum der Wertschöpfung das Development Team, das möglichst autonom und selbstorganisiert arbeitet. Der Product Owner sorgt als „CEO“ des Produkts für die inhaltliche Führung und gibt dadurch der Autonomie eine gemeinsame Vision und Richtung. Und schließlich gibt es den Scrum Master, der sich dienend um die Menschen kümmert und dem Product Owner, dem Development Team und dem Rest der Organisation hilft effektiv zusammenzuarbeiten. Ein klassischer Manager ist dort nicht beschrieben, denn seine verschiedenen Aufgaben sind auf diese Rollen verteilt.

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.