38
die positive Energie für das Vorhaben. Es lohnt,
auf die Product Vision hinzuarbeiten, weil da-
von das Unternehmen, meine Organisations-
einheit und/oder jeder für sich einen Vorteil
hat. Sie so
(„veränderungsfreundlich“) zu
formulieren
und mit den Stakeholdern abzu-
stimmen, dass diese Effekte entstehen kön-
nen,
ist Aufgabe des sogenannten
„Product
Owner“
. Eine Product Vision ist also in der
Regel nicht messbar, oft nicht quantifiziert in
ihrem Effekt und überhaupt recht unpräzise.
Bereits hier beginnt das Leiden vieler Control-
ler, ist es doch beinahe das Gegenteil von dem,
was im „klassischen Projekt-Management“
gefordert wird, nämlich die Projekt-Ziele vor
dem Start des Projektes so genau wie nur
irgend machbar zu dokumentieren.
Agiles Management-Prinzip: unscharfe
Vision statt genauere Ziele
Auf Basis der Product Vision werden nun in
SCRUM die Bestandteile des Produktes identi-
fiziert, die im Rahmen des Projektes entstehen
sollen. Diese Produkt-Teile sammelt der Pro-
duct Owner im
„Product Backlog“
.
Lassen Sie mich das anhand einer Metapher
veranschaulichen:
·
·
Product Vision: „Eine schicke, warme und
flexibel einsetzbare Jacke, die ich in mehre-
ren Jahreszeiten anziehen kann.“
·
·
Product Backlog: Wärmende Weste | Wär-
mende Ärmel | abnehmbare Kapuze | 2 regen
dichte Innentaschen | Wasser- und wind-
dichte Außenschicht | kuschliges und wasch-
bares Innenfutter | 3 abnehmbare Außen
taschen | usw.
Diese
„Product Backlog Items“
werden nun
in eine eindeutige Reihenfolge gebracht
,
beginnend mit dem wichtigsten Teil, sinnvol-
lerweise aber unter Berücksichtigung etwaiger
technischer Abhängigkeiten (in unserer Meta-
pher wäre es vermutlich ungünstig, die Außen-
taschen vor der Außenschicht zu realisieren).
Es entsteht somit ein priorisiertes Product
Backlog.
Spätestens jetzt kommt das
„Development
Team“
(DevTeam) ins Spiel. Im Development-
Team sind etwa
5 – 9 Personen
vertreten, die
über
die wesentlichen Kompetenzen verfü-
gen
, um die Product Backlog Items zu realisie-
ren. In IT-Projekten wären somit auch Fachbe-
reichs-Mitarbeiter im DevTeam zu finden. In un-
serem Beispiel bräuchten wir vermutlich Desig-
ner, Schneider und Einkäufer. Diese schätzen
nun initial das Product Backlog. Üblicherweise
erfolgt diese Schätzung in SCRUM in der unde-
finierten Einheit
„Storypoints“
. Auch das wird
von vielen klassischen Controllern mit Stirnrun-
zeln kommentiert, weil Storypoints in keine
gängige monetäre Kennzahl einbezogen wer-
den können.
Storypoints sind weder Auf-
wands-Einheit noch Geld-Menge.
Sie sagen
nur etwas darüber aus, wie komplex dieses
spezielle DevTeam die Product Backlog Items
einschätzt. Storypoints sind somit auch nicht
projekt- oder teamübergreifend vergleichbar.
Trotzdem sind sie sehr
hilfreich bei der Ter-
min-, Aufwands- oder Kostenschätzung
für
das Projekt sowie die wesentliche Basis für
das, was man klassisch „Projektsteuerung“
nennen würde.
Agiles Management-Prinzip: Selbstorgani-
sation vor Management-Entscheidungen
Nun entscheidet das DevTeam, wie viele
Back-
log Items
es sich
für eine erste Zeitperiode
zutraut fertigzustellen. Diese
Zeitperiode
ist
normalerweise zwischen einer und vier Wochen
kurz und wird
„Sprint“
genannt. Durch die
Priorisierung der Backlog Items befasst sich
das DevTeam zunächst mit den allerwichtigs-
ten Produkt-Teilen. In unserer Metapher könnte
das z. B. die Außenschicht sein. Nun diskutie-
ren DevTeam und Product Owner ausführlicher,
wie diese Außenschicht genau aussehen und
beschaffen sein sollte. Anschließend plant das
DevTeam, welche
Tasks
nun nötig sind, um die
für den ersten Sprint versprochenen Product
Backlog Items liefern zu können. Tasks sind
Tä-
tigkeiten
, die von einem DevTeam-Mitglied
in-
nerhalb eines Tages durchgeführt
werden
können. Dieser
Prozess des
„Sprint Plan-
ning“
wird vom sogenannten
„Scrum Mas-
ter“ moderiert
. In unserer Metapher könnten
also z. B. der Entwurf eines Schnittmusters für
die Ärmel ebenso wie das Herausfinden von
Lieferanten für den Stoff oder auch eine Be-
standsaufnahme im eigenen Stofflager bis hin
zum eigentlichen Zusammennähen der Teile
sinnvolle Tasks sein.
Agiles Management-Prinzip: Priorisierung =
Fokussierung = Speed + Lernen = Effizienz
Da hierbei nur der nächste Sprint, also ein
überschaubarer Zeitraum betrachtet wird, ist es
leistbar, so fein zu planen, ohne den Überblick
zu verlieren. Spätestens am Ende eines Sprints
werden die bis dahin fertigen Product Backlog
Items an den Product Owner übergeben. Ziel ist
es, in jedem Sprint mehrere Product Backlog
Items fertigzustellen.
Wenn alles perfekt läuft, liefert das DevTeam
genau die Backlog Items, die es vorher verspro-
chen hat. Erfahrungsgemäß wird das in den
ersten drei bis fünf Sprints aber eher nicht der
Fall sein. Das DevTeam wird sich zu viel (oder
vielleicht auch zu wenig) zutrauen. Es wird
Missverständnisse zwischen DevTeam und Pro-
duct Owner, technische Probleme oder unvor-
hergesehene Schwierigkeiten innerhalb des
DevTeams geben.
In SCRUM wird mit Unvorhersehbarem ge-
rechnet. Aber ebenso damit,
dass ein Team
sich schnell selbst verbessern wird, wenn
Räume für Feedback und Lernen vorgese-
hen werden.
Konkret bedeutet das in SCRUM,
dass am Ende jedes Sprints bewusst danach
Autor
Dipl.-Wirtschaftsing. (FH) Dieter Eschlbeck
ist Inhaber der Firma MoveYourProjekt, München. Er berät,
trainiert und coacht, um Projekte und Projekt-Management in
Unternehmen zu optimieren. Er hat branchenübergreifend Er-
fahrung sowohl in klassisch als auch agil aufgesetzten Projek-
ten und leitet seit mehr als zwanzig Jahren die Fachseminare
für Projekt-Management der CA Akademie.
E-Mail:
Agiles Management: Chance oder Bedrohung für Controller?
