-
Psychologie:
Teams richtig motivierenKommunikationals Schlssel
Methodenwissen:
Projekte global steuernVerlsslich schtzen
Organisation:
Agiles OffshoringHybride Verfahren anwenden Komplexitt
reduzieren
Recht und Gesetz:
Festpreise im agilen Umfeld Wenns schiefgeht: Wer haftet?
Methoden verstndlich erklrt
Agil Softwareentwickeln
KOMPAKTIT-PROJEKTE
Scru
mric
htig
einf
hre
n
Ein Sonderheft des Magazins fr professionelle
Informationstechnik 4/2015
Fr Praktiker:
Von Erfahrungenprofitieren
-
iX Kompakt 2015 Agiles IT-Projektmanagement 3
EDITORIAL
Wie ein roter Faden zieht er sich durch das gesamte Heft,
dererste Leitsatz aus dem agilen Manifest:
Individuals and interactions over processes and tools.
Menschen und ihre Zusammenarbeit sind der Schlssel zumErfolg in
der Softwareentwicklung. Eine ernst zu nehmendeStudie von oose
Informatik untermauert diese Erkenntnis (sie-he Alle Links). Das
gewhlte Vorgehen ist danach zweitran-gig, auch wenn agil
durchgefhrte Projekte unbestritten einehhere Erfolgsquote aufweisen
als traditionelle. Das liegt nahe,es ist einfach sinnvoller,
Software in regelmigen Abstndenund in verdaulichen Hppchen
auszuliefern, als dem Kundenam Ende einen Riesenbatzen hinzuwerfen,
von dem er vorhernichts zu sehen bekam. In der Regel folgt ein bses
Erwachen.
Nur: Was genau bedeutet eigentlich agil? Auf den Hype vor ein
paar Jahren, der im Prinzip dafr warb, den gesunden
Men-schenverstand in die Softwareentwicklung einzufhren, folgtezwar
keine Ernchterung dafr sind die Vorteile zu offen-sichtlich , aber
eine realistische Einbettung der agilen Ideenin das tatschliche
Geschehen. Denn auch frher ging nicht alles schief, die zunehmende
Komplexitt der Anforderungendeckte jedoch die Schwchen
wasserfallmig organisiertenProjektmanagements auf.
Es mussten neue Verfahren her. Allerdings galt Scrum zunchstnur
als Technik fr berschaubare Projekte. Die Anpassung angroe und
internationale Vorhaben kam erst spter hinzu. Nunzeigte sich: Ganz
ohne Formalismen geht es nicht. Und somauerte man die schne neue
Welt wieder ein mit administrati-ven Vorgaben, festgelegten Rollen
und allerlei Spezialbefind-lichkeiten. Einer konservativen
Organisation lsst sich der pureStoff nicht schmerzlos
verabreichen.
Und so beklagte sich Dave Thomas, einer der Vter des imJahre
2001 proklamierten agilen Manifests, 2014 darber, dassdie
IT-Industrie aus reinem Profitinteresse die Seele aus denagilen
Ideen sauge (siehe Alle Links). Tatschlich hat sichdarum eine Armee
aus Beratern, Toolherstellern und Konfe-renzveranstaltern
aufgebaut, Agile ist zu einer Marketing-floskel verkommen.
Thomas mchte den Terminus daher in Rente schicken undhofft, dass
sich die Programmierer wieder auf das Wesentlichebesinnen. Seine
Worte: Lets abandon the word agile to thepeople who dont do things.
Instead, lets use a word that describes what we do. Lets develop
with agility.
Das klingt sympathisch, lsst aber eine wesentliche Sache au-er
Acht: Entwickler bewegen sich nicht im luftleeren Raum,sie
unterliegen dem Diktat des Wirtschaftslebens. Auftraggeberfreuen
sich ber verlssliche Abgabetermine, planbare Kosten,und dann sind
da noch Compliance-Vorgaben, Branchenstan-dards, Gesetze,
kulturelle Bremsen und anderes mehr, das dieidealtypische Welt
stark einschrnkt. Es ist gut, wenn Program-mierer autonom und
eigenverantwortlich entwickeln drfen,jedoch funktioniert das nur in
einem abgesteckten Rahmen.
Viele eher traditionell ausgerichtete Projekte bedienen
sichheute aus dem agilen Werkzeugkasten. Agil im ursprnglichenSinn
ist das nicht. Derzeit scheint das Vereinen solcher Techni-ken mit
klassischen Verfahren angesagt zu sein. Das belegenetliche Artikel
im vorliegenden Heft, die praxisgerechte Wegeaus dem Dilemma
zeigen. Agil zu arbeiten, heit in erster Linie, im Kopf frei zu
sein, die Zwnge klein zu halten undmiteinander zu reden.
JRGEN DIERCKS
Zurck zum Ursprung
Alle Links: www.ix.de/ix1516003 x
-
Agile Software -entwicklung kompaktZwar haben sich agile
Verfahren in der Softwareent-wicklung etabliert, aber die kommen
leider ebenfallsnicht ohne Tcken aus. Es gibt viele Stolperfallen,
und wer nur auf die Methoden schaut, hat gute Chancen, dabei auf
die Nase zu fallen. Einen berblick gibt es ab
Seite 8
Abseits des Hype Manche Anhnger des Agilen konzentrieren sich
zustark auf die Methoden. Um mit diesen Technikenerfolgreich zu
sein, braucht es jedoch mehr, vor allemeine realistische
Einschtzung der Lage.
Seiten 14, 18, 22 und 54
EinfhrungAgilittIn 28 Artikeln: So gelingen agile IT-Projekte
8
Projekte & QualittMethodenkritikAgiles Projektmanagement:
Eine Illusion? 14
FirmenkulturScrum nachhaltig im Unternehmen einfhren 18
PlanungsmethodenGenauere Schtzungen durch Komplexittsreduzierung
22
SoftwarequalittWerte schaffen mit sinnvollen Inkrementen 28
AnforderungsmanagementRequirements Engineering in der agilen
Entwicklung 32
QualittssicherungSoftware testen im agilen Entwicklungsprozess
36
OutsourcingAgile Techniken und Offshoring zusammenbringen 40
ErfahrungenVom agilen Projekt zum agilen Unternehmen 46
Kommunikation & Soft SkillsProjektfhrungWie man Projekte
gekonnt scheitern lsst 54
UmgangsformenSCARF: Die fnf Grundbedrfnisse des Menschen 58
PsychologieProjekte mit gewaltfreier Kommunikation verbessern
64
CoachingAgiler Coach: Change Agent mit vielfltigen Aufgaben
70
FhrungsstilDer agile Manager: Gewnschte Kultur vorleben 74
DidaktikVisual Facilitation: Workshops lebendiger gestalten
80
ArbeitsumfeldEine produktive Umgebung fr Teams schaffen 86
Methoden & ModelleGrundlagenHistorie der agilen Entwicklung
92
Feature Driven DevelopmentAgile und konventionelle Verfahren
zusammenfhren 96
4 iX Kompakt 2015 Agiles IT-Projektmanagement
INHALT | IX KOMPAKT IT-PROJEKTE
-
Den Kollegen verstehenTools und Techniken sind zwar wichtig,
ohne kreativeKpfe luft jedoch nichts. Wie man die anzapft unddas
Team richtig motiviert, steht auf den
Seiten 58, 64, 70 und 74
Das Beste beider WeltenRundum agil kommt man meist nicht ins
Ziel. Zu vielunagile Hindernisse wie Festpreise, kulturelle
Differen-zen und Haftungsfragen liegen im Weg. Es gilt daher,die
jeweils passenden Dinge zu kombinieren.
Seiten 96, 100, 124, 133 und 138
SkalierungScaled Agile Framework: Groe Projekte agil umsetzen
100
Change ManagementKontinuierliches Lernen durch Retrospektiven
104
Hybride VerfahrenFestpreisprojekte mit kombinierten Verfahren
109
SchtzverfahrenFunktionsumfnge statt Aufwnde festlegen 112
OrganisationTeambergreifende Projekte mit Kanban umsetzen
118
GlobalisierungInternationale Projekte mit Scrum steuern 124
Compliance & RechtRegeltreueCompliance in agilen Projekten
umsetzen 130
VertragsgestaltungPlanbare Kosten mit agilen Festpreisen 133
ProjekthaftungSo kann man sich gegen Schadensflle absichern
138
DokumentationTestflle in agilen Projekten beschreiben 142
SonstigesEditorial 3
Inserentenverzeichnis 6
Impressum 6
iX Kompakt 2015 Agiles IT-Projektmanagement 5
Alle Links: www.ix.de/ix1516004
Artikel mit Verweisen ins Web enthalten am Ende einenHinweis
darauf, dass diese Webadressen auf dem Server deriX abrufbar sind.
Dazu gibt man den iX-Link in der URL-Zeile des Browsers ein. Dann
kann man auch die lngstenLinks bequem mit einem Klick ansteuern.
Alternativ stehtoben rechts auf der iX-Homepage ein Eingabefeld zur
Verfgung.
-
iX Kompakt 2015 Agiles IT-Projektmanagement
SERVICE | IMPRESSUM/INSERENTEN
MAGAZIN FR PROFESSIONELLE INFORMATIONSTECHNIKiX Kompakt 4/2015
Agiles IT-Projektmanagement
Postfach 61 04 07, 30604 Hannover; Karl-Wiechert-Allee 10, 30625
Hannover
Redaktion: Telefon: 0511 5352-387, Fax: 0511 5352-361, E-Mail:
[email protected]
Chefredakteur: Jrgen Seeger
Konzeption: Jrgen Diercks, Barbara Lange
Redaktionelle Leitung: Jrgen Diercks (-379, [email protected])
Autoren dieser Ausgabe: Kai Altenfelder, Manfred Baumgartner,
Pavlo Baron, Bjrn Berg, Johannes Bergsmann, Frank Dsterbeck, Boris
Gloger, Andrea Grass, Andrea Herrmann, Michael Hofmann, Michael
Httermann, Dirk Jahnke, Martin Klonk, Philip Knott, Veronika
Kotrba,Barbara Lange, Stefan Lange, Klaus Leopold, Tilo Linz, Marc
Lffler, Christoph Mathis, Ralph Miarka,Ralf Mittermayr, Andreas
Opelt, Wolfgang Pfarl, Helmut Pichler, Ilja Preuss, Sandra
Reupke-Sieroux,Andreas Rping, Gregor Sandhaus, Richard Seidl,
Siegfried Tanczos, Uwe Vigenschow, Markus Wittwer, Henning Wolf,
Serhiy Yevtushenko
Abbildungen Can Stock Photo Inc.: mtruchon (Titel, S. 7),
fpfunke (S. 8), OG_vision (S. 13),AndreySt (S. 14), amabrao (S.
18), andriigorulko (S. 22), LORRIANI (S. 28), drudoran (S. 29),
smarnad (S. 31), Otvala (S. 32), Neirfy (S. 36, S. 40), gunnar3000
(S. 41), GekaSkr (S. 53), Zinch (S. 54), albund (S. 58, S. 142),
jonnysek (S. 64, S. 91, S. 92, S. 112), asafeliason (S.
70),donatas1205 (S. 74), azgek (S. 80), Gelpi (S. 86), Arogant (S.
96), johannesk (S. 100), kamchatka (S. 104), Jochen (S. 104),
tobkatrina (S. 109), justmeyo (S. 118), photovova (S. 124), JackF
(S. 129), prill (S. 130), valzan (S. 133), Garry518 (S. 138)
Redaktionsassistenz: Michael Mentzel (mm) -153, Carmen Lehmann
(cle) -387
Korrektorat: Kathleen Tiede, Hinstorff Verlag, Rostock
Layout und Satz: Enrico Eisert, Matthias Timm, Hinstorff Verlag,
Rostock
Titelidee: iX, Jrgen Diercks
Verlag: Heise Medien GmbH & Co. KG, Postfach 61 04 07, 30604
Hannover; Karl-Wiechert-Allee 10, 30625 Hannover; Telefon: 05 11/53
52-0, Telefax: 05 11/53 52-129
Geschftsfhrer: Ansgar Heise, Dr. Alfons Schrder
Mitglied der Geschftsleitung: Beate Gerold
Verlagsleiter: Dr. Alfons Schrder
Anzeigenleitung: Michael Hanke (-167), E-Mail:
[email protected],www.heise.de/mediadaten/ix
Druck: Dierichs Druck + Media GmbH & Co. KG, Kassel
Verantwortlich: Textteil: Jrgen Seeger; Anzeigenteil: Michael
Hanke
iX Kompakt 4/2015 Agiles IT-Projektmanagement: Einzelpreis 9,90,
sterreich 10,90, Schweiz CHF 17,50, BeNeLux: 10,90, Italien:
10,90
Eine Haftung fr die Richtigkeit der Verffentlichungen kann trotz
sorgfltiger Prfung durch die Redaktion vom Herausgeber nicht
bernommen werden. Kein Teil dieser Publikation darf ohne
ausdrckliche schriftliche Genehmigung des Verlages verbreitet
werden; das schliet ausdrcklich auch die Verffentlichung auf
Websites ein.
Printed in Germany
Copyright by Heise Medien GmbH & Co. KG
Die Inserenten
dpunkt.verlag www.dpunkt.de 63, 148
Hanser Verlag www.hanser.de 41
Hostserver www.hostserver.de 2
Orientation in Objects www.oio.de 93
Die hier abgedruckten Seitenzahlen sind nicht verbindlich.
Redaktionelle Grndeknnen nderungen erforderlich machen.
-
iX Kompakt 2015 Agiles IT-Projektmanagement 7
EINFHRUNG | AGILITT
EinfhrendesEs gibt vermutlich nur noch wenige Unternehmen, die
sich nicht mit agilen Entwicklungspraktiken beschftigen. Denn die
haben ihre Vorzge inzwischen bewiesen. Doch auch in der agilen Welt
lsst sich an den Bedrfnissen vorbei programmieren. Wie man es
richtig angeht, mchte dieses Heft zeigen.
In 28 Artikeln: So gelingen agile IT-Projekte 8
-
Scrum, Kanban oder Extreme Programming haben sich inUnternehmen
etabliert, Wasserfallmodelle befinden sichauf dem Rckzug. Trotz
zahlreicher Anpassungen an mo-derne Ansprche gelten lineare
Entwicklungsverfahren immernoch als zu starr und brachten so
manches ehrgeizige Projektzum Absturz. Der vielzitierte
Chaos-Report der Standish Groupuntermauert das regelmig und
anschaulich (siehe Alle Links).Immerhin: Die Untersuchung
attestiert agil durchgefhrten Pro-jekten eine deutlich hhere
Erfolgsquote (Abbildung1). Durchdas stndige Ausliefern lauffhiger
Softwareteile fallen Fehlereher auf und Missverstndnisse lassen
sich schneller aus derWelt schaffen.
Kommunikation als Hauptproblem
Das heit jedoch noch lange nicht, dass die agilen Methoden
injedem Fall der Weisheit letzter Schluss sind, genug
IT-Projektegeraten immer noch ins Trudeln oder werden sang- und
klangloseingestellt. Technische Tcken sind in der Regel allerdings
nichtdie Hauptverursacher der Schwierigkeiten obwohl die
Verant-wortlichen das gern als Ausrede missbrauchen. Meist liegen
dieGrnde fr im Morast steckende Vorhaben in schlechter
Kom-munikation, also im zwischenmenschlichen Wirrwarr. Miteinan-der
sprechen will eben auch gelernt sein.
Schlecht formulierte Anforderungen geben ebenfalls
reichlichAnlass zur Klage, denn oft wei der Kunde nicht, wie die
be-
stellte Software tatschlich aussehen soll. Dieses Phnomen hatden
schnen Spruch IKIWISI geprgt: Ill know it when I seeit. Nach
solchen Vorgaben zu programmieren, drfte viele Ent-wickler in die
Verzweiflung treiben. Und manchmal starten agileTrendsetter im
Unternehmen mit viel Enthusiasmus, der trgeRest zieht jedoch nicht
mit. Denn gerade in groen Organisatio-
8 iX Kompakt 2015 Agiles IT-Projektmanagement
EINFHRUNG | AGILITT
In 28 Artikeln: So gelingen agile IT-Projekte
Nicht in dieFalle tappenBarbara Lange, Jrgen Diercks
Die Einsicht, dass sich in der Software entwicklung nicht
alles
przise planen lsst, hat sich durchgesetzt. Leider haben auch
agile Vorgehensweisen
ihre Tcken, vor allem, wenn sie nur als Feigen-blatt dienen.
Dieses Sonderheft gibt einen
fundierten Einblick in die vielfltigen Aspekte des Themas.
Wasserfall agil
49 %42 %
14 %
29 %
9 %
57 %
gescheiterterfolgreich schwierig
Die Standish Group, Urheber des notorischen Chaos Report,sieht
agile Projekte im Vorteil gegenber traditionellen Ver-fahren. Als
erfolgreich gelten Projekte, die mit allen ge-wnschten Funktionen,
zu den geplanten Kosten und im Zeit-rahmen abgewickelt wurden
(Abb.1).
Que
lle: T
he C
HAO
S M
anife
sto,
The
Sta
ndish
Gro
up, 2
012
-
nen lassen sich undurchlssige Hierarchien, ber Jahrzehnte
ge-wachsene Frstentmer und traditionelle Karrierewege nichtdurch
bloe agile Proklamationen auflsen. Daher gehen ambi-tioniert
gestartete Versuche ebenfalls regelmig in die Hose agil hin oder
her. Oder man lsst die agilen Spinner halt machen,solange sie
keinen greren Schaden anrichten und die gewohn-te Ordnung
bedrohen.
Die Ursachen fr das Scheitern sind jedenfalls zahlreich
undvielfltig. Wer nicht in die blichen Fallen tappen mchte, hatmit
dem Kauf dieses Heftes schon mal einen Schritt in die rich-tige
Richtung getan. Die hier versammelten Artikel stammen zuknapp zwei
Dritteln aus aktuellen Bchern bekannter agiler Pro-tagonisten, zehn
Beitrge wurden exklusiv neu erstellt. Das Fol-gende zeigt eine
bersicht.
Klein anfangen und langsam wachsen
Gelegentlich heit es, man solle einen Elefanten in
Scheibenschneiden, wenn es darum geht, komplexe Vorhaben in
genie-bare Hppchen zu zerlegen. Keine gute Idee, denn der Kundekann
mit ein einzelnen Abschnitten wenig anfangen, wenn dasGanze nicht
funktioniert. Zudem setzt er die Fragmente imZweifel falsch
zusammen, gibt der Autor des Artikels In Ein-klang bringen (S. 22)
zu bedenken. Besser ist es daher, einenkleinen Elefanten langsam
grozuziehen und, bezogen auf agileSoftwareprojekte, sukzessive
einzelne, lauffhige Releases zuliefern (Abbildung2). Dieses
iterative Vorgehen gilt als wesent-liches Merkmal von Scrum und Co.
Das Grundgesetz dafrstellt das agile Manifest (siehe gleichnamigen
Kasten).
Allerdings schtzt die stetige Abgabe solcher Zwischenpro-dukte
die Beteiligten nicht automatisch davor, nutzlose Pro-grammteile zu
produzieren. Warum immer noch viel unbrauch-barer Softwareschrott
hergestellt wird, erfhrt man im ArtikelKein faules Obst auf S. 28.
Denn lngst nicht alle Projektesind agil, auch wenn sie unter dieser
Flagge segeln. GefhrlichesHalbwissen und das Auspacken des
Scrum-Brecheisens fhrenoftmals direkt ins Desaster, kritisieren die
Autoren. InteressanteFragen stellt der Beitrag Definitionssache auf
S. 14. Etwa: Ab
wann lsst sich ein Vorgehen als agil bezeichnen? Eignen
sichagile Methoden fr jedes Unternehmen? Ist es sinnvoll, agileund
traditionelle Verfahren zusammenzurhren? Letztlich kanndie ehrliche
Beschftigung mit diesen Themen zum Ergebnis ha-ben, dass ein
gewnschtes Vorgehensmodell nicht zur Firmen-kultur passt.
Schtz mal, wie lange wir brauchen
Einerseits versuchen agile Projekte gar nicht erst, alle
Detailsvorab festzulegen, andererseits sind sie eingebunden in die
Bud-get- und Zeitplanung der Unternehmen. Jeder will wissen,
wielange es dauert und was es kostet. Im agilen Umfeld helfen
klas-sische Aufwandsschtzungen jedoch meist nicht weiter.
Erfolgversprechender ist es, den Funktionsumfang eines Produkts
zuschtzen. Wie das geht, beschreibt der Artikel Spielerisch
ar-beiten auf S. 112. Er stellt dazu Methoden wie Planning
Poker,Team Estimation Game und Magic Estimation vor.
Auch in der agilen Welt kommen Kunde und Dienstleisternicht um
Vertrge herum, wenn es darum geht, Kosten fr einProjekt zu planen.
Hier bieten sich agile Festpreise an ei-gentlich ein Widerspruch in
sich, aber machbar, wie der ArtikelIm Vertrauen (S. 133) ausfhrt.
Dabei schaffen beide Partner
iX Kompakt 2015 Agiles IT-Projektmanagement 9
Agiles ManifestWir erschlieen bessere Wege, Software zu
entwickeln, indem wir esselbst tun und anderen dabei helfen. Durch
diese Ttigkeit haben wirdiese Werte zu schtzen gelernt:
Individuen und Interaktionen mehr als Prozesse und
WerkzeugeFunktionierende Software mehr als umfassende
DokumentationZusammenarbeit mit dem Kunden mehr als
Vertragsverhandlung Reagieren auf Vernderung mehr als das Befolgen
eines Plans
Das heit, obwohl wir die Werte auf der rechten Seite wichtig
finden,schtzen wir die Werte auf der linken Seite hher ein.
Einen Elefanten in Scheiben schneiden? Besser nicht. Der Kunde
kann nmlich mit dieser Salamitaktik wenig anfangen und setzt
dieTeile eventuell noch falsch zusammen. Besser ist es, den
Elefanten langsam grozuziehen (Abb.2).
Que
lle: F
rank
Ds
terb
eck
-
einen Rahmen, in dem sie sich auf Kosten, Termine und
einegemeinsame Marschrichtung einigen.
Ein hybrides Vorgehen, das klassische und agile
Software-entwicklungsmethoden kombiniert, schlgt der Beitrag
Wie-dervereinigung (S. 109) fr agile Festpreisprojekte vor.
DieStrken iterativer und linearer Modelle zusammenzufhren,versuchen
auch andere Methoden, denn jenseits der Euphoriekann Agilitt einige
Schwierigkeiten verursachen: So gestaltetsich das Verwalten der
Aufgaben in den Backlogs oft mhse-lig, das Rollenkonzept wird
gelegentlich unzureichend umge-setzt, Schtzungen sind immer noch zu
optimistisch und vieleMitarbeiter empfinden ihre Arbeit als zu
kleinteilig getaktet.
Besonders in Festpreisprojekten und greren Teams hat sichdeshalb
das Feature Driven Development (FDD) bewhrt,meint die Autorin des
Artikel Was nicht passt (S. 96).FDD zerlegt jedes Projekt in
Teilvorhaben, die jeweils ein ein-zelnes Feature erstellen.
Unternehmen mssen sich wandeln
Gegen ein Aufweichen agiler Prinzipien wendet sich der
BeitragGanz oder gar nicht (S. 18). Demnach sollte ein
Unterneh-men, das Scrum einfhren will, nicht einfach die Elemente
aus-
10 iX Kompakt 2015 Agiles IT-Projektmanagement
EINFHRUNG | AGILITT
Warum eigentlich agil?Das Entwickeln von Software hat ein Ziel:
Wert zu schpfen durch daseffektive Umsetzen komplexer und
dynamischer Geschftsprozesse.Dies erzeugt immer aufwndigere
Systeme, die einer hohen nde-rungsdynamik unterliegen. Ihr gerecht
zu werden, ist eine der Haupt-aufgaben fr Entwickler.
Grundlage eines Produktes sind die Anforderungen, die es erfllen
soll.Sie werden durch Menschen und deren Interaktionen umgesetzt
(Ab-bildung3). Wer den Produktionsprozess verstehen will, muss sich
auchmit den umliegenden Komponenten beschftigen.
Whrend im Industriezeitalter Menschen in denkende Subjekte
(Ma-nager) und handelnde Objekte (Ressourcen) aufgeteilt wurden, so
sindheute kreative und innovative Kpfe gefragt. Eine erfolgreiche
Soft-wareentwicklung zeichnet sich dadurch aus, dass sie die
Fhigkeitendieser sogenannten Wissensarbeiter bestmglich nutzt. Dazu
gehrt,dass Erkenntnisse aus Psychologie und Wissenschaft, etwa was
dieMotivation und das Zusammenspiel von Menschen angeht,
konse-quent angewendet werden. Neben einer positiven Fehlerkultur
unddem Frdern eines intrinsischen Ansporns zhlt hierzu die
Organisationder Beteiligten in autonom handelnden Teams.
Leider behandeln viele Organisationen heute noch Menschen, die
inihrem privaten Leben schwierige Entscheidungen eigenstndig
treffen,in ihrer ureigenen Wissensdomne, dem beruflichen Alltag,
wie kleineKinder. Ihnen wird von der Geschftsfhrung, der
Gruppenleitung, demProjektmanager oder Projektleiter, dem
Stararchitekten, dem Testma-nager gesagt oder gar befohlen, wann
sie was wie lange tun mssenund drfen. Das degradiert diese Personen
zu den oben genannten Ob-jekten/Ressourcen, demotiviert sie und
erstickt Ideen und Kreativittim Keim. So entsteht eine
Unternehmenskultur, die absolut nichts mitmoderner Wertschpfung zu
tun hat und dem Markt in keiner Weisegerecht werden kann.
Softwareentwicklung funktioniert nicht mit veralteten Prozessen,
Prak-tiken und Methoden des Industriezeithalters. Dies gilt brigens
ebensofr die moderne industrielle Produktion (gerne unter dem
BuzzwordIndustrie 4.0 subsummiert). Hier setzt das agile Manifest
an. Es bil-det den Rahmen fr das, was heute in der
Softwareentwicklung als Vo-raussetzung fr den Umgang mit Komplexitt
und Dynamik gilt. Setztman seine Werte und Prinzipien konsequent
um, hat man das Funda-ment fr eine erfolgreiche Softwareentwicklung
gelegt. Darauf basie-rend kann eine anpassungsfhige Produktion und
eine kundengerechteFertigung entstehen. Wer weiterhin auf dem
Althergebrachten beharrt,wird auf Dauer mit groer
Wahrscheinlichkeit scheitern. Umso erstaun-licher, dass in
Deutschland das Thema Agilitt 14 Jahre nach Verkn-dung des agilen
Manifests noch immer nicht in allen Bereichen der ITEinzug gefunden
hat, und gelegentlich eine regelrechte Angst davorzu spren ist.
Dies mag auch daran liegen, dass Scrum als Prozessrahmen nicht
aus-reicht, die genannten Anforderungen abzudecken. Zum einen fehlt
derRahmen fr den Rahmen. Das heit, Unternehmen mssen
gegebe-nenfalls organisatorische Vernderungen durchfhren, damit
Agilittfunktionieren kann. Zum anderen mssen sie den Rahmen mit
Prozes-sen und Praktiken fr das Anforderungs-, Qualitts- und
Projektma -nagement sowie die Entwicklung ausfllen.
Weitere Grnde fr den noch nicht flchendeckenden Einsatz
agilerVorgehensmodelle sind in den technischen und
infrastrukturellen He-rausforderungen zu suchen. Damit Software
zeitgerecht und in guterQualitt alle xWochen ausgeliefert werden
kann (wie es beispielsweiseScrum fordert), ist die modernste
Technik notwendig. Das erfordert Investitionen in Infrastruktur und
untersttzende Software. Das not-wendige Kleingeld zur Einfhrung hat
jedoch nicht jedes Unternehmenparat. Zudem mssen sie ihre
veralteten, jedoch weit verbreiteten Ar-chitektur- und
Entwicklungskonzepte abschaffen. Das kontinuierlicheAus- und
Weiterbilden der Mitarbeiter sowie das Einbeziehen von Ex-perten
ist dabei unerlsslich. Nur so kann echte Agilitt entstehen,die sich
nicht in Alibiveranstaltungen erschpft. Man sollte sie jedochnicht
als Dogma verstehen, sondern als Hilfsmittel zum Gestalten
desTransitionsprozesses. Frank Dsterbeck
Softwareentwicklung im Zusammenspiel: Wer den Produk
-tionsprozess verstehen will, darf sich nicht nur mit dem
eigentliche Produkt beschftigen, sondern muss das gesamteUmfeld im
Auge behalten (Abb.3).
Que
lle: F
rank
Ds
terb
eck
-
whlen, die ihm gerade passend erscheinen. Wer auf Scrumsetzt,
holt sich nicht nur eine neue Entwicklungsmethode insHaus, sondern
muss Organisationsstruktur sowie Firmenkulturanpassen und steckt
schnell in einem ausgewachsenen Change-Projekt, so die berzeugung
der Verfasser. Man kann einigesfalsch machen bei der Einfhrung: Es
ist jedoch nicht gut, lund Wasser zu mischen. Mit anderen Worten:
Nur auf sehr gro-ber Ebene lassen sich agile Projekte in ein nicht
agiles Umfeldeinbetten.
Das gilt ebenso fr groe sowie globale Vorhaben. Hier zeigtsich
deutlich, dass es nicht nur um das Verndern der Arbeits-weise
einzelner Teams geht, sondern um den Wandel zur agilenOrganisation.
Der richtige Mix (S. 46) steuert praktische Er-fahrungen dazu bei.
Den flankierenden Manahmen widmetsich das Scaled Agile Framework
(SAFe), nachzulesen im Ar-tikel Big Picture auf S. 100. Die Beitrge
Integrationspro-jekt (S. 40) und Rund um die Welt (S. 124) zeigen,
wie manOffshoring und Agilitt zusammenbringt. Und
Zusammenhangherstellen auf S. 118 erklrt, wie sich teambergreifende
Pro-jekte mit Kanban umsetzen lassen. Hier geht es ums groeGanze,
es ntzt nichts, in einem komplexen System nur einzel-ne Komponenten
zu optimieren.
Auch Chefs mssen umdenken
Wenn es wirklich agil werden soll, muss sich die Fhrungs-Crew
ebenfalls bewegen. Beispiele aus sechs Unternehmen pr-sentiert der
Artikel Voll dynamisch auf S. 74. Wenn wir Mit-arbeiter als
Erwachsene behandeln, die Konflikte untereinanderaustragen, statt
den Konflikt auf den Chef abzuwlzen, knnendiese bessere
Entscheidungen treffen, als das in zentralen Gre-mien mglich ist,
so eine der Kernaussagen (siehe KastenWarum eigentlich agil?). Und
wer es richtig ernst meint, kannsogar die Gehlter nach fairen
Gesichtspunkten gemeinsam mitallen Beteiligten festlegen und wre
damit ultimativ agil. Wiees berhaupt dazu kam, dass sich die
Einsicht durchsetzte, Soft-ware nach agilen Prinzipien zu
entwickeln, zeigt der historischeAbriss Evolutionstheorie auf S.
92.
Wie man es garantiert schafft, ein Projekt mit Aplomb in denSand
zu setzen, beschreibt der Artikel Crashkurs (S. 54).
DieMglichkeiten sind zahlreich: Ziele fr sich behalten,
unklareAnforderungen stellen, nur mglichst komplexe Projekte
ange-hen oder autoritr ber die Kpfe der Mitarbeiter hinweg
ent-scheiden. Damit ist der Misserfolg quasi sicher.
Skrumm und schief scheitern
Wenn es zwischen Kunde und Auftragnehmer nicht rund luft,steht
pltzlich Unerquickliches wie Schaden und Haftung imRaum. Wie sich
damit umgehen lsst, und wie man gerichtsfesteNachweise fhrt, erklrt
der Beitrag Wer schreibt, der bleibt aufS. 138. Normen und
Standards schrnken Agilitt ebenfalls ein,etwa wenn ein
ISO-9001-zertifiziertes Qualittsmanagementsys-tem verlangt wird.
Zwar fordert keine Norm einen klassischenEntwicklungsprozess, aber
manchmal ist es erforderlich, den Pro-zess schriftlich
festzuhalten. Mit diesem Abdriften ins Unagile be-schftigt sich der
Text Alles geregelt auf S. 130. Dokumenta-tionen sind auch in
agilen Projekten unerlsslich. An dieser Stelleinterpretieren die
Beteiligten aus Bequemlichkeit das agile Mani-fest oft falsch, wie
die Autoren des Artikels Beweissicherung(S. 142) feststellen.
hnliches gilt fr das Anforderungsmanage-ment, das sich nun auf
seine Kernkompetenzen konzentrieren
muss, aber keinesfalls zum Alteisen gehrt, nachzulesen im
Bei-trag Aufs Wesentliche besinnen (S. 32).
Zum integralen Bestandteil der Qualittssicherung in
derSoftwareentwicklung gehrt das Testen. Anders als in klassi-schen
Methoden gibt es bei den agilen Verfahren hierfr keineeigene Phase:
Die Tests laufen in jedem Sprint mit, und das ge-samte Team ist
dafr verantwortlich. Die erforderlichen Ma-nahmen beschreibt der
Artikel Permanente Kontrolle (S. 36).
Kommunizieren und Konflikte lsen
Teams sollen sich selbst organisieren, iterativ entwickeln
undganz viel kommunizieren im stillen Kmmerlein sind DailyScrums
und Retrospektiven jedoch nicht mglich. Mehrere Bei-trge
thematisieren das in der Rubrik Kommunikation&SoftSkills,
letztlich aber zieht sich diese Sache wie ein roter Fadendurch das
ganze Heft.
Einen Lsungsweg fr Konflikte bietet die sogenannte ge-waltfreie
Kommunikation (Bedrfnisbefriedigung auf S. 64).Der psychologische
Ansatz aus den 1970er-Jahren geht davonaus, dass sich hinter jedem
Verhalten eine positive Absicht verbirgt, mit der ein Mensch
versucht, seine fundamentalen Be -drfnisse zu erfllen. Der Beitrag
stellt das notwendige Hand-werkszeug vor, das man bentigt, um agile
Teams zu Hchst-leistungen zu animieren.
Die fnf sozialen Grundbedrfnisse klassifiziert eine
psycho-logische Methode namens SCARF: Status, Certainty
(Sicher-heit), Autonomy (Selbstbestimmtheit), Relatedness
(Zugehrig-keit) and Fairness (Gerechtigkeit). Sieht jemand eins
oder garmehrere dieser Bedrfnisse gefhrdet, ist Kooperation
kaumnoch mglich, schreiben die Autoren im Artikel
Konfliktbe-wltigung (S. 58). Das vorgestellte Modell erleichtert
das Ver-stehen menschlicher Verhaltensweisen enorm.
Man sieht, es gibt viele Aufgaben fr einen agilen
Coach,dargestellt im Beitrag Rollenspiele (S. 70). hnlich wie
derScrum Master begleitet der Coach das Team durch den
Entwick-lungsprozess. Er moderiert die Meetings und achtet darauf,
dassdie agilen Werte nicht im Alltagsgeschft verlorengehen.
Grund-stzlich soll er dem Team den Weg ebnen, damit es sich auf
sei-ne Arbeit konzentrieren kann und sich nicht in
administrativenKleinkram verzettelt.
Wie man Meetings gut vorbereitet, erlutert der ArtikelBlick
zurck (S. 104) am Beispiel der Retrospektiven. In ei-nem Workshop
schaut das Team auf die letzten Wochen undMonate, um daraus
Erkenntnisse fr die Zukunft zu gewinnen.Wichtig ist dabei, wie man
Ergebnisse visualisiert, damit dieTeilnehmer des Workshop nicht
einschlafen. Die zugehrigeTechnik namens Visual Facilitation,
vermittelt der ArtikelWie gemalt auf S. 80.
Wie die Arbeitsumgebung agiler Teams aussehen sollte, skiz-ziert
der Beitrag Angenehme Atmosphre (S. 86). Zwischennervigem
Groraumbro und Einzelzelle gibt es Alternativen:Gemeinsame
Arbeitsbereiche, Rckzugsgebiete sowie eine Kom-mandozentrale sollen
die gegenstzlichen Bedrfnisse nach Nheund Distanz ausbalancieren.
(jd)
Barbara Langeist IT-Journalistin und Inhaberin des
Redaktionsbros kurz und einfach in Lengede.
12 iX Kompakt 2015 Agiles IT-Projektmanagement
EINFHRUNG | AGILITT
Alle Links: www.ix.de/ix1516008 x
-
iX Kompakt 2015 Agiles IT-Projektmanagement 13
QualitativesAgil hin oder her: Immer noch muss sich der
Konsument mit unbrauchbarer oder zweifelhafter Software
herumschlagen. Zwar knnen moderne Ent -wicklungsmethoden helfen,
die Lcke zwischen Wunsch und Wirklichkeit zu verkleinern, eine
Garantie dafr gibt es jedoch nicht. Denn auch agile Methoden muss
man erlernen und beherrschen.
Agiles Projektmanagement: Eine Illusion? 14
Scrum nachhaltig im Unternehmen einfhren 18
Genauere Schtzungen durch Komplexittsreduzierung 22
Werte schaffen mit sinnvollen Inkrementen 28
Requirements Engineering in der agilen Entwicklung 32
Software testen im agilen Entwicklungsprozess 36
Agile Techniken und Offshoring zusammenbringen 40
Vom agilen Projekt zum agilen Unternehmen 46
-
D er Begriff agil ist so positiv besetzt, dass
entsprechendeVerfahren ohne weitere Qualifizierung traditionellen
ber-legen erscheinen. Der wegen zu oberflchlicher
Betrach-tungsweise besorgte Agilist drfte rasch darauf hinweisen,
dasses ja gute Grnde dafr gibt, zum Beispiel, weil agile
VorgehenVerschwendung vermeiden sollen. Das bringt den
traditionellenVertreter selbstverstndlich auf die Palme, schlielich
bedienter sich mit viel Erfahrung der Best Practices, da kann von
Ver-schwendung keine Rede sein. Schnell zeigt sich, dass eine
ver-nnftige Auseinandersetzung zwischen Protagonisten beiderWelten
nicht einfach ist.
Beide Seiten tragen diesen Konflikt emotional und somithufig
leider unsachlich aus. Zuschauer der Auseinandersetzung,die fr sich
entscheiden mssen, welchen Weg sie einschlagenwollen, stehen ratlos
daneben. Sie knnen sich mitreien lassenoder versuchen, einen
eigenen Weg zu finden. Aber wie soll dasgehen?
Uneinigkeit bei der Einordnung
Eine der Ursachen fr die Schwierigkeiten bei der
Betrachtungbeider Anstze knnte darin liegen, dass ungleiche Dinge
ver-glichen werden. Das Project Management Institute (PMI)
be-schreibt traditionelles Projektmanagement als die Anwendungvon
Wissen, Knnen, Werkzeugen und Techniken auf Projekt-aktivitten, um
bestimmte Anforderungen zu erfllen. Die Ge-sellschaft fr
Projektmanagement (GPM) sieht es hnlich, ge-nauso wie die DIN- und
ISO-Normen. Fr IT-Projekte stellt dasPITPM (Pragmatisches
IT-Projektmanagement) eine Reduktion
des allgemeingltigen Project Management Body of Know -ledge
(PMBOK) der PMI auf Belange der IT-Projekte dar undmacht somit die
umfangreiche Methodensammlung leichter zu-gnglich und handhabbar
(siehe Alle Links).
Diese Anstze teilen die Idee, dass zu Beginn ein Projekt
for-muliert und in weiteren Phasen umgesetzt wird. Im Grundsatzist
das der Gedanke des Wasserfallmodells. Beim agilen Vorge-hen lohnt
sich ein Blick auf Scrum als den derzeit strksten Ver-treter. Schon
bei Kanban ist man sich uneinig darber, ob es sichberhaupt um ein
agiles Modell handelt. Solche Anstze bezie-hen sich auf das agile
Manifest mit seinen vier Kernaussagen,die die Grundwerte und
Prinzipien entsprechender Vorgehens-modelle festlegen. Scrum bietet
ein Framework an, das im kon-kreten Projektfall mit Leben gefllt
werden muss.
Der Scrum-Guide legt in einem 20-seitigen Dokument denRahmen
fest, und der ist viel kleiner als in allen traditionellenVerfahren
(siehe Alle Links). Das zeigt deutlich, dass vieleThemen, die
allgemein Scrum zugeordnet werden, vermutlichgar nicht so auf
dieses Vorgehen festgelegt sind. In der Tat bietetder Guide
reichlich Spielraum fr eine projektspezifische Ge-staltung. Es ist
Aufgabe des Teams, ihn zu erkennen und zu nut-zen. Allein diese
distanzierte Betrachtung der traditionellen undagilen Modelle
zeigt, wie unterschiedlich die Schwerpunkte ge-lagert sind. Auf der
traditionellen Seite stehen Prozesse undWerkzeuge im Mittelpunkt,
auf der agilen Seite Werte, Prinzi-pien und nur wenige feste
Regeln.
Somit stellt sich die Frage, ob man die beiden Welten
nichtzusammenbringen kann. Wenn sie so unterschiedliche
Eigen-schaften festlegen, sollte es doch mglich sein, mit einem
soge-nannten agilen Projektmanagement, das sich jedoch nur
einiger
14 iX Kompakt 2015 Agiles IT-Projektmanagement
PROJEKTE & QUALITT | METHODENKRITIK
Agiles Projektmanagement: Eine Illusion?
Definitions sacheDirk Jahnke
Ab wann ist ein Projekt agil? Und ist agil immer gut? Wer diese
Fragen
seris beantworten will, muss genau hinschauenund darf vor allem
nicht jedem Hype hinter-
herlaufen. Denn oftmals funktioniert dasgewnschte Vorgehens
modell nicht,weil es schlicht nicht zur Unterneh-menskultur
passt.
-
ausgesuchter agiler Praktiken bedient, zu arbeiten. Das
Folgen-de betrachtet die Sache aus zwei Perspektiven: Zum einen
wer-den die Rollen untersucht und insbesondere die Rolle des
Pro-jektmanagers im agilen Umfeld kritisch beleuchtet. Zumanderen
wird das gesamte Umfeld in seiner Ausprgung als Fir-menkultur
daraufhin geprft, wie gut sich agile und traditionel-le Anstze
einfgen.
Im traditionellen Projektmanagement geht es um die Rolledes
Projektmanagers, in Scrum um die Rollen des ProductOwners, des
Entwicklungsteams sowie des Scrum Masters (Ab-bildung1). Diese
Betrachtungsweise ist etwas verkrzt, es exis-tiert zustzlich ein
Umfeld mit Management und Stakeholdernin beiden Umgebungen, die
ebenfalls Einfluss ausben bezie-hungsweise aus dem Projekt heraus
Informationen und Ergeb-nisse erhalten mssen.
Der Projektmanager ist als zentrale Person mit allen
Befug-nissen ausgestattet, um die gewnschten Methoden anzuwen-den.
Er bekommt ein Ziel und ein Budget vorgegeben, das er imIdealfall
im Vorfeld mitgestalten darf. Im Rahmen der Projekt-durchfhrung
kann und muss er bestimmen, wer wann welcheTtigkeiten durchzufhren
hat. Er setzt Prioritten, legt Reihen-folgen fest und steuert auf
diese Weise Abhngigkeiten. Selbst-verstndlich holt ein erfahrener
Projektmanager beim Entwick-lungsteam Meinungen ein und
bercksichtigt sie auch. Er istzentrale Ansprechperson und
Entscheidungsstelle fr alle Be-lange des Vorhabens. Ist er nicht in
der Lage, eine Entscheidungzu treffen, wird sie beispielsweise in
einem Steuerkreis eskaliert,in dem Management und Stakeholder
sitzen.
Das Team ist Entscheidungstrger
In agilen Projekten funktioniert es anders: Hier geht es um
geteilteund gemeinsame Verantwortung. Gemeint ist damit, dass alle
Rol-len (Product Owner, Entwicklungsteam, Scrum Master) gemein-sam
am Erfolg gemessen werden. Das gesamte Team bestimmt,wo es
langgeht, nicht eine einzelne Person. Dafr sind
Entschei-dungsprozesse ntig, die etwas komplizierter sein knnen. Es
istAufgabe des Scrum Masters, die Ablufe so zu moderieren, dassam
Ende ein fr alle Beteiligten tragfhiges Ergebnis steht.
Ein geeigneter Fhrungsstil in agilen Teams ist das Fhrendurch
Dienen (Servant Leadership). Der Scrum Master ach-tet darauf, dass
alle Beteiligten die Prinzipien, die im agilen Vorgehen von
Bedeutung sind, einhalten. Der Product Ownerfungiert als
Schnittstelle zu den Stakeholdern, klrt die fach -lichen Fragen im
Projekt und ist insbesondere dafr verantwort-lich, dass am Ende ein
Produkt entsteht, das den gewnschtenGeschftsnutzen liefert.
Besonders gefordert ist das Entwicklungsteam: Es entscheidetber
technische Angelegenheiten, somit ber die Architektur, undliefert
nach jedem Sprint ein Produktinkrement. Damit das lang-fristig
gelingt, muss das Unternehmen in technische Aufgaben
iX Kompakt 2015 Agiles IT-Projektmanagement 15
Typen von Unternehmenskulturen William Schneider identifizierte
vier Typen fr Unternehmenskulturen:Control, Collaboration,
Competence und Cultivation. Welche in einemUnternehmen vorherrscht,
bestimmt sich durch verschiedene Fakto-ren, insbesondere sind
Erfahrungen aus der Vergangenheit entschei-dend: Was machte das
Unternehmen erfolgreich? Wer hat es gefhrtbeziehungsweise gegrndet
und mit welchem eigenen Hintergrundbezglich Geschichte, Natur und
Erfahrungen in der Sozialisierung?Mit welcher Wahrnehmung, was
notwendig ist, um in einem Markterfolgreich zu sein? Schneider
beschreibt die vier Kernkulturen wiefolgt:
Control: Hier dreht sich alles um Sicherheit, Vorhersagbarkeit,
Genau-igkeit und Zuverlssigkeit. Die Organisation selbst steht an
erster Stel-le. Alles konzentriert sich auf das Erreichen der
Unternehmensziele.Begriffe, die zur Control-Kultur passen, sind:
formale Prozesse, Key Per-formance Indicators, Management by
Numbers, TQM, Just in Time,Rightsizing, Robotik, Automatisierung,
autoritre Fhrung, Hierarchie,Compliance, Systematik.
Collaboration: Synergien stehen hier im Vordergrund. Diese
Organi-sationen existieren, um Gemeinschaften zu bilden, oder eine
enge Ver-bindung mit den Kunden einzugehen. Sie zeichnen sich durch
ihreHingabe zum Kunden aus. Eine Collaboration-Kultur erreicht
Fort-schritt durch die vielfltigen Erfahrungen der Menschen
innerhalb undauerhalb des Unternehmens. Begriffe, die zur
Collaboration-Kulturpassen sind: Teams, Diversity, Customer
Loyality, Open Door Policy,partizipatives Management,
selbstbestimmte Teams, High Perfor-mance Work Teams, Brainstorming,
Group Facilitation, Fhren durch
Konsens, Synergie, Win-Win, Coaching, demokratisch, Team
Player,Vertrauen, Kameradschaft.
Competence: Unternehmen der Competence-Kultur geht es um
denUnterschied, den ihre Produkte und Dienste ausmachen. Es ist die
Kul-tur der einzigartigen Produkte und Dienstleistungen.
Informationenund Wissen haben einen hohen Stellenwert, sie richten
sich an denkonzeptuellen Zielen des Unternehmens aus. Begriffe, die
zur Compe-tence-Kultur passen sind: Knowledge Capital, virtual
Organization,Benchmarking, Entrepreneurial Management, Excellence,
Best Practice,Continuous Improvement, Matrix Management,
Kernkompetenzen,leistungsabhngige Bezahlung, Standard Setter,
Experten, Spezialisten,analytisches Vorgehen, Professionalitt.
Cultivation: In dieser Kultur geht es um Bereicherung. Die Unter
-nehmen tun alles, um ihre Kunden wachsen zu lassen, ihre
Potenzialeauszuschpfen und zu entwickeln. Es geht ihnen um die
Verwirkli-chung von Idealen, Werten und Zwecken hherer Ordnung.
Begriffe,die zur Cultivation-Kultur passen sind: Empowerment,
Employee Com-mitment, Fhren ist eine Kunst, Fhren nach Prinzipien,
Entrepreneu-rial Management, Qualitt des Arbeitslebens, soziale
Verantwortung,charismatisches Fhren, Spirit at work, Enlightened
Leadership,Selbstverwirklichung, persnliche Entwicklung,
evolutionr, partizipa-tiver Fhrungsstil, Fehler machen drfen.
Schneider beschreibt diese Kulturen detailliert in seinem 1994
verf-fentlichten Werk [1]. Selbstverstndlich treten diese
Kategorien seltenin reiner Form auf, jedoch lsst sich immer
feststellen, welche Kulturdominant und somit mageblich ist.
Mgr = Manager, Fhrungskraft | SH = Stakeholder | Dev =
Entwickler PM = Projektmanager | SM = Scrum Master | PO = Product
Owner
Traditionelles Projektteam Agiles Projektteam
MgrSHSH
Mgr
Dev Dev
DevDev
POSMDev
Dev Dev
DevDev
Mgr Mgr
Mgr
SHSH
PM
Dev
Rollenverteilung: Im traditionellen Team steht der
Projektmana-ger im Zentrum des Geschehens, das agile Scrum-Team
teilt sichdie Verantwortung (Abb.1).
-
investieren, zum Beispiel in Refactoring-Manahmen, die an
sichkeinen Business Value haben. Selbstverstndlich treten in
diesemSpannungsfeld verteilter und gemeinsamer
Verantwortlichkeitenberschneidungen auf, die Konfliktpotential
besitzen. An diesenStellen mssen die Beteiligten verhandeln ein
Vorgang, der imtraditionellen Vorgehen kaum vorstellbar ist.
Neue Rollenverteilung ist gefragt
In der traditionellen Projektarbeit kennen die Mitarbeiter die
Rol-lenverteilungen und haben in der Regel Fhigkeiten und
Eigen-schaften entwickelt, die ein Projektmanager blicherweise
ben-tigt. Kann man in solch einer Umgebung einfach ein
Projektaussuchen, um es probehalber agil durchzufhren? Welche
Rollenimmt der bisherige Projektmanager in einem neuen Szenarioein?
Als Product Owner htte er zwar einen groen Anteil an dergewohnten
Verantwortung, aber es liegt nicht mehr alles in seinerHand, denn
um die technischen Aspekte kmmert sich das Team.Und die Stories
muss er ebenfalls mit dem Team verhandeln.
Das Team bestimmt auch den Umfang von Sprints, der Pro-duct
Owner soll jedoch dafr vor dem Stakeholder geradeste-
hen. Methodisch beeinflusst der Scrum Master die Arbeit imTeam.
Ein Projektmanager kann diesen Teil vorgeben und da-mit eine Menge
Diskussionen abkrzen. Und wer legt die Sprint-dauer fest? Soll man
alle zwei Wochen eine Retrospektivedurchfhren? Es hat doch bisher
gereicht, das am Projektendezu erledigen und die Ergebnisse fr die
Nachwelt festzuhalten.Der Projektmanager knnte hier schnell den
Eindruck gewin-nen, dass zu viel Zeit verschenkt wird, die besser
in wertvolleImplementierungsarbeiten investiert wre. Aber er darf
nichtmehr so optimieren, wie er es fr richtig hlt.
Es ist also kaum mglich, einfach mal ein Projekt agil
durch-zufhren. Die Vernderungen wren zahlreich, ebenso wie
dieGelegenheiten, in alte Muster zurckzufallen. Denn dass die alten
Muster ebenfalls erfolgreich sein knnen, darf nicht in
Vergessenheit geraten. Neu und agil allein fhren nicht zumErfolg.
Es stellt sich nun die Frage, was agiles Projektmanage-ment
eigentlich ausmacht. Wie viel Agilitt ist damit gemeint?Wenn man
das agile Manifest zu stark verndert, sind die be-schriebenen
Schwierigkeiten vorhersehbar. Solange nur einzelnePraktiken aus der
agilen Welt zum Einsatz kommen, etwa dasbewhrte Time Boxing oder
regelmige Retrospektiven, blei-ben die bekannten Rollenverteilungen
jedoch erhalten und diebeschriebenen Probleme treten nicht auf.
Aber sollte man dasschon agiles Projektmanagement nennen?
Unternehmen sind lebende Organismen
Bisher lag der Fokus auf den Mitwirkenden, den Auswirkungenauf
ihre Arbeitsweise und die Art der Entscheidungsfindung.Nun geht es
um die Einbettung in eine Unternehmensumgebung.Hier nehmen
Management und Stakeholder ebenso Einfluss wiealles andere, was im
Betrieb blich ist, also die Unterneh-menskultur. Doch was zeichnet
die aus? Zu diesem Thema exis-tieren verschiedene
Erklrungsversuche, hier soll das Modellvon William Schneider Licht
in die Sache bringen [1], der un-tersucht hat, warum neue
Management-Ideen manchmal funk-tionieren und manchmal eben nicht.
Er vergleicht Unternehmenmit lebenden Organismen und zeigt, dass
komplexe Wirkungs-modelle notwendig sind, um sie adquat zu
beschreiben. Ein-deutig steht bei ihm an erster Stelle, dass
Unternehmenskulturenmchtiger sind als alle anderen Einflsse. Die
identifiziertenGrundtypen nennt Schneider Control, Collaboration,
Compe-tence und Cultivation (siehe Kasten Typen von
Unternehmens-kulturen).
Danach konzentriert sich jede Organisation entweder aufdas, was
derzeit gilt (Actuality). oder auf die Mglichkeiten(Possibilities).
Unternehmen der erstgenannten Kategorie ar-beiten mit Konkretem,
Berhrbarem, mit Fakten, Dingen, diein der Vergangenheit liegen oder
gerade geschehen. Die derzweiten Sorte beschftigen sich dagegen mit
Einsichten, Din-gen, die in der Zukunft geschehen knnen, Idealen,
berzeu-gungen, Neuerungen, Innovationen, kreativen Optionen
odertheoretischen Konzepten.
Eine weitere Eigenschaft zur Unterscheidung von Kulturenist der
Organisationsprozess, also die Antwort auf die Frage,wie eine
Organisation Dinge entscheidet und beurteilt. JedesUnternehmen
betont entweder unpersnliche/sachorientierteAnalysen oder
persnliche/zwischenmenschliche Beteiligung.Die Kennzeichen einer
Kultur der sachorientierten Entschei-dungen lassen sich mit
folgenden Begriffen beschreiben: Sys-teme, Policies,
Arbeitsanweisungen, berechnungsorientiert,wissenschaftlich,
objektiv, prinziporientiert, Gesetze, Formali-tten, gefhlsfrei,
vorschriftsmig. Eine Kultur der personen-
16 iX Kompakt 2015 Agiles IT-Projektmanagement
PROJEKTE & QUALITT | METHODENKRITIK
Actuality
Possibility
Control
Competence
Impersonal
Collaboration
Cultivation
Personal
customer collaboration
daily scrum
sprint-retro spectives
Maintain a constant pace
burndownself-organizing teams
Business people and developers must work together daily
velocityindividuals and
interactions
sprint-reviews
technical exellence and good design
early and continues delivery of valuable software
Build projects around motivated individuals
face-to-face communication
Scrum im Kulturenmodell: Die agilen Aspekte hufen sich in
denSektoren Cultivation und Collaboration (Abb.2).
ProjectManagement
Agile
Actuality
Possibility
Control
Competence
Impersonal
Collaboration
Cultivation
Personal
Agile und traditionelle Vorgehensmodelle im Kulturenmodell:Der
Schwerpunkt traditioneller Methoden liegt eindeutig in denBereichen
Control und Competence (Abb.3).
-
bezogenen Entscheidungsfindung wird umrissen durch: orga-nisch,
evolutionr, dynamisch, partizipativ, subjektiv,
informell,open-ended, orientiert am Menschen, gefhlsbetont.
Warum Management-Ideen scheitern
Diese beiden grundstzlichen Unterscheidungsmerkmale
frUnternehmenskulturen lassen sich als zwei Achsen eines
Koor-dinatensystems betrachten. Es entsteht eine
Vier-Feld-Darstel-lung der wesentlichen Unternehmenskulturen (siehe
KastenUnternehmenskulturen nach Managementpraktiken). Schnei-der
verwendet diese Darstellung, weil er in der Missachtung
derUnternehmenskulturen einen der Hauptgrnde sieht, dass
neueManagementideen hufig scheitern. Das gilt vor allem, wenn
sienicht zur Kultur des Unternehmens passen.
Wie fgt sich das agile Projektmanagement ins Kulturenmo-dell
ein? Fr die Vorgehensmodelle bietet das agile Manifest mitseinen
vier Kernwerten eine gute Grundlage. Noch hilfreichersind die
daraus abgeleiteten zwlf Prinzipien. Wenn man sie aufdas
Kulturenmodell abbildet, so entsteht eine Matrix (Abbil-dung2). Es
ist deutlich erkennbar, dass sich die Aspekte in denSektoren
Cultivation und Collaboration hufen. Diese Darstel-lung enthlt
schon Scrum-Artefakte wie Velocity und Burn-down, obwohl die nicht
zu den Prinzipien gehren. Das soll ver-deutlichen, dass es sehr
wohl agile Praktiken gibt, die sich auchanderen Kulturformen
zuordnen lassen.
Eine hnliche Betrachtung kann man fr das
traditionelleProjektmanagement durchfhren, ebenso wie fr jeden
anderenAnsatz, etwa das hauseigene Projektmanagement-Modell.
DasBetrachten der traditionellen Modelle fhrt zu einem
offensicht-lichen Ergebnis. Zur Erinnerung die PMI-Interpretation
vonProjektmanagement: Die Anwendung von Wissen, Knnen,Werkzeugen
und Techniken auf Projektaktivitten, um Projekt -anforderungen zu
erfllen. Der Schwerpunkt liegt eindeutig inden Bereichen Control
und Competence (Abbildung3).
Zu viel Verquickung ist schlecht
Das Ergebnis drfte nicht berraschen. Es sei an dieser
Stelleausdrcklich erwhnt, dass mit der Betrachtung der Kulturenund
der Vorgehensmodelle keine Wertung einhergeht. Ziel istnicht, eine
Kultur mit einer anderen in ihrer Wertigkeit zu ver-gleichen. Diese
Kulturen existieren, weil Unternehmen in ih-ren Umgebungen damit
erfolgreich waren. Somit hat jede ihreBerechtigung, ebenso wie
smtliche Vorgehensmodelle. DieserBeitrag soll verdeutlichen, dass
ein Zusammenwerfen von Agi-litt und traditionellem
Projektmanagement ein zu groes Feldabdeckt und somit alle
Kulturformen einschliet. Das wre qua-si die eierlegende
Wollmilchsau. Dadurch wrden Kulturbrcheschon in das Vorgehensmodell
einflieen. Das passiert beispiels-weise, wenn man agil in einem
Control-betonten Unternehmenarbeiten mchte. Es entstehen Risse, in
der Regel zwischen demagilen Team und dem Umfeld in Form von
Management undStakeholder. Besonders zu spren bekommt das der
ProductOwner in einem Scrum-Projekt sowie die Mitglieder des
Ent-wicklungsteams. Das bremst schnell die Motivation.
hnliche Betrachtungen lassen sich fr andere Vorgehens-modelle
durchfhren. Michael Sahota beschreibt zum Beispiel,dass Kanban der
Control-Kultur zuzuordnen ist und SoftwareCraftmanship (siehe Alle
Links) der Competence-Kultur.
Traditionelle und agile Vorgehensweisen weisen deutliche
Un-terschiede auf, und es ist nicht Erfolg versprechend, durch
wildes
Vermischen der Prinzipien ein agiles Projektmanagement
zuschaffen. Es spricht jedoch nichts dagegen, sich im
Werkzeugkas-ten der Methoden zu bedienen. Aber vor der unbedachten
Einfh-rung agiler Aspekte in traditionelle Projekte mit der
Erwartung,die beste Vorgehensweise zu verwenden, kann nur
eindringlichgewarnt werden. Auch stellt agiles Projektmanagement,
dasssich nur ein paar Teile aus dem agilen Fundus herauspickt,
keinensanften bergang zur wirklich agilen Arbeitsweise dar.
Das Anwenden agiler Methoden in Control- oder
Compe-tence-Kulturen fhrt zu Kulturbrchen an den Schnittstellen.Das
kann gehrige Frustrationen auslsen und eine erhhteFluktuation nach
sich ziehen, weil Mitarbeiter es in diesemSpannungsfeld nicht
dauerhaft aushalten. Hufig ist das ndernder
Unternehmensorganisation und -spielregeln jedoch keineOption. Es
muss die Erkenntnis erlaubt sein, dass ein ge-wnschtes
Vorgehensmodell eventuell nicht zu einem Unter-nehmen passt.
(jd)
Literatur[1]William E. Schneider; The Reengineering
Alternative;
A Plan for Making Your Current Culture Work; Burr Ridge,IL;
Irwin Professional Publishing, Inc., 1994
Dirk Jahnke ist bei der adesso AG als Berater sowohl in agil als
auch traditionell gefhrten Projekten sowie als Coach oder
Mitarbeiter in verschiedenen Rollen ttig.
iX Kompakt 2015 Agiles IT-Projektmanagement 17
Unternehmenskulturen nach Management-Praktiken
Trgt man die Kulturen aus Schneiders Modell auf zwei Achsen
auf,ergibt sich eine Vier-Feld-Einteilung (Abbildung4).
Auf der vertikalen Achse steht, wem die Aufmerksamkeit im
Unter-nehmen primr gilt (Inhalt/Content der Kultur). Die beiden
Endpunk-te sind die Gegenwrtigkeit, also der Bezug auf das Jetzt
oder dieVergangenheit (Actuality) im Gegensatz zu dem nach vorne
gerich-teten Blick auf die Mglichkeiten (Possibility).
Die horizontale Achse zeigt an, wie im Unternehmen in der
Haupt-sache Entscheidungen oder Beurteilungen gefllt werden
(Prozessder Kultur): unpersnlich/sachlich (impersonal) im Gegensatz
zumstarken Bezug auf den Menschen (personal).
Actuality
Possibility
Control
Competence
Impersonal
Collaboration
Cultivation
Personal
Basiskulturen nach Schneider: Auf den vier Quadranten lassensich
die vier Kulturtypen einordnen (Abb.4).
Alle Links: www.ix.de/ix1516014 x
-
S chweigen neun Augenpaare sehen ihn an. Florian, derseit zwei
Monaten Scrum Master ist und beharrlich darumkmpft, den Teamgeist
zu strken, berkommt ein mulmi-ges Gefhl. Was nun? Dabei hatte er
nur nach Lehrbuch eineRetrospektive anmoderiert. Und nun dies: Sie
schweigen ihn an.Wo ist der Team-Spirit, von dem andere so
schwrmen, wennsie von geglckten Scrum-Projekten sprechen?
So oder so hnlich wie Florian drfte es vielen gehen, dieScrum
einfhren und feststellen, dass die Regeln zwar einfachsind, jedoch
schwierig umzusetzen. Was macht eine gute Scrum-Einfhrung aus?
Woran merkt man, dass man auf dem falschenWeg ist? Darum soll es
hier gehen.
Agilitt in der Softwareentwicklung hat mittlerweile
denMainstream und den Golfplatz erobert. Obwohl viele Unterneh-men
bereits Scrum einsetzen, erreichen nur wenige die erhofftenZiele.
Zum Beispiel schaffen sie es nicht, eine krzere Zeitspan-ne
zwischen Produktidee und Auslieferung zu etablieren.
Einverbessertes Projekt-Controlling bekommen sie nicht hin. Undbeim
Frdern der Mitarbeitermotivation durch mehr Selbstbe-stimmung in
der Arbeitsgestaltung hapert es ebenfalls.
Geht man durch einen Betrieb, in dem Agilitt Einzug gehal-ten
hat, so nimmt man dies zunchst durch die vernderten Ar-beitsweisen
mancher Mitarbeiter wahr: Es gibt selbstorganisierte
Teams, mehr direkte Kommunikation, ritualisierte Treffen zumTeil
im Stehen und Unmengen von Klebezetteln an Brown-den und -tren.
Yes, we do Scrum, but
Manche Unternehmen entscheiden sich dafr, Agilitt einzufh-ren,
indem sie den Werkzeugkasten der Projektleiter um Prakti-ken aus
Scrum erweitern. Was vernnftig klingt, ist eine Vari-ante von
Scrum-But und schon der erste Schritt auf dem Wegzum Scheitern.
Scrum-But bedeutet, aus der Methode nur dieElemente auszuwhlen, die
einem passend erscheinen (Yes, wedo Scrum, but ). Scrum ist jedoch
keine Werkzeugkiste, son-dern eher vergleichbar mit einer Schweizer
Taschenuhr. DieWerte und Prinzipien der Agilitt bilden das Uhrwerk,
in demdie Zahnrder przise ineinandergreifen; an der
Oberflchesichtbar sind das Zifferblatt, die Zeiger (Scrum-Rollen,
Mee-tings, Artefakte). Ohne Werte und Prinzipien bleibt Scrum
eineleere Hlle. Wer auf Scrum setzt, holt sich nicht nur eine
neueEntwicklungsmethode ins Haus, sondern muss
Organisations-struktur sowie Firmenkultur anpassen und steckt
schnell in ei-nem ausgewachsenen Change-Projekt.
18 iX Kompakt 2015 Agiles IT-Projektmanagement
PROJEKTE & QUALITT | FIRMENKULTUR
Scrum nachhaltig im Unternehmen einfhren
Ganz oder gar nichtMichael Hofmann, Andrea Grass
Wenn ein Unternehmenseine Entwicklungs -prozesse agil
gestaltet,
kann es echte Fortschritteerzielen. Die Sache kann
jedoch auch nach hinten los gehen nmlich dann, wenn Agilitt
lediglich als Feigenblatt fungiert. Erfolg stellt sich nur ein,
wenn man alle Beteiligten von Anfang
an mit auf die Reise nimmt.
-
Wie sich ein Change-Projekt gestalten lsst, hat John PaulKotter
bereits in den 90er-Jahren mit drei Phasen Sensibilisie-rung,
Mobilisierung, Umsetzung und insgesamt acht Schrittendes Wandels
dargelegt [1]. Die Tabelle Change-Prozess nachKotter zeigt, wie ein
Unternehmen den Change-Prozess zumEinfhren von Agilitt nutzen kann
und wie sich die Kotter-schen Phasen und Schritte umsetzen lassen.
Die folgenden Ab-stze beschreiben, was beim Einfhren von
Agilitt/Scrum allesschiefgehen kann.
Wenn es bei der Sensibilisierung (Phase1) und der Mobili-sierung
(Phase2) Defizite gibt, zeigen sie sich bei der Umset-zung
(Phase3). Ein Beispiel aus der Praxis: Um niemanden aufder Reise in
eine neue Arbeitswelt zu verlieren, gibt es manch-mal das Bestreben
Wir nehmen alle mit und fhren Vernde-rung daher behutsam ein
(Phase3). Dies kann jedoch auch zulangsam geschehen, das Ganze wird
zum Schneckenrennen.Aufgeschlossene Kollegen werden ungeduldig,
weil sich kaumetwas ndert und gleichzeitig gibt es andere, die
nicht mitreisenwollen. Hier zeigt sich, wie wichtig eine
ausreichende Sensibi-lisierung ist. Im mittleren Management erzeugt
die Scrum-Ein-fhrung sowohl Chancen als auch Probleme, da alte
Karriere -
pfade als Projektleiter oder Softwarearchitekt in Scrum
keineEntsprechung finden. Hier mssen die Verantwortlichen
frh-zeitig Klarheit darber schaffen, was aus den Kollegen wird,
dieRollen besetzen, die in Scrum nicht existieren.
Die innere Einstellung ist entscheidend
Zu Beginn gilt es, ausreichend Bewusstsein fr die
Dringlichkeitzu schaffen und ein mit Befugnissen ausgestattetes
Team zusam-menstellen, das eine Vision entwickelt, die bildhaft
erklrt, wieman in Zukunft arbeiten mchte (Phase1). Diese
Vorstellungsollte gegebenenfalls wiederholt erzhlt, erlutert und
ver-breitet werden, um so die Kollegen zu mobilisieren
(Phase2).
Es liegt auf der Hand, einen Unternehmenswandel zu
agilerEntwicklung ebenso in agiler Weise iterativ durchzufhren.Das
Prinzip heit Inspect and Adapt. Feedback-Kreislufeersparen den
Zwang zur Perfektion zu Beginn. Sind die Mit-arbeiter ausreichend
in die Vernderung eingebunden, entstehenProzesse, die jeder
annehmen und akzeptieren kann; die Dis-krepanz zwischen gelebtem
und dokumentiertem Prozess ist
Phase Schritt Beispiele einer agilen Operationalisierung Se
nsib
ilisie
rung
Gefhl fr die Dringlichkeit erzeugen Problembewusstsein durch
Retrospektive schaffen Welche Probleme existieren derzeit? Welche
davon knnen mit Scrum gelst werden?
Fhrungskoalition aufbauen Gruppe mit ausreichend Kompetenz soll
den Wandel gestalten
Enterprise Transition Team (unterschiedlicher Hierarchieebenen)
einsetzen
Vision und Strategie entwickeln Vision: Frage klren: Was
bedeutet es fr das Unternehmen, agil zu arbeiten?Strategie:
systematische Einfhrung Agilitt agil einfhren, alternative
Karrierepfade thematisieren agile Transition untersttzen
Mob
ilisie
rung
Vision des Wandels kommunizieren Empfehlung: die Kommunikation
top-down regelmig wiederholen und vor allem die Intention
erluternber den aktuellen Stand des Change-Projektes berichten
Mitarbeiter auf breiter Basis befhigen Handeln im Sinne der
neuen Vision und der Ziele ermglichen
Enterprise Transition Team bernimmt Steuerung des
Change-Projektes
Scrum schulen Scrum-Rollen ausbilden, durch Coach untersttzen
und zum
Leben erwecken
Umse
tzun
g
schnelle Erfolge erzielen Pilotprojekte und Quick-Wins
identifizieren
Erfolge konsolidieren und weitere Vernderungen einleiten Split
and Seed: erfahrene Mitarbeiter aus den anfnglichen Pilotprojekten
auf neue Scrum-Projekte verteilen
neue Anstze in der Kultur verankern ber Ziele und Fortschritte
regelmig berichten Communities of Practice etablieren agile
Transformation weiterhin begleiten Scrum-Master-Rolle im Alltag
etablieren
Change-Prozess nach Kotter
iX Kompakt 2015 Agiles IT-Projektmanagement 19
-
gering. Eine iterative Herangehensweise an die Umsetzungs-phase
ermglicht das Lernen aus frhen Erfolgen und frhemScheitern. Es
zeigt sich dabei regelmig, wie weit man aufdem Weg zur Vision
vorangekommen ist, und festigt so die Ver-nderungsprozesse.
Es soll an dieser Stelle nicht unerwhnt bleiben, dass auchdas
Gegenteil gelingen kann statt iterativer Vernderung
eineBig-Bang-Einfhrung. Die gute Absicht hier ist: Wir sind
vonAgilitt berzeugt, geben Orientierung und Klarheit und gehenalle
gemeinsam. Wenn es schief luft, funktioniert durch dieschiere
Anzahl an gleichzeitigen Vernderungen zu viel nichtmehr und die
Akzeptanz fr die Transformation sinkt. Es ist je-doch mglich und in
der Praxis belegt , dass die gute Absichttrgt und sich Scrum
erfolgreich in einem groen Sprung ein-fhren lsst. Es erscheint zwar
kontra-intuitiv, kann aber den-noch glcken [2].
Allerdings sind manche Unternehmen davon berzeugt, dassScrum
auch nur ein Werkzeug ist. Sie bernehmen daher ledig-lich einige
Praktiken aus der Vorgehensweise, ohne sich tatsch-lich an ihren
Werten und Prinzipien auszurichten. Dabei entstehtetwas, das man
Verwaltungs-Scrum nennen knnte. Die Aufga-be des Scrum Master
besteht in diesem Umfeld allein darin,rechtzeitig zu den Meetings
einzuladen und zu prfen, ob allepnktlich erscheinen. Er tut weder
etwas fr die Teambildung,noch wirkt er als Change Agent in die
Organisation hinein.
Darber hinaus gibt es weitere Ursachen fr ein Scheitern
derAgilittseinfhrung. Beispielsweise werden Berater in ein
Un-ternehmen gerufen, um den gelebten Scrum-Prozess zu pr-fen. Die
Symptome beschreibt das Team gelegentlich mit Stzenwie: Weder sind
wir mit unserer Performance zufrieden, nochlsst sich der viel
zitierte Teamspirit so richtig spren. Aus ir-gendeinem Grund
scheint der Prozess ins Stocken geraten zusein. Die Ursache liegt
hufig nicht in einem fehlenden Change-Projekt, sondern in dem
Gedanken Wir passen Scrum an unserUnternehmen an und knnen dennoch
die eingangs erwhntenZiele erreichen sowie unsere Vision in die
Realitt umsetzen.Doch das ist in der Regel nicht erfolgreich. Zwar
kann man Din-ge verndern, nur sollte man vorher genau verstanden
haben,welche Auswirkungen solche Aktionen haben knnen.
Angst vor Vernderungen lhmt vieles
Eine andere Ausprgung von Wir passen Scrum an steckt hin-ter der
guten Absicht, dass man organisatorisch zunchst so wenig wie mglich
verndern mchte, um die Akzeptanz zu fr-dern. Eine solche
Einstellung will nicht zum Aufbruch motivie-
ren, sondern die Angst vor Vernderungen eindmmen. Darausentsteht
im Alltag beispielsweise ein Unternehmen mit (wei -terhin)
funktionsorientierten Abteilungen (Requirements-Engi -neering,
Entwicklung, Qualittssicherung), mit einem Scrum-Team je Abteilung,
die vielleicht auch noch in verschiedenenGebuden sitzen
(Abbildung).
Kein Wunder, dass sich der Teamgeist im Keller versteckt.Dabei
liegt die Lsung nahe: Man kann Scrum-Teams abtei-lungsbergreifend
besetzen und in einem Flur, benachbarten B-ros oder sogar einem
Raum unterbringen. Darber hinaus sollteman darauf hinarbeiten, den
Spezialisierungsgrad der Teammit-glieder aufzuweichen, um so mehr
Flexibilitt und echte Zusam-menarbeit zu bekommen. Eine weitere
Variante der genanntenguten Absicht, organisatorisch so wenig wie
mglich zu bewe-gen, knnte den Namen Das Beste aus beiden Welten
bekom-men. Hier wird Scrum neben den vorhandenen Rollen und Re-geln
eingefhrt die Scrum-Rollen und -Regeln gelten einfachzustzlich. Die
betroffenen Mitarbeiter werden mit der Aufl-sung von
Rollenkonflikten etwa Projektleiter und Scrum Mas-ter in
Personalunion allein gelassen. Es ist jedoch nicht gut,l und Wasser
zu mischen. Mit anderen Worten: Nur auf sehrgrober Ebene lassen
sich agile Projekte in ein nicht agiles Um-feld einbetten.
Wenn alle Fragen des Warum, Was und Wie zum Ein-fhren von
Agilitt geklrt sind, bleibt immer noch die Heraus-forderung, die
neue Arbeitsweise dauerhaft im Alltag zu veran-kern und nicht
wieder in alte Gewohnheiten zurckzufallen. Beidiesem Thema der
Nachhaltigkeit kommt dem Scrum Mas-ter besondere Bedeutung zu.
Voraussetzung fr das Etablierender Neuerungen im Unternehmen ist,
dass die Betroffenen allerHierarchieebenen so am
Vernderungsprozesses teilhaben, dasssie die Mglichkeit bekommen,
ihre Angewohnheiten und Ar-beitsweisen nachhaltig zu ndern. Sie
mssen also mitgestaltenknnen und dies iterativ. Die regelmige
Reflektion im Teamber die eigenen Arbeitsweisen gehrt zu den
Kernaufgaben ei-nes Scrum Master. Seine Rolle sollte im
Arbeitsalltag verankertsein und gezielt die Nachhaltigkeit der
neuen Arbeitsweise fr-dern. Scrum Master wie der eingangs
geschilderte KollegeFlorian bentigen somit nicht nur Kenntnisse ber
Rollen,Meetings und Artefakte, sondern vor allem eine Ausbildung,
diesie befhigt, die Teambildung voranzubringen und Change Agentim
Unternehmen zu sein. Das erfolgreiche Einfhren von Scrumerfordert
den Mut, nicht nur ausgewhlte Praktiken zu verwen-den, sondern sich
an den entsprechenden Werten und Prinzipienim Alltag zu
orientieren. (jd)
Literatur[1]John Paul Kotter; Leading Change; Harvard
Business
School Press, 1996[2]Michael Hofmann, Meino von Spreckelsen;
Einfhrung von
Scrum im Groen ein Praxisbericht; 30. Internationales
Projektmanagement Forum, Nrnberg, 2013
Dr. Michael Hofmann ist Arbeits- und Organisationspsychologe.
Als Trainer und Berater der oose Innovative Informatik eG fhrt er
Lean, Agile und Scrum in Unternehmen ein.
Andrea Grass arbeitet als Trainerin und Agile Coach bei der oose
Innovative Informatik eG. Sie fhrt Agilittsschecks durch und
untersttzt Teams dabei, Agilitt zum Leben zu erwecken.
20 iX Kompakt 2015 Agiles IT-Projektmanagement
PROJEKTE & QUALITT | FIRMENKULTUR
Es ist ein Irrtum, zu glauben, dass Abteilungs-Scrum
funktioniert.Echte Vernderungen in Richtung agiles Unternehmen sind
soausgeschlossen.
-
W as treibt jemanden dazu, einen Artikel ber Plne zuschreiben?
Mir persnlich gengt dafr die Beschfti-gung mit dem in Abbildung1
dargestellten Gantt-Dia-gramm. Es wurde angefertigt, um die
zeitliche Abfolge von Ak-tivitten zum Umstellen eines bestehenden
IT-Systems auf SAPdarzustellen. Den Plan mit seinen rund 3000
Zeilen zu erstellen,erforderte einen gewaltigen Aufwand. Dumm nur,
dass sich dasGanze schon nach wenigen Wochen als hinfllig erwies.
Ja, dieArbeit von ber 100 Bearbeitungstagen war umsonst und
dasobwohl die Planung den Segen des Program Board und der
Ge-schftsleitung hatte. Denn nach kurzer Zeit stellte sich zur
all-gemeinen berraschung heraus, dass die zweiwchigen Krank-heiten
zweier Schlsselressourcen immense, nicht-lineare
Auswirkungen auf die Abhngigkeiten in der Projekt- und
Res-sourcenplanung hatten. Die Folge: Die vorgesehene Laufzeitvon
eineinhalb Jahren verlngerte sich um mehr als ein Jahr. Somacht
Planung keinen Spa und bringt auch nichts fr den Er-folg des
avisierten Produkts.
Voraussagen sind unmglich
Leider ist bei anspruchsvollen Projekten eine sorgfltige
Pla-nung unverzichtbar. Wie sonst sollte man wissen, was man
wannund wie zu tun hat und was man dafr braucht? Ein Plan ist
eineEntscheidungsgrundlage, und die entscheidenden Fragen, die
er
22 iX Kompakt 2015 Agiles IT-Projektmanagement
PROJEKTE & QUALITT | PLANUNGSMETHODEN
Genauere Schtzungen durch Komplexittsreduzierung
In Einklang bringenFrank Dsterbeck
Beim Planen von Produkten, Releases und Ressourcen liegen die
Beteiligten mit ihren
Schtzungen immer wieder weit daneben. Knnen agileVerfahren die
Situation verbessern? Sind sie tatschlich schneller und genauer als
klassische? Und wo bleibt eigentlich mein Gantt?
-
beantworten soll, lauten: Was fr ein Produkt will ich
entwi-ckeln? In welchem zeitlichen Ablauf mchte ich dies tun?
Wasbrauche ich dafr? Typischerweise beantworten drei
unter-schiedliche Plne Produkt-, Release- und Ressourcenplan diese
drei Fragen.
Da Softwareentwicklung komplex ist, bewegen sich die
Ver-antwortlichen auf dnnem Eis, wenn sie zu Beginn eines Pro-jekts
konkrete Aussagen ber die bentigte Zeit, die bentigtenRessourcen
und die voraussichtlichen Kosten treffen. Schlie-lich lehrt die
Komplexittstheorie, dass man sich in komplexenSystemen auf
Voraussagen fr die Zukunft nicht verlassen kann.Dies gilt umso
mehr, je komplexer ein System ist. Unglckli-cherweise existieren
gerade in der Softwareentwicklung beson-ders viele
Komplexittstreiber. Hierzu gehren: sich ndernde Anforderungen
Echtzeit Chancen und Risiken Interessen der Stakeholder/politische
Interessen neue Prozesse und Methoden neue Techniken alter Code
Anwendbarkeit des Gelernten Organisationsstrukturen Infrastruktur
die TeammitgliederAllein diese Aufzhlung zeigt, dass Plne nicht
alle Unwg-barkeiten im Projektverlauf abdecken knnen. Da
komplexeSysteme zudem grundstzlich nicht linear sind, ist es
sinnlos,sie vollstndig in ein sequentielles Gantt-Diagramm zu
ber-fhren.
Simplifizierung ist der Schlssel
Es gibt jedoch einen Weg, mit dem Menschen komplexe Sys-teme in
den Griff bekommen und besser verstehen knnen:Simplifizierung. Denn
je besser es gelingt, Komplexitt zu re-duzieren und ihr dennoch
weitgehend gerecht zu werden, destobesser lsst sich planen. Ganz
falsch wre es, auf komplexeSachverhalte mit komplexen Methoden zu
reagieren. Denn da-durch erhht sich die Komplexitt noch weiter.
Leider ist ihreReduktion immer mit einem Informationsverlust
verbunden. Es
gilt also, bei der Planung die Waage zwischen Verminderungund
Verlust zu finden.
Ausgangspunkt der Produktplanung ist die Vision bezie-hungsweise
das Produkt, mit dem man sie erreichen will. DerProduktplan zeigt,
wie die Vision umgesetzt werden soll. bli-cherweise definiert man
ein Projekt, in dessen Rahmen das Pro-dukt entsteht. Ziel des
Projekts ist immer, Wert zu schaffen und dies mglichst schnell,
flexibel, hochwertig und gnstig.Hierbei gilt jedoch: Wer versucht,
die Planung 1:1 umzusetzen,drfte bald feststellen, dass er den
Erfolg des Produkts (auf denes letzten Endes ja ankommt) so nicht
erreicht. Denn im Rah-men eines Projekts funken immer wieder die
oben genanntenKomplexittstreiber dazwischen.
Ein Projekt kann nur derjenige erfolgreich umsetzen, der
im-stande ist, jederzeit flexibel auf Vernderungen zu
reagieren.Einfach nur stur den einmal aufgestellten Plan zu
verfolgen,fhrt jedenfalls gewiss nicht zum gewnschten Ziel und
kannsogar kontraproduktiv sein.
Die ntige Flexibilitt liefert ein Product Backlog, in demsich
der Produktplan manifestiert (Abbildung2). Sein Vorzugbesteht
darin, dass er eine eindeutige Reihenfolge vorgibt, in derdie darin
enthaltenen Product Backlog Items (PBIs, typischer-weise User
Stories und Epics) abzuarbeiten sind, wobei die ers-
iX Kompakt 2015 Agiles IT-Projektmanagement 23
Gantt-Diagramm: Die Realitt lsst
sich in einem solchen Diagramm
nicht darstellen(Abb.1).
Im Product Backlog manifestiert sich der Produktplan mit
einerklaren Reihenfolge der Aktivitten (Abb.2).
-
ten User Stories mglichst frh einen hohen Wert schaffen
soll-ten. Nur sie werden deshalb schon am Anfang so detailliert
undkonkret ausgearbeitet, dass sie sich umsetzen lassen (Status
oderDefinition of Ready). Stories, die weiter hinten im
ProductBacklog stehen, mssen erst dann in ihren Einzelheiten
ausge-arbeitet sein, wenn sie an der Reihe sind.
Diese Vorgehensweise verringert die Komplexitt und ver-schafft
einen immensen Vorteil gegenber dem Arbeiten mitherkmmlichen
Lasten- oder Pflichtenheften, die viele Anfor-derungen stark
ausdifferenzieren, obwohl sie spter keinen
oder nur noch einen sehr geringen Wert haben (die
typischeGoldkante).
Die grte Herausforderung beim Anfertigen eines ProductBacklogs
besteht darin, die optimale Reihenfolge und den rich-tigen Schnitt
(also die Aufteilung) der Stories festzulegen.Hierbei spielen
Elefanten eine wichtige Rolle doch dazu sp-ter mehr.
Auf der Product Roadmap zum Ziel
Der Releaseplan beantwortet die Frage: Wann kriege ich
was?Hierfr sollte das Projektteam eine Product Roadmap
anfertigen,die angibt, auf welche Weise es die Vision verwirklicht
will. Siedient als Fahrplan und beinhaltet unterschiedliche
Releases, diesich jeweils einem bestimmten Ziel (Thema) widmen, das
esdann in einem oder in mehreren Sprints zu erreichen gilt.
Ob nach jedem Sprint eine Auslieferung stattfindet odernicht, ob
es auch innerhalb von Sprints Auslieferungen gibt,oder ob berhaupt
Releases bentigt werden, all das ist abhn-gig vom Kontext. Oft wird
ein Release dazu verwendet, eineKlammer um weitere Ttigkeiten wie
Migrationen, Schulun-gen und Change Management zu bilden.
Grundvoraussetzungder Releaseplanung ist es, die einzelnen PBIs zu
schtzen. Wiebei jeder Schtzung gibt es dabei zwangslufig
Unsicherheiten.Der in Abbildung3 dargestellte Kegel der
Unsicherheit desamerikanischen Softwareingenieurs Barry Boehm
beschreibt,dass zu Anfang eines Projekts die Schtzunsicherheit hoch
ist(Faktor4). Im Laufe der Zeit wird die Schtzung zwar genau-er,
erreicht aber niemals Faktor1. Erst am Ende eines Projektswei man,
welche Schtzung richtig war (und das auch nichtin allen Fllen).
Oft kommt der Auftragnehmer in die Verlegenheit, dem Kun-den
schon vor Beginn eines Projekts eine ungefhre Schtzungdes
voraussichtlichen Aufwandes geben zu mssen. Rechneteder
Auftragnehmer zum Beispiel ber den Daumen mit einemZeitaufwand von
60 Tagen, wre es nicht unbedingt ratsam, demKunden diese Schtzung
mitzuteilen, denn vermutlich lsst sichnur schwerlich ausschlieen,
dass das Projekt auch 120 oder 240Tage dauern kann oder auch nur
15. Da kein Kunde eine sounkonkrete Zeitangabe wie 15 bis 240 Tage
akzeptiert, musseine konkretere Schtzung her.
Besser ungefhr richtig als genau falsch
Man knnte darauf verfallen, nun doch ein vermeintlich
exaktesLastenheft zu schreiben. Doch auch dann gbe es weiterhin
gro-e Schtzungenauigkeiten (zumal keine Umsetzungserfahrun-gen
vorliegen). Und selbst mit erheblich gesteigertem Aufwanderreiche
die Schtzgenauigkeit niemals 100 Prozent. An dieserStelle sei auf
einen bewhrten Tipp von Johann Wolfgang vonGoethe verwiesen:
Entscheide lieber ungefhr richtig, als ge-nau falsch.
Ein weiterer unerfreulicher Aspekt: Menschen sind nichtwirklich
gut darin, komplexe Sachverhalte zu schtzen. Zwarknnen sie relativ
gut Relationen bilden und erkennen bei-spielsweise leicht, welches
Mnnchen in Abbildung4 grerist als die anderen. Doch insbesondere
groe Mengen knnensie nur sehr schlecht richtig einordnen. In der
Softwareentwick-lung kommt hinzu, dass Entwickler dazu tendieren,
nur das rei-ne Kodieren (also das ideale Netto) zu schtzen
(Abbildung5).
Das reale Brutto, also die eigentliche Arbeit, wird dagegenkaum
betrachtet. Dies fhrt zu hohen Abweichungen, die man
24 iX Kompakt 2015 Agiles IT-Projektmanagement
PROJEKTE & QUALITT | PLANUNGSMETHODEN
Kegel der Unsicherheit: Im Laufe der Zeit wird die Schtzungzwar
genauer, erreicht aber niemals Faktor1 (Abb.3).
Relatives Schtzen:Die kleineren Figu-ren zu erkennen, ist kein
Problem,schwierig wird esbei groen Mengen(Abb.4).
reales Brutto
ideales Netto
Waste/private
Dinge tunabstimmen,besprechen
fortbilden
Entwerfen Codieren
Dokumentieren
Testen
Reviewen
Refaktorieren
Organisieren
Ideales Netto vs. reales Brutto: Entwickler neigen dazu, das
Ko-dieren in den Vordergrund zu rcken, bersehen aber gern denRest
(Abb.5).
-
blicherweise mit Puffern korrigiert. Doch wie kann ein
Pro-jektteam den Schtzherausforderungen und -komplexitten ge-recht
werden?
Ein einfacher Ausweg aus dem Dilemma sind Story Points.Die
Planer schtzen nicht, wie schnell sie eine Strecke laufen,sondern
die Lnge der Strecke. Auf die Softwareentwicklungprojiziert heit
das: Sie schtzen die Struktur dessen, was sieumsetzen mssen. Dabei
kommen sowohl der zeitliche Aspektals auch die Komplexitt und die
Unsicherheit bei der Planungeiner Story zum Tragen (was sich etwa
ber eine abgewandelteFibonacci-Reihe erreichen lsst). So wird man
sowohl der Kom-plexitt als auch den Problemen der Schtzung
gerecht.
Auerdem ist es mit einfachen Schtzverfahren mglich,ein Product
Backlog schnell und effizient vergleichend zuschtzen, zum Beispiel
ber das Team Estimation Game (siehedazu den Artikel Spielerisch
arbeiten auf Seite 112). Hierbeischlgt die bereits erwhnte
Eigenschaft der Menschen durch,dass sie gut Relationen bilden
knnen. Auch das reduziertKomple xitt.
Ist das Product Backlog entsprechend bewertet, muss dasTeam fr
die zeitliche Abbildung wissen, wie viele Story Pointses pro Sprint
abarbeiten kann (die sogenannte Velocity). Sie ba-siert auf den
tatschlich geleisteten Werten (empirisches Ma-nagement) und lsst
sich zum Vermeiden grerer Schwankun-gen auf die Anwesenheit der
Mitarbeiter beziehen. Weiterhinmuss das Projektteam die maximalen
und minimalen Werte derVelocity betrachten (extreme Minima und
Maxima herausrech-nen), um mit ihnen in die Releaseplanung zu gehen
(Abbil-dung6).
Agil schtzt es sich besser
Gibt es einen fixen Termin fr das Re-lease, so lsst sich mit
hoher Validitt sa-gen, welche Stories bis dahin abgearbei-tet
werden knnen, welche nur vielleichtund welche auf keinen Fall. Ist
der Funk-tionsumfang fix, so lsst sich anhand derermittelten
minimalen und maximalenVelocity leicht bestimmen, bis wann sichder
Auftrag erfllen lsst. Im Zweifelempfiehlt sich ein fixer
Release-Termin,
nicht zuletzt, weil es Vertrauen schafft, wenn das Produkt
oderwenigstens dessen Essenz bis dahin auch tatschlich
geliefertwird (was dank guter Priorisierung im Backlog gelingt). Fr
einTeam, dessen Velocity noch nicht bekannt ist, muss man aus
derErfahrung heraus am Anfang eines Projekts eine Annahme tref-fen,
die es dann schnellstmglich zu besttigen und gegebenen-falls zu
korrigieren gilt. ber die Genauigkeit einer Preisindika-tion gibt
der Vergleich zwischen diesem agilen und einemklassischen Vorgehen
in Abbildung7 Auskunft.
Schnell auf Probleme reagieren
Das agile Angebot ist mit Sicherheit wesentlich genauer als
daszum gleichen Zeitpunkt abgegebene klassische, da die
Betei-ligten bis dahin schon Erfahrungen beim Umsetzen
gesammelthaben. Somit knnen sie gute Zukunftsprognosen treffen.
Einweiterer Vorteil der agilen Vorgehensweise ist, dass die
Umset-zung zeitig beginnt. Das bedeutet zwar auch, dass schon
frhmehr Geld in das Entwicklungsteam flieen muss, doch zu-gleich
zeichnen sich etwaige Fehlschlge viel schneller ab, undman kann
schnell auf Probleme reagieren. Bei ungnstigemVerlauf lsst sich ein
Projekt also wesentlich frher stoppen.Um mit den Unsicherheiten der
Releaseplanung besser umge-hen zu knnen, sollten sich die
Beteiligten klarmachen, dassman einen Elefanten nicht in Scheiben
schneiden darf. Was dasbedeutet? Ein Elefant ist stark und kann
eine ganze Menge Eigenschaften, die auch fr das Produkt gelten
sollten. Mit einpaar Scheiben kann man nichts anfangen, und seien
sie noch
iX Kompakt 2015 Agiles IT-Projektmanagement 25
Releaseplanung: Das Team muss wissen,
wie viele Story Points es pro Sprint abarbeiten
kann (Abb.6).
klassisch
agil
Lastenheft
Pflichtenheft
ProductBacklog
CR CR
Umsetzung Umsetzung
Preisindikation
Preisindikation
Angebot
Umsetzung
Das agile Angebot ist wesentlich genauer als das zum gleichen
Zeitpunkt abgegebeneklassische (Abb.7).
-
so gro. Im Zweifel werden sie auch noch falsch zusammen-gesetzt
(Abbildung8).
Salamitaktik fhrt zu nichts
Auf das Produkt bertragen hei das: Wenn der Auftragnehmeres
scheibchenweise verwirklicht, hat es erst ganz zum Schlusseinen
Wert. Besser wre es jedoch zweifellos, mglichst schnelleinen Wert
zu schaffen. Die richtige Vorgehensweise bestehtdemnach darin, den
Elefanten wie es die Natur vorgesehenhat langsam grozuziehen.
Zwar bedeutet das, dass der kleine Elefant noch nicht allesgut
kann und vielleicht ein paar Probleme bereitet, aber immer-hin lebt
er schon mal. Wer sein Produkt langsam zur vollen Rei-fe bringt,
wird der Komplexitt der Software gerecht und schafftfrhzeitig
Wert.
Um dies zu erreichen, bietet sich bei der Produkt- und
derReleaseplanung das Story Mapping an. Es besteht aus
folgendenRegeln und Schritten: Alle, die mit der Produktentwicklung
zu tun haben, machen
mit Nimm die Haupt-Benutzeraktivitten und Hauptgeschftspro-
zesse Trenne Aktivitten in entsprechende Schritte auf
(funktionale
Bereiche, Epics et cetera) Trenne jeden Schritt in kleinere
Stories auf Priorisiere jede Story nach Wert, Risiko, Nutzen,
Wichtigkeit Definiere und schtze ein Walking Skeleton, das Gerst
der
Anwendung, das alle kritischen Schichten und Techniken be-rhrt,
allerdings ohne viel Fleisch (im Sinne von Funktio-nen) drumrum
Definiere und schtze das Minimal Viable Product (MVP,
dasminimale Set an Funktionen)
Vergiss nie die Vision beziehungsweise das Big PictureHinter dem
Ressourcenplan steckt hufig die Frage: Was solldas Ganze kosten?
Was die Entwicklungsttigkeiten angeht, istdie Antwort darauf
einfach: Die Kosten pro Story Point ergebensich aus den Kosten pro
Sprint geteilt durch die Velocity. DieKosten pro Sprint wiederum
ergeben sich je nach Kontext. Istein externer Dienstleister
involviert, muss man der Rechnunglediglich dessen Kosten pro Stunde
zugrunde legen.
Verzgerungen mit einplanen
Typischerweise hat ein Auftraggeber allerdings nur ein
begrenz-tes Budget. In der klassischen Welt geht ein kluger
Auftraggeberoder Projektverantwortlicher davon aus, dass das
Projektbudgetnicht ausreicht, und plant Mehrkosten von 10 bis 15
Prozent so-wie etwaige Zeitverzgerungen mit ein. Nach dem Projekt
wird
selbstverstndlich ein Wartungsbudget definiert. Es ist aber
nichtim Projektbudget enthalten und im schlimmsten Fall muss esein
anderer Bereich bezahlen.
blicherweise erweisen sich bei Projekten sowohl die
Zeit-vorgaben als auch die geplanten Kosten als zu knapp
kalkuliert.So entsteht vor allem beim klassischen Vorgehen nach
demWasserfallprinzip am Projektende ein starker zeitlicher
Druck,dem dann vielleicht sogar einige Tests zum Opfer fallen.
Zeitlicher Druck ist eine beliebte Ursache fr eine
groetechnische Schuld (schnell mal fertig machen). All das
ziehtunweigerlich Qualittsmngel nach sich und erzeugt ein
starkberhhtes Wartungsbudget. Mit Festpreis und der Gewhrleis-tung
des Dienstleisters ist es im besten Fall nur rgerlich fr
denEndkunden. Meistens aber fhrt es zu erheblichen Mehrkostenbei
Folgeprojekten, entweder weil sich der Dienstleister die
Ge-whrleistungskosten wieder zurckholt oder weil die
technischeSchuld so gro ist, dass sie aufwendige Refaktorierungen
erfor-dert. Ein Mittel, diesen Problemen entgegenzuwirken, ist ein
ite-rativ-inkrementelles Vorgehen.
Auch hier muss man davon ausgehen, dass das Projekt so-wohl den
zeitlichen als auch den Kostenrahmen reit. Trotzdemsind dabei doch
bestimmte Funktionen korrekt umgesetzt wor-den und erzeugen Wert
(vorausgesetzt, der Elefant wurde gro-gezogen und nicht
geschnitten). Das bedeutet: Die Funktionen,die das Team am Ende der
Projektlaufzeit noch umsetzen muss,sind im Zweifel kaum noch
relevant und knnen womglich so-gar wegfallen.
In jedem Fall verbessert das iterativ-inkrementelle Vorgehendie
Qualitt des Produkts. Testphasen entfallen nicht, und dietechnische
Schuld ist kleiner. Das Wartungsbudget drfte des-halb deutlich
geringer ausfallen als beim klassischen Wasser-fallverfahren.
Der Wert treibt, nicht der Plan. Ein Team muss versuchen,
derKomplexitt der Softwareentwicklung sowie den Schwierigkei-ten
insbesondere von Schtzungen mit geeigneten Manahmenzu begegnen.
Erreichen lsst sich das durch das Kombinierenetablierter agiler
Praktiken und Methoden sowie einer inkremen-tellen, iterativen
Vorgehensweise. Das bedeutet auch, dass manEntscheidungen auf Basis
des Bekannten trifft und nicht aufGrundlage des Unbekannten. Dabei
braucht man kein Gantt-Chart. Dieses berbleibsel aus der
Industrialisierung suggerierteine Planungssicherheit, die es in der
Softwareentwicklung nichtgibt. Besser ist es, den Ausspruch von
Bertold Brecht zu berck-sichtigen: Wer A sagt, der muss nicht B
sagen, er kann auch er-kennen, dass A falsch war. (jd)
Frank Dsterbeckarbeitet bei der HEC GmbH als Berater und Trainer
fr Organisationsentwicklung, Projekt-, Test- und Anforderungs
manage -ment mit Fokus auf agilen Methoden (Twitter:
@fduesterbeck).
26 iX Kompakt 2015 Agiles IT-Projektmanagement
PROJEKTE & QUALITT | PLANUNGSMETHODEN
Egal, wie gro die Scheiben ausfallen; der Kunde kann damit
nichts anfangen (Abb.8).
-
Agile Softwareentwicklung ist im Mainstream angekom-men. Und
genau hier lauern die Gefahren. Die ursprng-lichen agilen Ideen
werden hufig nicht ausreichend ver-mittelt. Oder die Leute
ignorieren die Grundstze und schnappensich stattdessen die erste
Methode, die ihnen ber den Weg luft,nur um sich den Orden agil an
die Brust heften zu drfen. Oh-ne adquates Zuschneiden. Ohne
berlegung, ob und was bes-ser und passender wre. Ohne Respekt vor
Grautnen, einfachnur von Schwarz ins vermeintliche Wei.
Wir haben in diversen Projekten und Teams festgestellt,
dassviele Menschen hufig nicht genau verstehen, was die
agileSoftwareentwicklung denn ausmacht, und zwar im Kern,
nettosozusagen. Dafr haben sie aber beispielsweise den Scrum-Flohim
Ohr sitzen. Sie wissen nicht, nach welchen Prinzipien managil
denken muss, um so Software entwickeln zu knnen. Siefrchten sich
vor Pair Programming, weil sie es fr Ressourcen-verschwendung
halten.
Es hat sich zu viel oberflchliches, gefhrliches
Halbwissenangesammelt, weil sich viele nicht einmal die Mhe
machen,bei Wikipedia unter Agile Softwareentwicklung
nachzuschla-gen, sondern gleich das Scrum-Brecheisen auspacken. So
stellensie ihr ganzes Unternehmen auf den Kopf, ohne zu ahnen,
dasssie mit Scrum ein Managementkonzept und keineswegs per seagile
Softwareentwicklung einfhren. Kurzum: Fr viele scheintdie agile
Softwareentwicklung in ihrer reinen, methodenunab-hngigen Form im
Spannungsfeld zwischen Marketing-Hypeund Halbwissen ein Buch mit
sieben Siegeln zu sein.
Unsere oberste Prioritt ist es, den Kunden durch die frheund
kontinuierliche Auslieferung ntzlicher Software
zufrieden-zustellen.
Das Umsetzen dieses Prinzips aus dem agilen Manifest wirktsich
direkt auf die Kundenzufriedenheit aus, und die ist schlie-lich
entscheidend fr den Erfolg der Mission. FunktionierendeSoftware ist
in diesem Kontext die Software, die fr den Kun-den einen Mehrwert
bringt, also im Vergleich zum vorherigenStand eine Verbesserung
darstellt. An dieser Aufgabe werdenSie und Ihr Team gemessen.
Der Kunde muss immer profitieren
Erhhen Sie mit jeder Auslieferung Nutzen und Wert der Soft-ware
fr den Kunden. Prferieren Sie Inkremente gegenbermehrwertlosen
Iterationen. Bauen Sie nicht auf Halde oder aufVerdacht, lassen Sie
keine berdimensionierung zu. VerwerfenSie rigoros alles, was nicht
hier und jetzt erforderlich ist oderzumindest als Vorbereitung fr
die nchsten Schritte dient be-ziehungsweise zur Basisarchitektur
der Lsung gehrt.
Ein Beispiel: