Scrum ist Agile Leadership - Teil 2

Wie führt der ScrumMaster?

Geschrieben von Peter Beck am 18.03.2019

Im ersten Teil wurde an zwei Beispiel-Unternehmen gezeigt, wie Product Owner führen. Der Product Owner ist Teil eines agilen Führungs- bzw. Managementsystems, das für jede Organisation entwickelt werden muss. Scrum liefert einen Rahmen für dieses Führungssystem.

Dieser Teil führt die Geschichten der beiden Unternehmen fort, und zeigt auf wie der ScrumMaster führt.

Scrum ist Agile Leadership - Teil 1

Wie führt der Product Owner?

Geschrieben von Peter Beck am 23.01.2019

Die Scrum-Rollen sind die Prototypen für agile Führung und agiles Management. Das Agile Manifest wurde 2001 von den beiden Autoren der ersten Scrum-Publikation mitformuliert. Scrum ist ein Rahmenwerk, um eine Organisation auf Agilität zu optimieren. Es bringt neben dem Grundverständnis, welche Artefakte und Abläufe nötig sind, auch eine Aufteilung der Führungsaufgaben in 3 Rollen mit. Scrum verfolgt auch bei den Rollen einen Lean-Ansatz: Weniger ist mehr. Nur die absolut notwendigen Regeln wurden in das Rahmenwerk aufgenommen.

Das hat den Vorteil, dass jede Organisation das für sie passende Führungssystem innerhalb der Kräftedreieckes der Scrum-Rollen entwickeln kann. Es hat aber auch zum Nachteil, dass das Verständnis um Agile Führung nicht so leicht zugänglich ist und oft auch sehr unterschiedlich interpretiert wird.

Um mehr Klarheit zu schaffen, werde ich in diesem ersten von vier Artikeln die Frage Wie führt der Product Owner? anhand von zwei Beispiel-Unternehmen beantworten.

  • Ein junges, stark wachsendes Unternehmen mit anfangs 20 Mitarbeitern.
  • Ein über zwei Jahrzehnte gewachsenes, mittelständiges Unternehmen mit 450 Mitarbeitern.

Wie ein Ingenieur bei BMW eine Large Scale Scrum Adoption ins Rollen brachte

Geschrieben von Kai Simons am 23.10.2018

Konstantin Ribel war leicht geschockt, als er in einem Large Scale Scrum - Training bei Craig Larman am zweiten Seminartag feststellen musste, dass sein bisheriger Job in der Lean-Philosophie als "Waste" bezeichnet wird - überflüssige, nicht wertschöpfende Arbeit. 

Als Ingenieur auf unterster Hierarchie-Ebene machte er sich sorgen über die Komplexität einer autonomen Fahrzeugentwicklung.

Hilfe, mein Unternehmen macht SAFe

Survival Guide für Agile Coaches

Geschrieben von Andreas Schliep am 20.11.2016

Du hast alles gegeben. In unzähligen Sitzungen, Gesprächen, Präsentationen und Intranet-Artikeln hast du von A bis Z dargelegt, warum es Sinn macht, als Unternehmen agil zu werden, was Agilität bedeutet, warum im komplexen Kontext definierte Prozessvorschriften nicht funktionieren können. Du hast agilen Teams geholfen, eine herausfordernde Definition of Done zu formulieren und vermeintlichen Product Ownern geholfen, ihren Beitrag als Anforderungsspezialist im Team zu leisten. Dem Management hast du die Lean-Gedanken ans Herz gelegt - und im Change-, Transition- oder Transformation Team alles gegeben. Schliesslich haben alle eingesehen, dass ein Unternehmen zu dieser Zeit agil werden muss. Es gab sogar einen grossen Vortrag des Managements mit Bildern von Tankern und Schnellbooten.

Und jetzt das: Das Management hat sich von externen Beratern davon überzeugen lassen, dass SAFe - Scaled Agile Framework - für euch genau die richtige Lösung sei.

Scrum Guide und Skalierung: Teil 4 - Scrum Artefakte

Geschrieben von Peter Beck am 24.03.2015

Scrum Artefakte oder Prozessdokumente dienen als Orientierung oder Bindeglieder im Prozessrahmen.

4.1 Product Backlog

Das Product Backlog ist das Kernartefakt von Scrum. Bei größeren Produktorganisationen wird das Management desselben unnötig verkompliziert. Was sind Kernaussagen, was sind die Spielregeln für ein Product Backlog, die auch für skalierte Umfelder gelten?

Zunächst einmal: es gibt nur ein Product Backlog. Dazu gibt es im Scrum Guide eine ganz klare Aussage:

Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. […,] Häufig arbeiten mehrere Scrum Teams gemeinsam an einem Produkt. Dann wird ein einziges Product Backlog benutzt, um die anstehende Arbeit am Produkt zu beschreiben. In diesem Fall kann ein Gruppierungsattribut für die Product Backlog-Einträge verwendet werden.