Redesigned Agile in großen Unternehmen - Korn AG

Hans-Peter Korn Manuskript eines Buchbeitrags für:
Agiles IT-Management in großen Unternehmen - Hrsg.: Hans-Peter Korn, Jean Pierre Berchez
ISBN 978-3-86329-442-7 Symposion Publishing, Düsseldorf 2013
Die „Stories“ und „Features“ erscheinen im Team Backlog und im Program Backlog als
einzelne Elemente einer nach der Abarbeitungsreihenfolge geordneten Liste. Sie sind jedoch
nicht isoliert, sondern eng miteinander verbunden – beginnend bei den „Investment
Themes“ auf Portfolioebene bis zu den „Epics“ auf Programmebene.
Abbildung 5 zeigt diese Zusammenhänge. Ein derartiges Metamodell dient auch als
Grundlage für die Methoden und Werkzeuge des agilen Requirement-Engineerings.
Abb. 5: Agile Requirements Enterprise Backlog Meta-Model (Leffingwell) [12]
Es würde den Rahmen dieses Beitrags sprengen, im Detail auf die Erarbeitung des Team
Backlogs, des Program Backlogs und der Nonfunctional Requirements einzugehen. Ich
verweise auf die entsprechenden Beschreibungen im „Scaled Agile Framework“ [11] von
Dean Leffingwell.
Teamleiter/ScrumMaster (Agile Master) verantwortlich für das Wie
Wenn es beim Redesign des bereits eingeführten agilen Vorgehens oder bei seiner
Neueinführung Teamleiter gibt, dann werden sie jetzt „Wie-Verantwortliche“ im Sinne eines
„ScrumMasters“ als „Servant Leader“ gemäß Scrum Guide 2011 [3]. Ihre bisherige
Verantwortung für das „Was“ übernehmen jetzt neu die PO/SO. Diese Teamleiter bleiben die
Vorgesetzten der Entwickler, sind jedoch nicht die Vorgesetzten der POs/SOs. Bei Teams
ohne Teamleiter, jedoch mit einem „ScrumMaster“, übernimmt dieser als „Servant
Leader“ auch die Rolle des Teamleiters.
Da die agilen Teams – wie im Abschnitt „Hinweise zum Strukturieren der Teams“ erwähnt –
keine temporären Projektteams, sondern längerfristig stabile Feature- oder Component-Teams
sind, werden sie als Organisationseinheiten der Primärorganisation mit jeweils einem
Teamleiter als disziplinarischer Führungskraft gebildet. Nur so ist gewährleistet, dass die
individuelle Förderung der Teammitglieder auf Basis der Tag für Tag beobachteten Arbeit
erfolgt und nicht „aus der Entfernung via Informationen aus dritter Hand“, wie es bei
Matrixorganisationen oft der Fall ist. Wenn die disziplinarische Führungskraft weit weg „vom
Schuss“ ist, beobachte ich häufig, dass der ScrumMaster und der Product Owner dieser
Führungskraft anlässlich der Zielerreichungsgespräche Inputs zu einzelnen Teammitgliedern
liefern müssen – und sie damit zu nicht deklarierten, indirekten Führungskräften werden.
13