eDOSSIER

02.2014
shop.page-online.de/
downloads

Projektmanagement
in der Kreativbranche
Kreation, Budget, Timing und
Technik stets im Griff

Agiles Projektmanagement: So finden Sie

die richtige Methode für Ihr Projekt

Fallbeispiel: Scrum bei XING

Das PAGE eDossier 02.2014 enthält Beiträge aus PAGE 11.2011 (Oktober 2011), WEAVE 05.2013 (September 2013),
WEAVE 05.2009 (September 2009) im Originallayout.
IMPRESSUM Redaktion PAGE, Borselstraße 28, 22765 Hamburg; info@page-online.de; Telefon: 040 85183-400, Fax: -449; www.page-online.de; Chefredakteurin/Publisher: Gabriele Günder, V.i.S.d.P. Autoren:
Antje Dohmann (ant), Stefan Freimark, Ilona Koglin (ik), Wiebke Lang (wl); Freie Mitarbeit: Christine Krawinkel, Rebecca von Hoff (Grafik); Anzeigenleiter: Alexander Herz; alexander.herz@page-online.de; Telefon:
+49 85183-480, Fax: -489 (verantwortlich für die Anzeigen und Promotion); PAGE erscheint in der Ebner Verlag GmbH & Co. KG, Karlstraße 3, 89073 Ulm; Geschäftsführer: Gerrit Klein, Martin Metzger (Stellver-
treter), Florian Ebner Urheberrecht: Alle Beiträge sind ur­he­berrechtlich geschützt. Alle Rechte, auch Übersetzun­gen und Zweitverwertungen, vorbehalten. Reproduk­tionen, gleich welcher Art, ob Fotokopie,
­Mikrofilm oder Er­fas­sung in Datenverarbeitungsanlagen, nur mit schrift­­li­cher Genehmigung des Verlages. Eine Vermietung, Verleihung sowie Verkauf oder eine sonstige Form der Zugänglichmachung an Dritte ist
Ihnen nicht gestattet. Aus der Veröffentlichung kann nicht geschlossen werden, dass die beschriebe­nen Lösungen frei von gewerblichen Schutzrechten sind. Für den Fall, dass hier unzutreffende Informationen
enthalten sein sollten, kommt eine Haftung nur bei grober Fahrlässigkeit des Verlages oder seiner Mitarbeiter in Betracht. Weitere eDossiers, Einzelhefte und Aboangebote gibt’s unter shop.page-online.de
004 PAGE eDossier 02.14 (Beitrag aus PAGE 11.2011)
Analoge und digitale Tools helfen Projekt-
managern den Überblick über alle Prozesse zu
behalten – hier die Planungswand der
Agentur Syzygy und rechts die Software Solo
Klare Linien
Projektmanagement ist eine Investition in den Projekterfolg. Und den
wollen schließlich alle Beteiligten – vom Kreativen bis zum Kunden
n Sie heißen Projekt-, Account oder
Service Client Manager, Kontakter, Be­
ra­ter oder auch mal Producer. Ihr Job
ist dennoch fast der Gleiche: Sie halten
die Fäden in der Hand, koordinieren al­le
an einem Projekt Beteiligten, sorgen so
für einen möglichst reibungslosen Ab-
lauf und sehen zu, dass die Erwartun­
gen aller Stakeholder erfüllt werden.
Geht etwas schief, sind es meistens sie,

die dafür geradestehen müssen. Keine
leichte Aufgabe, die durch die immer
komplexeren Design- und Kom­mu­ni­
ka­tionsprojekte noch anspruchsvoller
wird. „Vor allem bei Multichannel-Kam-
pagnen müssen wir als Digital­agen­tur
neben den eigenen Aufgaben, etwa
der Entwicklung der Website, auch den
Überblick über das Gesamtprojekt ha-
ben, um sicherzustellen, dass die Maß­
PAGE eDossier 02.14 005
Zeitplanung
Budgetplanung
Qualitätsmanagement
Teamkommunikation
nahmen integriert konzipiert und Sy- Kundenkommunikation
nergien sinnvoll genutzt werden“, er-
klärt Sabrina Lück. Die Online-Marke-
ting-Fachwirtin war zweieinhalb Jahre
Projektmanagerin bei der Interactive-
Agentur Syzygy in Bad Homburg und
arbeitet nun in dieser Position bei der
Syzygy-Tochter Hi-ReS! in Hamburg.
„Zum Glück hat sowohl bei Agen­-
tu­ren als auch bei den Kunden ein
Reporting
006 PAGE eDossier 02.14 (Beitrag aus PAGE 11.2011)
In der ersten Phase der „Jägermeister Legenden“-Aktion konnten Interessierte für 10,99 Euro am Tag einen Oldtimer mieten
Lern­effekt eingesetzt. Die Agentu­
ren fra­gen nicht mehr als Erstes, wer
im Lead ist und wem sie sich unterord-
nen müs­sen. Vielmehr tragen sie aus
ihrem Bereich das Bestmögliche bei,
um das Pro­­jekt zum Fliegen zu bringen.
Beim Kun­den lassen sich die Abtei­
lungen untereinander mehr Spielraum
und binden deutlich frühzeitiger alle
Partner mit ein“, berichtet Sabrina Lück.
„Früher wurden Projekte eher abge-
wickelt. Heute müssen Kunden und
Teams exzellent geführt werden. Ande­
re führen, sich selbst führen und sich
führen lassen – das ist essenziell, um
Effizienz und Kundenzufriedenheit zu
steigern“, betont Daniel Karczinski, Ge­
schäftsführer bei Martin et Karczinski
in München. Außerdem seien Agentu­
ren heute sehr dynamische Gebilde,
die je nach Kundenstruktur ihre Orga-
nisationsstruktur wechseln müssten.
„Gerade bei der Umsetzung medien­
übergreifender Konzepte bilden wir
Unit-übergreifende Teams, die je nach
Aufgabe und Anforderung speziell zu-
sammengesetzt werden.“
Auch auf Kundenseite hat sich Eini­ges
getan. Bedingt durch das wirtschaft­
liche Auf und Ab der letzten Jahre
herrscht in den Marketingabteilungen
ein stärkerer Druck aus dem Control-
ling – Design- und Werbeaktivitäten
müssen auch intern gut verkauft wer-
den. Und dies gehört zunehmend zu
den Dienstleistungen der Agenturen,
die mit transparenten Kosten- und Leis­
tungsaufstellungen den Verantwortli­
chen beim Kunden argumentativ un-
terstützen. Auch das Brand Manage-
ment, also die Implementierung von
Design, wird aufgrund der technischen
und konzeptionellen Komplexität der
Lösungen von den Unternehmen oft
an die Agenturen delegiert.
Daniel Karczinski erkennt zudem
eine Tendenz weg von Einzelprojek­ten
hin zu kompetenz- und medienüber-
greifenden Konzepten. Dies erfordere
einen integrierten Kommunikationsan­
satz und eine enge Zusammenarbeit
zwi­schen Strategie und Design. „Auf
die­se Weise schaf­fen wir die Grundla-
gen dafür, dass Marken- und Unter­
neh­mens­auftritte übergreifend funkti­
onieren“, erklärt er. Dabei spielt – ganz
praktisch – auch das Großraumbüro
der Münchner Agentur eine wichtige
Rolle. Hier können sämtliche Units und
Mitarbeiter auf extrem kurzen Wegen
kommunizieren.
Persönlicher Kontakt nimmt gene-
rell sowohl bei der internen als auch
bei der Kundenkommunikation eine
zentrale Rolle ein. Während sich alltägli­
che Fragen selbstverständlich per Te­le­
fon oder E-Mail klären lassen, werden
selbst kleinere Entscheidungen in re-
gelmäßigen Meetings heute meist am
runden Tisch getroffen. Dass sich da-
für ganze Kreativ- ebenso wie Kunden­
teams Zeit nehmen, macht die stärke­re
Serviceorientierung auf Agenturseite
deutlich. Außerdem ist die intensive,
offene Kommunikation auf Augenhö-
he auch Ausdruck des wachsenden
Selbstbewusstseins der Branche – und
eines höheren Ansehens kreativer Ar-
beit in der Wirtschaft.
Was Projektmanagement konkret be­
deutet, erläutert Sabrina Lück am Bei-
spiel der zweistufigen „Jägermeister
Legenden“-Aktion. In der ersten Phase
konnten sich Interessierte bewerben,
einen von fünf Oldtimern für einen Tag
zum Preis von 10,99 Euro zu mieten. Die
Bewerbung, für die der Satz „Ich bin ein
echter Typ, weil . . .“ vollendet werden
musste, war über die Kampagnen-Web­
site oder eine Telefon-Hotline möglich.
In der aktuellen Phase (bis 6. Novem-
ber) kann man eines von zehn Autos
gewinnen. Für die Teilnahme an der
Ver­losung ist ein Aktionscode nötig, der
in den Jägermeister-Aktionspackun­gen
im Handel zu finden ist. Neben Syzygy
als Digitalagentur sind eine Event- und
eine PR-Agentur beteiligt, dazu „Bild“
sowie drei verschiedene Abteilungen
des Kunden, Mast-Jägermeister.
„Zunächst führte jede der Agentu­
ren ein Erstgespräch mit dem Auftrag-
geber, in dem die Aktion umrissen und
der Bedarf – in unserem Fall im digita­
len Bereich – grob abgestimmt wurde“,
erzählt Sabrina Lück. Es folgte ein Kick-
off mit allen Beteiligten, in dem der
Kunde die Kampagnenidee präsentier­
te, um alle auf denselben Stand zu brin­
gen, und in dem Fragen geklärt wurden.
Das Resultat war ein Briefingdo­ku­ment,
aus dem das Projektmanagement den
Creative Brief ableitete, der die für Kon­
zeption und Kreation relevanten Punk­
te enthielt. Dann ging es ans Timing,
das natürlich mit allen abgestimmt wur­
de. Spätestens jetzt mussten Freigabe­
prozesse geklärt und die Entscheider
auf Kundenseite bekannt sein.
Auch die Kalkulation des Budgets
für den Digitalpart gehörte zu den Auf­
gaben von Sabrina Lück: „Zunächst
haben wir die Kosten anhand der An-
forderungen des Kunden und eines
ersten Briefings nur überschlagen: Wir
brauchten eine Campaign- und eine
Facebook-Website, Online-Werbemit-
tel, einen Newsletter. So kamen wir auf
den Betrag X, der natürlich noch nicht
komplett durchkalkuliert war.“ Den Kos­
tenvoranschlag klärte Sabrina Lück
mit der entsprechenden Abteilung bei
Mast-Jägermeister ab. Wichtig sei es,
die Kosten schon vor dem finalen Brie-
fing zu überschlagen, um den Kunden
bei seiner Jahresplanung beraten zu
können. Diese Grobkalkulation basie­re
vor allem auf Erfahrungswerten. Wäh-
rend des Projekts erstellt Sabrina Lück
meist in Zusammenarbeit mit Syzygys
Online-Media-Schwester uni­quedigi­tal
monatliche Qualitäts- und Leistungs­
008 PAGE eDossier 02.14 (Beitrag aus PAGE 11.2011)
­
­kontrollen sowie Reports für den
Kunden. „Es gibt natürlich auch Situati­
onen, in denen wir öfter nachschauen.
Nach dem Versand eines Newsletters
wollen wir ja möglichst schnell wissen,
wie erfolgreich er war.“
Die Tools, mit denen die Projektma-
nager in den Agenturen arbeiten, sind
unterschiedlich. Um Briefings, Timings
und Kalkulationen festzuzurren, kom-
men bei Syzygy vor allem Word und
Excel zum Einsatz. Eine agentureigene
Software hilft beim Erfassen und Ab-
rechnen der Stunden. „Hier kann man
genau sehen, wie lange welcher Kolle-
ge auf welchem Projekt gearbeitet hat.
Das ist wichtig fürs Controlling, denn
wenn zu viele Stunden auflaufen, müs­
sen wir steuernd eingreifen. Darüber
hinaus erlaubt uns die Software, die
Ressourcenplanung vorzunehmen“, so
Sabrina Lück.
Redmine, ein Webtool auf der Basis
von Ruby on Rails, hilft während der
Testphase beim Beheben von Bugs,
indem es den Workflow vor allem zwi-
schen Projektmanagement und Tech-
nik verbessert. „Stelle ich zum Beispiel
fest, dass ein Link noch nicht funktio-
niert, notiere ich das in Redmine und
schicke es an den Entwickler. Ist das
erledigt, bekomme ich, ebenfalls über
Redmine, eine entsprechende Rück-
meldung“, erklärt Sabrina Lück. „Ge-
nauso verfahren wir mit Tasks. Wenn
wir sehen, dass irgendwo noch ein
kleiner Text fehlt, schicken wir einen
Task an das Team. Das funktioniert viel
besser als E-Mails, die in der täglichen
Flut leicht untergehen.“ Allerdings sei
Redmine kein Ersatz für die persön-
liche Kommunikation im Meeting oder
per Telefon, sondern lediglich eine Er-
gänzung, die dem Projektmanager die
Übersicht erleichtert.
Martin et Karczinski setzt bei der
Aufgabenkontrolle, Kostentransparenz
In der aktuellen Phase kann man eines von zehn Autos gewinnen. Dafür braucht es den Aktionscode auf den Verpackungen
und Projektplanung auf die Software
Troi, die sie ursprünglich für sich selbst
entwickelt hatte. Inzwischen ist Troi
selbstständig geworden und bildet ein
eigenständiges Unternehmen, die Troi
GmbH. Ebenfalls von Designern für
Designer kommt Solo. Jerome Iveson
aus dem britischen Newcastle upon
Tyne weiß aus eigener Erfahrung, wie
schnell es gehen kann, dass man sich
voll auf den kreativen Part eines Pro-
jekts konzentriert und den ganzen fi-
nanziellen und organisatorischen Kram
beiseiteschiebt. Darum hat er mit sei-
ner Firma Thrive ein All-in-one-Tool für
Freelancer entwickelt, das einfach zu
bedienen ist und dabei auch noch gut
aussieht (siehe Seite 23). Eine deutsche
Version gibt es bisher noch nicht, doch
unter  http://thrivesolo.co  lässt sich ei-
ne kostenlose Testversion herunterla-
den und zwei Wochen ausprobieren.
Beim Jägermeister-Projekt bot sich
eher traditionelles als agiles Projekt-
management mit Scrum an. „Natürlich
arbeiten wir bei Syzygy mit Scrum, aber
eher dann, wenn es um komplette An-
wendungen, etwa für große Portale,
geht“, sagt Sabrina Lück. „Die Daily-
Scrum-Meetings, die dann nötig sind,
wären bei den ,Jägermeister Legenden‘
auch deshalb schwierig gewesen, weil
wir viel mit den Kollegen von Hi-ReS! in
Hamburg gearbeitet haben.“ Eine Art
Mini-Scrum fand allerdings in der Tech­
nik statt. Ein vierköpfiges Flash-Team
baute gemeinsam an einem Backend,
das sowohl die Kampagnen- als auch
die Facebook-Website bediente. Da
machte die Wand mit Post-its Sinn, an
der nach und nach die Zettelchen von
der Rubrik „to do“ in die Spalte „done“
geklebt wurden.
Knackpunkte gab es bei der Jäger-
meister-Kampagne natürlich auch. Das
waren zum einen die sehr festen Termi­
ne und dass man, während man noch
mit der Umsetzung der ersten Phase
beschäftigt war, schon die zweite kon-
zipieren musste, also an zwei Projek­ten
parallel arbeitete. Auch kam­pag­nen­
spezifische Eventualitäten mussten im
Vorfeld bedacht werden. „Schließlich
hatten wir es mit Oldtimern zu tun,
und wir fragten uns: Was passiert ei-
gentlich, wenn mal einer plötzlich aus-
fällt?“ Also suchte die Eventagentur
nicht nur fünf, sondern sechs Autos
aus. Und da es wesentlich länger dau-
erte als gedacht, bis endlich feststand,
welche fünf nun wirklich über die Web­
seite vermietet wurden, bereitete sie
einfach alle sechs für den Einsatz in der
Kampagne vor. Am Ende hat aber alles
sehr gut geklappt, die Websites gingen
pünktlich online und auch die codier­
ten Aktionspackungen waren recht-
zeitig im Handel verfügbar.
Hört man Sabrina Lück erzählen,
kann man sich kaum vorstellen, dass
gerade kleinere Agenturen und De­
signbüros noch immer ohne Projekt-
manager arbeiten. Denn wenn dieser
Job von der Kreation mitübernommen
wird, läuft er spätestens dann neben-
bei, wenn es gestalterische und kon-
zeptionelle Fragen zu klären gibt. „Ich
würde jeder Agentur die Investition
in einen Projektmanager empfehlen,
denn es ist schon ein Fulltime-Job, auch
bei kleinen Projekten“, ist Sabrina Lück
überzeugt. Wer keinen fest anstel­len
möchte, kann auch projektbezogen auf
einen freien Projektmanager zurück-
greifen (siehe Interview auf Seite 12).
Schließlich gehören Zeiterfassung, Ka-
pazitätenplanung, Angebotserstellung
und ein stets offenes Ohr für die Wün-
sche und Ideen von Kunden nicht zu
den Dingen, um die sich Kreative auch
noch kümmern. Ein guter Projektmana­
ger hält dem restlichen Team den Rü-
cken frei – und das kommt sowohl der
Kreationsarbeit als auch der Zufrieden­
heit aller Beteiligten zugute.  ant/wl
 Nice-to-must-have.
NEU
IM SHOP:
DAS PAGE
BOOK

PAGE Book »Originalität ist der beste Kopierschutz«

Skizzenbuch mit Flexcover aus Lederfaserstoff natur, anthrazit / 
neon-oranges Punktraster auf den Innenseiten / Maßtabellen,
Tastaturkürzel / 165 mm x 220 mm / 256 Seiten

PAGE Shop: PAGE Book – Originalität ist der beste Kopierschutz /

typoPAGE – geballte Typografie auf 196 Seiten / Schneidematte –
stabil & stilvoll / DTP-Typometer 2.0 – mit US- und DIN-Formaten.
Jetzt bestellen: shop.page-online.de/produkte
010 PAGE eDossier 02.14 (Beitrag aus PAGE 11.2011)

„Agenturpolitik betrifft mich

nicht. Die Zeit, die ich vor Ort
bin, kann ich gezielt in das
Projekt und das Team stecken“
Zwölf Jahre lang arbeitete Kati Schäddel als Beraterin in den verschie-
densten Agenturen. Im April letzten Jahres machte sie sich in Hamburg
als Projektmanagerin selbstständig

Sie werden auch von großen Agenturen gebucht. Haben die keine
eigenen Projektmanager?
Kati Schäddel: Doch natürlich. Sie brauchen meine Unterstüt-
zung, wenn der eigene Projektmanager länger ausfällt, zum Bei-
spiel wegen Elternzeit, oder ein Projekt so umfangreich ist, dass
die internen Kapazitäten nicht mehr ausreichen.
Das heißt, Sie müssen sich häufig in ein schon länger bestehendes
Team einarbeiten. Ist das ein Problem?
Im Normalfall nicht. Ich bin ja für das Team eine Entlastung. Des-
halb stehen mir eigentlich alle positiv gegenüber. Ich habe noch
nie erlebt, dass ich irgendwo hingekommen bin und nicht will-
kommen war. Im Gegenteil. Die Leute sind offen, freuen sich,
dass ich da bin und wissen, ich komme, um sie zu unterstützen.
Deshalb sind sie auch hilfsbereit, wenn ich am ersten Tag allen
Löcher in den Bauch frage.
Wie viel Einarbeitungszeit wird Ihnen denn zugestanden?
Ich brauche selten länger als einen Tag, um loslegen zu können.
Das ist sportlich.
Jeder Mensch hat irgendein Talent. Meines ist, mich sehr schnell
anpassen und mich fix in Sachen einarbeiten zu können.
Was braucht ein Projektmanager neben einer schnellen
Auffassungsgabe noch?
Organisationstalent und ein supergutes Gedächtnis, weil ja sehr
viel parallel passiert. Ich kann sehr viel speichern und mir das auch
für lange Zeit merken. Wenn mich jetzt eine Agentur anruft, für
die ich vor einem halben Jahr gearbeitet habe, kann ich das alles
wieder abrufen. Unerlässlich sind gute Menschenkenntnis, sozia­le
Kompetenz, Nerven wie Drahtseile – und Humor. Denn in der
Werbung läuft meist nicht alles hundertprozentig stringent, und
dann ist es besser, darüber auch mal gemeinsam lachen zu können,
als die Nerven zu verlieren und innerlich zu explodieren.
Welche Tools verwenden Sie, um alles im Griff zu behalten?
Jede Agentur hat ihren eigenen Workflow und arbeitet mit ver-
schiedenen Tools. Das können Excel-Tabellen sein, Google Docs
oder ganz eigene Softwares für Zeiterfassung oder Statusberich­
te. Die gängigsten Programme wie Word, Excel, PowerPoint und
Keynote muss man natürlich beherrschen, in agentureigene Lö-
sungen muss man sich schnell einarbeiten.
Sie brauchen also auch technisches Verständnis, um eine neue
Software schnell zu begreifen.
Es macht sich tatsächlich nicht so gut, wenn man wie die Sau
vorm Uhrwerk steht und ein Teammitglied das Programm wieder
und wieder erklären muss.
Was ist in Ihrem Job besonders heikel?
Timings für Online-Projekte. Weil das, was der Kunde zu Anfang
in seinem Briefing vorgibt, meist nicht das ist, was es am Ende
wird. Zum Beispiel möchte ein Kunde eine Website oder ein Web-
special in Flash. Während die Kreation voll im Gestaltungspro-
zess drinsteckt, möchte er dann vielleicht doch etwas in 3-D oder
hier und da noch eine Animation oder was ganz Ausgefallenes.
Ein Online-Projekt entwickelt sich während des Prozesses. Des-
wegen ist es auch sehr schwer, am Anfang zu sagen: Das ist in
drei Monaten fertig.
Wie gehen Sie damit um: Der Kunde sagt: „Ich brauche es bald“, der
Kreativdirektor antwortet: „In Ordnung, drei Monate sollte
funktionieren“, und Sie sitzen daneben und denken nur „Oh, oh“?
Genau das sage ich dann auch „Oh, oh“. Dann schreibe ich ein
meines Erachtens realistisches Timing, das vor allem auf meinen
Erfahrungswerten beruht, mit Pufferzeiten bei den Milestones.
Wenn der Kunde das Timing sieht, sagt er oft fassungslos: „Wofür
um alles in der Welt braucht ihr sechs Monate?“ Ist das Projekt
be­endet, sagt er häufig: „Das haben Sie tatsächlich richtig einge-
schätzt.“ Den Kunden mit in die Prozesse einzubeziehen, halte
ich für unabdingbar, dann versteht er das Timing und was genau
die Agentur da eigentlich die ganze Zeit macht, auch besser.
Und wie kalkuliert man die Kosten?
Indem ich überlege, wie lange das Kreativteam braucht, wie lan-
ge der Motiondesigner oder der Flasher benötigt, also wie viele
Menschen an wie vielen Arbeitstagen an dem Projekt arbeiten.
Dann kalkuliere ich. Der umgekehrte Fall ist, dass der Kunde ein
bestimmtes Budget hat und ich herausfinden darf, was er dafür
bekommt. Wöchentlich ziehe ich mir Auswertungen, die mir sa-
gen, ob wir rentabel arbeiten oder ob an einigen Stellen zu viele
Stunden auflaufen und warum. Wenn ich merke, der Kunde dreht
gerade die dritte Korrekturschleife und im Kostenvoranschlag
sind nur zwei kalkuliert, muss ich ihn natürlich darauf hinweisen:
„Achtung, du überziehst jetzt gerade das Budget! Da kommen
Zusatzkosten auf dich zu.“
Was ist das Faszinierende an Ihrem Job?
Dass er so unglaublich abwechslungsreich ist. Ich arbeite nicht
jahrelang für den gleichen Kunden, und auch mit der Politik der
Agentur habe ich nichts zu tun. Die Zeit, die ich vor Ort bin, kann
ich wirklich in das Projekt und die Teamarbeit stecken.
Und Ihr persönliches Projektmanagement? Sie werden ja für
einen bestimmten Zeitraum gebucht. Was ist, wenn das Projekt
länger dauert?
Es kommt tatsächlich öfter vor, dass ich für zwei Monate gebucht
bin und dann werden vier daraus. Ich arbeite viel mit Xing oder
White Label, poste dort, wenn ich wieder buchbar bin. Die Agen-
turen sagen mir ja auch nicht erst am letzten Tag, dass sie mich
noch länger brauchen. Man darf halt nicht nervös werden, wenn
zwischen zwei Jobs mal ein oder zwei Wochen liegen. Diese Zeit
sollte man im Sinne einer einigermaßen ausgeglichenen Work-
Live-Balance für sich selbst nutzen.  ant
 Lückenlose Inspiration!
EINZELHEFTE
VERSAND-
KOSTENFREI
BESTELLEN!

Solange Vorrat reicht: PAGE-Einzelhefte lassen sich in unserem

Online-Shop einfach nachbestellen. Damit Sie kein Thema verpassen.
Damit es keine Lücken in Ihrer Sammlung gibt. Oder abonnieren
Sie gleich für ein Jahr – mehr unter shop.page-online.de
012 PAGE eDossier 02.14 (Beitrag aus PAGE 11.2011)
Zeitplanung Puffer
transparent einbauen
n Gerade bei Multichannel-Projekten ist das Timing sehr wichtig,
denn aus fixen Terminen ergeben sich Abhängigkeiten. Wenn wir
beim Jägermeister-Projekt etwa den Termin für den Live-Gang der
Kampagnen-Website nicht eingehalten hätten, wäre das ein Rie­
senproblem gewesen. Schließlich war in den Advertorials in „Bild“
die URL abgedruckt. Um so etwas zu verhindern, gibt es verschie­
dene Timings: den Kampagnen-Zeitplan, der festlegt, wann die
einzelnen Maßnahmen geschaltet werden, also wann die Website
online geht, der Newsletter verschickt wird, die Aktionspackun­
gen im Laden sind und so weiter. Der Milestone-Plan regelt die
Termine zwischen den Beteiligten: Der Kunde, die Event- oder die
PR-Agentur bekommt zu bestimmten Zeitpunkten bestimm­te
Dinge von uns und umgekehrt. Und dann gibt es noch ein internes
Timing, das die Projektabwicklung bei uns in der Agentur regelt.
Natürlich muss man Puffer einbauen, deren Umfang vor al­lem
von der Erfahrung des Projektmanagers abhängt. Klar, dass ein
Multichannel-Projekt aufgrund der Vielzahl von Beteiligten mehr
Zeit für Freigaben und Korrekturen braucht als ein Ein-Kanal-Job.
Ich kann nur empfehlen, mit Puffern transparent umzugehen,
also dem Kunden zu sagen: Ich habe hier einen Puffer eingebaut,
weil ich weiß, dass Korrekturschleifen und Freigaben auch mal
länger dauern. Es kommen auch Puffer-Vorschläge vom Kunden,
wenn er zum Beispiel weiß, dass eine Abteilung gerade urlaubs-
bedingt schwach besetzt ist und deshalb länger brauchen wird
als wir veranschlagt haben. Ein gut durchdachtes, realistisches Ti-
ming, das mit allen Beteiligten abgesprochen ist, kann eine Men-
ge Nerven und Geld sparen.
Sabrina Lück ist Accountmanagerin bei Hi-ReS! in Hamburg.
Dabei helfen ihr ein gutes Nervenkostüm, strategisches   Team oder dem, der am engsten mit dem
Denken und Durchsetzungsfähigkeit, gepaart mit Diplomatie.
Tipps für die Budgetplanung
Projekte vergleichen. Es ist sinnvoll,
sich beim Erstellen eines Angebots nach
vergleichbaren Projekten zu richten –
allerdings nicht nach dessen Kosten-
voranschlag, sondern nach den
tatsächlich abgeleisteten Stunden.
Disziplin. Befolgen Sie sklavisch Ihren
Budgetplan, und überprüfen Sie
ihn regelmäßig, um bei Schwierigkeiten
schnell reagieren zu können
Keine Angst vor Problemen. Sprechen
Sie mit Ihrem Kunden frühzeitig über
Schwierigkeiten wie Fehleinschätzungen
in der Budgetplanung.
Vorsicht vor Unterschätzung. In den
meisten Fällen unterschätzt man den not-
wendigen Zeit- und Kostenaufwand –
vielleicht aus Angst, für inkompetent oder
zu teuer gehalten zu werden. Dennoch:
Kalkulieren Sie realistisch, das schafft auch
beim Kunden nachhaltig Vertrauen.
Verhandlungsgeschick. Verhandlungen
immer vom erfahrensten Mann im
Kunden in Kontakt steht, führen lassen!

Budgetplanung Hinschauen, abgleichen,
kommunizieren
n Bei der Budgetplanung orientieren wir uns zunächst
an vergleichbaren Projekten aus der Vergangenheit. Als
Erstes überlegen wir nach der Anfrage für einen Job: Fühlt
sich das Projekt in Bezug auf Größe und Inhalt eher an
wie der Website-Relaunch aus dem letzten oder der
iPhone-App aus diesem Jahr? Auch wenn es nichts Ver-
gleichbares gab, wissen wir, dass ein Projekt in der ers­
ten Phase Strategen, Konzepter und Designer und erst
später weitere Designer und Techniker braucht, und pla-
nen das von Beginn an nach Kalenderwochen durch. Na-
türlich ist es schwieriger, Kreation als Technik zu kalkulie-
ren, weil eine Idee manchmal eine Stunde, manchmal
fünf Tage Zeit benötigt. Wird in Projekten Neuland betre-
ten, macht es Sinn, Spezialisten – bei uns etwa unsere in-
ternationalen Razorfish-Kollegen – einzubeziehen. Au-
ßerdem gilt es, den Grad der Fertigstellung eines Projekts
im Verhältnis zu verbrauchten Mann-Tagen und Budget
im Blick zu behalten, etwa in den Checkpoints nach je-
dem Scrum-Sprint. Ohne Zeiterfassungsprogramme läuft
nichts. Nur anhand der tatsächlich angefallen Stunden
im Vergleich zum Kostenvoranschlag kann man am Ende
des Projekts erkennen, wie gut eine Kalkulation war.
Bei der Kalkulation ist es unabdingbar, mit dem Kun-
den ehrlich zu sprechen und das Budget offen zu disku-
tieren. Man braucht Fingerspitzengefühl, um herauszu-
finden, was eine Leistung dem Kunden wert ist, um dann
zu schauen, wo Features weggelassen, ersetzt oder er-
gänzt werden können. Dazu gehört auch, Schwierigkei­
PAGE eDossier 02.14 013
ten nie auszusitzen, sondern direkt anzusprechen! Viele
Kunden haben durchaus Verständnis, wenn man sie
nach einem Nachschlag fragt. Es ist wichtig, sie frühzeitig
zu sensibilisieren, wann eine Änderung eine zusätzliche
Leistung ist. Beim Change Request Management kann es
aber auch sinnvoll sein, erst einmal abzuwiegeln und zu
schauen, ob eine Leistung im Budget enthalten oder nun
als Konzeptänderung ein weiteres Angebot angebracht
ist, denn ein neuer Kostenvoranschlag und die Diskus­
sion mit dem Kunden erfordert viel Zeit, Energie und Ein-
satz. Um das Budget im Blick zu behalten, hilft übrigens
auch, dem Team ein Grundgefühl fürs budgetäres Ar-
beiten zu vermitteln – wenn für eine Aufgabe nur fünf
Tage berechnet werden, kann das Team sich nun mal
nicht selbst verwirklichen.
Budgetplanung mit Scrum
Es gibt Studien, die besagen, dass Scrum-Teams bis zu
doppelt so effizient wie anders organisierte Projekt-
teams sein können. Ein Hauptgrund dafür ist, dass es
durch die enge Verzahnung der Arbeit und regelmä-
ßigen Abstimmungen – Kreative und Programmierer
setzen sich intensiver gemeinsam mit den Problemen
und Aufgaben auseinander – zu weniger Fehlentwick-
lungen kommt und schneller passende Lösungen gefun-
den werden. Während sich mit dem Wasserfall-Prinzip
eher Mängel im Zeit- oder Budgetplan vertuschen las-
sen, sorgt Scrum für Transparenz. Die Methode lohnt
sich vor allem für Teams zwischen fünf und neun Per-
sonen und dann, wenn ein Projekt zahlreiche ungewisse
Faktoren, etwa bei der Entwicklung technischer Innova-
tionen, mit sich bringt.
Hilfreich beim Überprüfen des aktuellen Budget- und
Zeitstands sind die in Scrum bekannten Burndown-
Charts. Diese vergleichen mit visuellen Mitteln die abge-
leistete Arbeit mit dem Idealzustand. Bei großen und
langen Projekten nutzen wir zusätzlich Treemaps, einen
Diagrammtyp, der aus der Architektur stammt: Hier wird
der Verkehr zwischen verschiedenen Nutzungsberei­chen
innerhalb eines Gebäudes – Wohnen, Essen Schlafen –
farbig visualisiert. Im Projektmanagement lässt sich mit
diesen Landkarten durch unterschiedliche Farben und
Formate bildlich aufzeigen, wie viel Prozent der Features
bereits fertiggestellt sind und wie viel Prozent das Team
noch leisten muss.
Hagen Seidel behält als Projektleiter und zertifizierter
Scrum Master bei Neue Digitale / Razorfish, die  
Budgetplanung und -kontrolle mit Scrum im Griff.
014 PAGE eDossier 02.14 (Beitrag aus PAGE 11.2011)

Qualitätsmanagement Ansprüche flexibel umsetzen

n Wesentlich für das Qualitätsmanagement ist zunächst, die und Zulieferer erhalten konkrete Qualitätsvorgaben, die sich
eigenen Ansprüche zu klären. So kann man bewusst ent- messen und vergleichen lassen. Dass wir Ideen sichtbar ma-
scheiden, wo diese durchgesetzt werden müssen und wo chen können, ist ein Vorteil der Gestaltung, den wir nutzen
andere Prioritäten im Vordergrund stehen. Ein Beispiel: Un- müssen. Wichtig sind in diesem Zusammenhang handunter-
sere „Zwangsarbeit“-Wanderausstellung sollte nach ihrer Pre­ zeichnete Freigaben, die auch eine symbolische Funktion
miere im Jüdischen Museum Berlin im Museum des Großen haben: Beim Setzen seiner Unterschrift hält der Kunde inne
Vaterländischen Krieges in Moskau gezeigt werden. Der Trans­ und fokussiert seine Aufmerksamkeit auf das Projekt.
­port wurde am Zoll aufgehalten, sodass es zeitlich eng wurde.
Zudem kamen Bauteile und Exponate beschädigt in Moskau Stefan Rothert, Geschäftsführer von Gewerk design in
an. Wir bemühten uns, die Schäden rasch zu beheben, stießen Berlin, und Ann-Christin Warntjen, Projektmanagerin  
dabei aber bei den russischen Mitarbeitern auf Unverständ- des disziplinenübergreifenden Designbüros, legen Wert  
nis für unsere Ansprüche. „Das sehen die Besucher doch nicht, auf Qualitätsmanagement in komplexen, inter- 
die Räume sind dunkel“, hieß es beispielsweise. Hier muss- disziplinären Gestaltungsprozessen.
ten wir mit viel Fingerspitzengefühl entscheiden, an welcher
Stelle deutsche Akribie und wo russische Gelassenheit an-
gebracht ist – was letztlich auf beiden Seiten zu Respekt für
die Perspektive des anderen führte. Als Projektmanager muss
man improvisieren und empathisch auf den Prozess reagie-
ren können. Dazu gehört es auch, Fehler zuzulassen und
einzugestehen – denn Schwierigkeiten treten immer auf.
Obwohl kostenintensiv und zeitaufwendig sind für die
Absicherung der gestalterischen Qualität gerade im Ausstel­
lungsdesign Konstruktionszeichnungen, Musterbauten und
Modelle aller Art unabdingbar. Langfristig lohnen sie sich,
weil sie Verbindlichkeiten schaffen: Für uns klärt sich, ob ein
Konzept in der Praxis funktioniert; Kunden können sich nicht
herausreden, sie hätten sich andere Ergebnisse vorgestellt;

Besprechung und Aufbau der
Ausstellung über Zwangsarbeit –
links im Jüdischen Museum in Berlin,
rechts im Museum des Großen
Vaterländischen Krieges in Moskau
Welche Fähigkeiten ein Projekt-
manager mitbringen muss
Ausdrucksvermögen. Ein Projekt-
manager muss seinen Plan und seine
Ansprüche artikulieren können.
Verlässlichkeit. Ansagen sollten
eingehalten, Fehler eingestanden
werden können.
Aufmerksamkeit. Es gilt, Stimmungen
und Situationen ganzheitlich zu
erfassen, ein Gefühl für den richtigen
Zeitpunkt, den richtigen Ort und den
richtigen Ton zu entwickeln.
Soziale Kompetenz. Projektmanager
müssen in der Lage sein, dem inhaltlich
fokussierten Kunden, Kreativen und
Handwerkern adäquat und auf
Augenhöhe zu begegnen.
Zielstrebigkeit. Es gilt, das Ziel zu jeder
Zeit im Auge zu behalten.
Kompromissbereitschaft. Projekt-
manager sollte einen ganzheitlichen
Anspruch an das Projektergebnis
haben, um in Detailfragen auch
Abstriche machen zu können.
Gestalterisches Verständnis.
Projektmanager müssen keine
Gestalter sein, sollten aber ein hohes
Maß an Interesse für Design besitzen.
PAGE eDossier 02.14 015
Teamkommunikation
Erwartungen managen
n Für jeden neuen Auftrag veran-
lasse ich zunächst ein Kick-off-Mee-
ting mit dem ganzen Team. Ich bin ein
Freund des persönlichen Gesprächs,
weil sich Inhalte dabei besser ver-
mitteln lassen als per Telefon oder E-
Mail. Wenn ein Briefing zu vage ist –
egal, ob es mündlich oder schriftlich
erfolgt ist –, habe ich mich schon vor
diesem Kick-off mit dem Kunden in
Verbindung gesetzt und die Details
geklärt. Es ist wichtig, dass mir die
Aufgabe völlig klar ist, um sie allen
Beteiligten, Designern wie Textern,
aber auch den externen Partnern,
verständlich und präzise vermitteln zu können.
Dabei ist es hilfreich, die unterschiedlichen Vorlieben der
Kreativen zu berücksichtigen: Manche Kollegen können mit vi-
suellen Vorlagen, etwa vergleichbaren Werbemedien oder Bild-
sprachen, besser arbeiten. Bei externen Partnern halte ich alle
Absprachen schriftlich fest und lege ein möglichst genaues Brie-
fing vor. Generell bemühe ich mich, Informationen gebündelt
weiterzugeben, um den Prozess für alle effizient zu gestalten.
Projektmanager bei KMS Team haben eine Schnittstellenpo-
sition mit konzeptionell-gestalterischem Fokus. So bin ich dieje-
nige, die im Prozess am Schluss die Qualitätssicherung der Er-
gebnisse übernimmt. Gibt es etwa noch einen Tippfehler im
Text oder einen Mangel beim Material, ist es meine Aufgabe,
diesen zu entdecken. Das braucht Zeit, deshalb kalkuliere ich für
die Qualitätskontrolle immer Puffer ein. Um eventuelle Schwie-
rigkeiten frühzeitig zu erkennen, ist es unabdingbar, während
eines Projekts regelmäßig bei den Kollegen vorbeizuschauen –
manchmal reicht hier auch ein kurzer Schulterblick.
Eine Herausforderung bei der internen Kommunikation be-
steht darin, die Erwartungen aller Beteiligten zu managen und
dabei unterschiedliche Charaktere und Interessen unter einen
Hut zu bekommen: Während für die Designer etwa maximale
gestalterische Qualität im Vordergrund steht, ist für die Ge-
schäftsführung auch Effizienz ein wesentlicher Faktor. Manche
Kollegen arbeiten lieber an mehreren Projekten gleichzeitig,
während andere sich gern auf eines konzentrieren und hier be-
sonders in die Tiefe gehen – auch das gilt es bei der Projektver-
gabe, wenn möglich, zu berücksichtigen. Manchmal haben Pro-
jekte, beispielsweise Pitches, eine hohe Dynamik; die Teams ver-
ändern und vergrößern sich während des Prozesses. Deswegen
ist es sinnvoll, alle Verantwortlichkeiten bereits im Vorhinein ge-
nau zu definieren.
Zuletzt kommt den Reviews nach größeren Projekten, aber
auch schon nach dem Erreichen von Meilensteinen, eine große
Bedeutung zu, um aus der Analyse der Prozesse zu lernen. Viele
erfolgreiche Projekte werden von Teams umgesetzt, die zuvor
schon öfter in dieser Konstellation zusammengearbeitet haben.
Auch Projekte für langjährige Auftraggeber, bei der sich beide Sei­
ten gut kennen, laufen häufig besonders reibungslos. Die Ab-
stimmung ist hier meist sehr eng, die Kommunikation transparent.
Joana Schmidtjansen, Projektmanagerin bei KMS Team in
München, versteht die Perspektiven aller beteiligten Parteien.
016 PAGE eDossier 01.12 (Beitrag aus PAGE 11.2011)
Kundenkommunikation Vertrauen bilden
n In der Kommunikation mit dem Kunden kommt es auf
einen intensiven Dialog, die frühe Einbeziehung des Auf-
traggebers und präzise Informationsvermittlung an. Das
Tool Merlin eignet sich besonders gut, um den Projekt-
verlauf mit den verschiedenen Schritten, Meilensteinen
und Abnahmeschleifen im Überblick zu behalten. Hier
wird deutlich, wie viel Zeit einzelne Schritte in Anspruch
nehmen dürfen: So können wir dem Kunden genau auf-
zeigen, bis zu welchem Termin wir Feedback, Inhalte oder
Bildmaterial brauchen und was er in Zwischenabnahmen
von uns bekommt. Merlin macht die Auswirkungen und
Abhängigkeiten jeder einzelnen Aufgabe im inhaltlichen
und zeitlichen Kontext optimal sichtbar: Es legt dar, wa-
rum etwa auf die Wireframes das Design und zuletzt die
Programmierung folgen oder warum Bildmaterial an ei­
nem bestimmten Zeitpunkt definitiv vorliegen muss.
Wichtig ist eine transparente Kostenaufstellung. Da-
bei hilft Troi, die Positionen in einzelne Module aufzu-
splitten – was unseren Kreativen nicht erspart, vor der
Kalkulation mit dem Konzept zu beginnen. Zudem gilt es
die Kommunikation vorab auf die Bedürfnisse der Kun-
den abzustimmen: Viele freuen sich über To-do-Listen und
Erinnerungsmails, andere wollen in Ruhe gelassen wer-
den. Ein wesentlicher Aspekt dabei ist ein fester Termin-
plan für Feedbackschleifen. Bei Webprojekten wird meist
eine solche Schleife nach dem Initialdesign für die Site
und eine nach der Entwicklung der Unterseiten einge-
baut. Einige Kunden kommen auch regelmäßig für einen
Schulterblick vorbei. Um für einen reibungslosen Ablauf
zu sorgen, sollten die Abnahmephasen mit einem kleinen
zeitlichen Puffer versehen, vor allem aber frühzeitig defi-
niert werden, damit sich der Auftraggeber darauf ein-
stellen kann. Hierbei ist rhetorisches Geschick gefragt –
er soll den Zeitplan ja nicht als Zwangsjacke, sondern als
unterstützendes Angebot verstehen.
Eine weitere kommunikative Herausforderung be-
steht darin, geplante Designelemente, die im frühen
Projektstadium noch nicht sichtbar sind, verständlich zu
machen. Viele Kunden können sich nicht vorstellen, dass
die Ästhetik der Wireframes als Strukturskizzen nichts
mit dem Design zu tun hat. Letztlich hilft hier vor allem
Geduld – es braucht Zeit, bis der Kunde der Kompetenz
der Kreativen vertraut. Schwierig kann auch sein, den
Wert der Designleistung argumentativ zu vertreten. Für
Nutzungsrechte etwa haben Kunden oft kein Verständ-
nis. Schlüssig finden die meisten aber folgenden Ver-
gleich: Der Nike-Swoosh ist in kurzer Zeit entstanden,
aber doch auch offensichtlich wesentlich mehr wert als
den bloßen Zeitaufwand.
Luzi Kahn ist Projektmanagerin in der Kölner Motion-  
und Digitaldesignagentur Elastique. Sie über- 
nimmt unter anderem den kommunikativen Part mit  
den Kunden.
Reporting Transparenz PAGE gibt’s übrigens
und Kontrolle auch in RGB.
n An der ausführlichen Dokumentation, wie wir unse­
rer Design- und Strategieprojekte organisieren, haben
unsere Kunden verstärkt Interesse – auch aufgrund
des Drucks aus dem Einkauf und dem eigenen Con­­
trolling. Unsere Ansprech­partner werden zunehmend
in die Reporting- und Nachweispflicht genommen –
wir tragen Sorge dafür, dass sie den Projektprozess in-
tern nachweisen können und unterstützen sie bei ih-
rer Projektführung. Dazu liefern wir in monatlichen
Jours fixes und E-Mails transparente Reportings, die
unsere Kunden als großen Mehrwert schätzen. Inzwi-
schen fordern viele präzise Angaben darüber, welche
Positionen und welche Mitarbeiter zu welchen Tages-
sätzen und mit welchem Zeitkontingent eingesetzt
werden. Wir erstellen dazu Übersichten mit konkreten
Informationen, wie viel Prozent der qualitativen Leis­
tung, der anberaumten Zeit und des Budgets bereits
verbraucht wurden. Vorab klären wir, in welcher Form
und wie oft der Kunde informiert werden möchte. Un-
sere Reportingübersichten variieren je nachdem, ob
er sie nach inhaltlichen Oberthemen, nach Budget,
Strategie- oder Designleistung gegliedert benötigt.
Seit wir das Reporting sukzessive ausbauen, funktio­
niert die Kommunikation deutlich besser. So wird auf
Kundenseite weniger nachgehakt, und die Fragen in
den Jours fixes sind konkreter. Negativ betrachtet lässt
sich diese neue Reportingkultur so interpretieren, dass
der Kunde damit die Agenturmitarbeiter und -ressour­
cen kontrolliert. Wir sehen darin eher die Chance der
Planungssicherheit; wir disziplinieren uns damit ein
Stück weit selbst. Es bietet sich für uns die Möglichkeit,
Budget- und Leistungsfragen frühzeitig zu kommuni-
zieren, etwa Nachkalkulationen zu begründen. Doch
ist es auch wichtig, sich als Agentur gegenüber dem
Kunden Freiheiten zu verschaffen, sich zum Beispiel
keine Leistungsqualitäten diktieren zu lassen: Wir kön-
nen am besten beurteilen, welche Mitarbeiter und wel­
ches Zeitkontingent für ein Projekt notwendig sind.
Um nicht als ausgelagerte Unternehmensabteilung
oder reiner Zulieferer verstanden zu werden, braucht
es vor allem gegenseitigen Respekt.

Nina Oswald, Managing Director bei Interbrand in  

Köln, liefert den Kunden mit transparenten  
Projektdokumentationen einen enormen Mehrwert.
018 PAGE eDossier 02.14 (Beitrag aus WEAVE 05.2013)

A

ABENTEUER
AGIL
Wer agile Arbeitsweisen einführen will, unternimmt eine Reise ins Ungewisse –
das gilt für Agenturen und Auftraggeber gleichermaßen. Und doch kann
gerade der Bereich User Experience enorm davon profitieren. Stefan Freimark
erläutert die Rahmenbedingungen für erfolgreiche agile Projekte
// Kanban, Crystal Clear, Lean Ma­
nagement, Scrum ... In Ausschrei­
bungen und Pitches häufen sich
die Anfragen nach agilen Arbeits­
weisen, und auf der Berliner IA Konfe­
renz im Mai (  http://2013.iakonferenz.
org  ) war dies der Schwerpunkt der Vor­
träge. Nicht ohne Grund, denn Scrum
und Co bieten handfeste Vorteile ge­
genüber dem klassischen Projektab­
lauf nach dem Wasserfallmodell.
Das Wasserfallmodell sieht einen
kla­­ren Plan mit eindeutig voneinander
abgegrenzten Projektphasen vor – nicht
selten mit dem Ergebnis mangeln­den
Dialogs zwischen den Diszi­pli­­nen. Dies
führt dazu, dass die Beteilig­ten oft kei­­
ne Verantwortung für das Ge­­samt­er­
geb­­nis überneh­men. Dazu hat das
Team zu Beginn meist nur ein ver­
meintlich klares Bild vom End­er­geb­
nis – und erstellt eine detaillier­te Spe­
zifika­tion mit allen Fines­sen, von de­
nen in der Umset­zung nur die Hälfte
Gestalt annimmt. Dumm gelaufen!
Kein Wunder, denn zum Start ken­
nen weder die Auftraggeber noch die
Dienstleister wirklich alle Anforde­
run­gen – oft kommen im Verlauf des
Projekts noch neue Erkenntnis­se hin­
zu. Oder beim Auftraggeber wech­­seln
die Entscheider, und die Prioritäten
ändern sich. Auch die Technik kann
sich weiterentwickeln, oder die Betei­
ligten müssen auf neue Markterforder­
nisse reagieren. Wenn das Projekt
dann auch noch lange dauert, ist an­
gesichts dieses beweglichen Kontexts
das Risiko ziemlich groß, dass der Was­
serfallplan durcheinandergerät.
Agile Arbeitsweisen eignen sich be­
sonders gut, derlei Begleiterscheinun­
gen zu begegnen. Und doch ist es nicht
sinnvoll, sämtliche Projekte über ei­
nen Kamm zu scheren und nur noch
agil zu arbeiten – der Wasserfall hat
nach wie vor seine Berechtigung: Wenn
die Projektlaufzeit überschaubar ist,
die Anforderungen weitgehend klar
sind und mit Überraschungen nicht
zu rechnen ist, dann ist die traditio­
nelle Arbeitsweise besser geeignet.
Wer Scrum einführt, rüttelt an der
Unternehmenskultur
Erfolgreich können agile Projekte nur
sein, wenn die Unternehmenskultur es
zulässt. Das im Jahr 2001 von 17 Erst­un­
terzeichnern formulierte »Agile Ma­ni­
festo« definiert ein Wertesystem, das
Orientierung gibt. So gilt etwa: »Indi­
viduen und Interaktionen sind wichti­
ger als Prozesse und Werkzeu­ge.« Das
heißt aber nicht, dass es keine Regeln
gibt. Agil bedeutet nicht chaotisch!
Zum wirklich »agil sein«, statt nur
»agil tun«, gehört mehr, als nur be­
stimmte Scrum-Artefakte wie »Burn­
down Charts« (siehe Glossar, Seite 23)
oder »Product Backlogs« zu produ­
zie­ren oder definierte Meetings wie
»Sprint Review« oder »Retrospektive«
einzuhalten. Es reicht nicht, alten Ar­
beitsweisen einfach neue Namen zu
geben. Zum »agil sein« gehört das Be­
wusstsein, dass jeder im Team Verant­
PAGE eDossier 02.14 019
wortung für das Gesamtergebnis trägt. BUCHTIPPS
Das heißt auch: Wenn etwas nicht gut Jutta Eckstein: Agile
läuft oder Schwierigkeiten auftauchen, Softwareentwicklung in
großen Projekten.
hat jeder nicht nur das Recht, son­dern
Teams, Prozesse und
die Pflicht, das anzusprechen. Alle Technologien. Strate-
Team­mitglieder müs­sen offen für Ver­ gien für den Wandel im
änderungen sein und flexibel genug Unternehmen. Heidel-
berg (dpunkt.verlag)
bleiben, um Anregun­gen aufzugreifen.
2011, 270 Seiten, ISBN
Kommunikation ist generell Trumpf! 978-3898647908
Ein Beispiel: Die User Storys sollte
Bernd Oestereich,
nicht der Konzepter allein formulieren
Christian Weiss: APM –
und dann den Entwicklern zur Umset­ Agiles Projektmanage-
zung zuschieben, denn dies entsprä­che ment. Heidelberg
wieder der sequenziellen Arbeitsweise (dpunkt.verlag) 2007,
454 Seiten, ISBN
des Wasserfalls. Stattdessen ent­stehen
978-3898643863
die Storys durch Teamarbeit in Sprint
Null, einer zwei- bis vierwöchi­gen Vor­ Andreas Opelt, Boris
Gloger, Wolfgang Pfarl,
laufphase. Mathias Wrba, Leiter der Be­
Ralf Mittermayr: Der agile
ratung bei FELD M in München, riet auf Festpreis. Leitfaden für
der IA Konferenz, die User Storys als wirklich erfolgreiche
Diskussionsgrundlage zu betrachten. IT-Projekt-Verträge.
München (Carl Hanser)
2012,239 Seiten,ISBN
Gute Rahmenbedingungen 978-3446432260
führen zum Erfolg
›››  Lesen Sie auch
Damit das Team effizient arbeiten Stefan Freimarks
kann, braucht es einen Projektraum, Buchempfehlungen
in dem alle Teammitglieder Platz auf Seite 87
NAME Stefan Freimark
BERUF Senior-Konzepter, Mitorganisator des
UXcamp Europe (  www.uxcampeurope.org  ),
Dozent an der Good School Hamburg
(  www.good-school.de  )
FIRMA Aperto Berlin
URL www.aperto.de
MEINE VERRÜCKTESTE IDEE WAR, mit der Bahn-
Card 100 an einem Tag von Nürnberg nach Nürnberg
zu fahren – über Hamburg, Köln und Frankfurt
020 PAGE eDossier 02.14 (Beitrag aus WEAVE 05.2013)
HERAUSFORDERUNG
Jutta Eckstein,
Trainerin,
Beraterin und
Autorin für
agile Software-­
entwicklung
›››  www.
jeckstein.com
»DIE UMSTELLUNG IST
DAS SCHWIERIGSTE«
Jutta Eckstein ist Expertin
für agile Software­entwicklung
und weiß, wie man Projekt-
teams auf »agil« einschwört
Was sind die Stolpersteine bei der Einführung
agiler Arbeitsweisen?
Meist ist es die so wichtige Umstellung auf soge­
nannte Featureteams oder crossfunktionale Teams:
Unterschiedliche Disziplinen müssen gemeinsam
Funktionalitäten entwickeln und diese auch in recht
kurzen Zyklen – etwa zweiwöchentlich – liefern.
In vielen Unternehmen ist der Silogedanke so aus­
geprägt, dass eine echte Zusammenarbeit mit ge­
genseitiger Unterstützung nur schwer möglich ist.
Wie sollte ein Team konkret vorgehen,
um auf agil umzustellen?
Es ist essenziell, auf existierende Erfahrung be­
züglich Prozessen und Zusammenarbeit aufzubau­
en. Als Einstieg bietet sich eine Retrospektive an,
sodass wertvolle Erfahrungen nicht verloren ge­
hen. Darüber hinaus übernimmt das Team direkt
die »Ownership« über den Prozess. Regelmäßige
Retrospektiven tragen dann dazu bei, dass das
kontinuierlich Dazugelernte transparent und die
Zusammenarbeit ständig verbessert wird.
Oft arbeiten die Teams ja verteilt.
Was ist dann zu beachten?
Das Team muss in der Lage sein, gemeinsam Funk­
tio­nalitäten zu erstellen. Das bedeutet, dass die
Mitarbeiter unabhängig vom Standort zusam­
menarbeiten. Das heißt die Teamgrenze orientiert
sich weder an Raum oder Zeit noch an Aufgaben
wie Analyse, Design, Entwicklung oder Test. Da­
für müssen alle gleichermaßen auf Informationen
zugreifen können. Nicht selten erweist sich eine
Firewall als der größte Verhinderer einer standort­
übergreifenden Zusammen­arbeit.
»DIE EIGENTLICHE
IST, EIN TEAM ZU
EINEM AGILEN TEAM
ZU MACHEN«
Jens-Christian Jensen, Director Beratung & Konzeption, Pixelpark
finden – und zwar nicht nur für den
regelmäßigen Statusabgleich, sondern
zum Arbeiten! In Agenturen kann hier
schnell ein Konflikt entstehen, denn
wo­möglich sind die Beteilig­ten nicht
zu 100 Prozent für das Projekt ein­ge­
plant, sei es, weil kein Budget für eine
Besetzung an fünf Tagen die Woche
vorgesehen ist oder dass in ei­nem an­
deren Projekt noch Arbeit ansteht.
Für den betroffenen Mitarbeiter be­
deutet das dann, dass er gedanklich
oft zwischen verschiedenen Projek­ten
wechseln muss und sich nicht auf eine
Aufgabe konzentrieren kann. Außer­
dem ist der Projektraum dazu gedacht,
schnell miteinander zu kommunizie­
ren. Wenn Teammitglieder in weitere
Projekte eingebunden sind, passiert es
leicht, dass sie wegen Besprech­un­gen
für diese anderen Projekte gar nicht im
Raum und somit nicht ansprechbar
sind. Dadurch bleibt nicht nur die Idee
eines Projektraums auf der Strecke, es
wird auch ein wesentli­cher Wert des
agilen Arbeitens ad absurdum geführt,
nämlich die Wertschätzung für Indi­vi­­
duen und Interaktionen. Daher sind
agile Arbeitsweisen vor allem für grö­
ßere Pro­jekte geeignet, bei denen die
Teammit­glieder für einen längeren
Zeitraum nahezu ausschließlich für
dieses eine Vorhaben tätig sind.
Wenn Sie sich für agile Methoden
entscheiden, gilt: Ken­nen Sie die Re­
geln, bevor Sie sie brechen! Die emp­
fohlenen »Artefakte«, Abläufe und
Mee­tings (siehe Seite 23) sind gut
­dazu geeignet, unerfahrenen Projekt­
teams Orientierung zu geben. »Teil­
agil« oder »moderat agil« arbei­ten,
um alte Arbeitsweisen beizubehalten
– das geht meistens schief.
Neue Bedingungen für Auftraggeber
Agil zu arbeiten heißt, sich iterativ an
ein bewegliches Ziel anzunähern. An­
ders gesagt: »Fahren auf Sicht«. Dar­
›››  @gibkette
auf kann oder will sich nicht jeder
Auftraggeber einlassen. Anders als
das Wasserfallmodell mit seiner ver­
meint­lichen Planungssicherheit löst
die Beschreibung agiler Arbeitsweisen
oft erst einmal Unsicherheit aus, die
bei genauerer Sicht der Dinge aller­
dings in der Natur von Digitalprojek­
ten generell begründet ist.
Sie sollten Auftraggeber auch nicht
darüber im Unklaren lassen, auf was
sie sich unter dem Stichwort »agil«
einlassen: Entgegen einem weit ver­
breiteten Irrtum bedeutet dies näm­
lich nicht, dass der Kunde jederzeit
Än­derungen einbriefen kann. Der
Kun­de kann erst im Review Meeting
die Ergebnisse ansehen und mit allen
Teammitgliedern sprechen und, soll­
te B­edarf bestehen, eine neue Rich­
tung vorgeben, ehe sich das Team für
eine weitere Iteration in den nächsten
Sprint zurückzieht.
Agile Projekte erfordern auch an­
dere Verträge. In Wasserfallprojekten
gibt es Werkverträge, in denen vor Pro­
jektstart der Gegenstand der Lieferung
festgelegt ist. Anders bei agilen Projek­
ten: In ihnen ist zwar nicht völlig un­
bekannt, was entwickelt werden soll –
wie das Endergebnis tatsächlich aus­
sieht, zeigt sich aber hauptsächlich
auf dem Weg. Eine Möglichkeit ist,
zwar einen Festpreis zu vereinbaren,
aber das exakte Endergebnis an dieser
Stel­le noch nicht festzulegen. Statt­
dessen vereinbaren Auftraggeber und
Dienst­leister, dass sie im Laufe des
Projekts gemeinsam beschließen, wel­
che Features bis zur bekannten Bud­
get­gren­ze umgesetzt werden sollen.
Andreas Opelt, Boris Gloger, Wolfgang
Pfarl und Ralf Mittermayr beschreiben
in ihrem Buch »Der agile Festpreis«,
wo­rauf Sie bei agilen Projekten ach­
ten sollten, und schlagen unter ande­
rem Musterverträge vor (  http://is.gd/
DerAgileFestpreis  ).

Schlüsselpositionen
richtig besetzen!
Bei Scrum gibt es neben dem Ent­
wicklungsteam zwei weitere Rollen:
den Product Owner (kurz PO) und den
Scrum Master. Zu den Aufgaben des
POs gehört es, Kontakt zum Kun­den
zu halten. Er muss Anforderun­gen
aufnehmen und diese mit dem Kun­
den priorisieren, um dann die jewei­
ligen Sprints vorzubereiten, damit das
Projekt sich in die richtige Richtung
entwickelt. Und er muss Kun­den­
wünsche während eines Sprints vom
Team fernhalten, damit es sich unbe­
schwert auf den aktuellen Sprint kon­
zentrieren kann. Außerdem muss der
PO das Gesamtprodukt im Blick ha­
ben und dabei eine gute Balance zwi­
schen den Interessen der Nutzer, des
»USER STORYS SIND CONVER­SATION
STARTERS. SIE SOLLEN ZU
BEGINN NOCH NICHT ALLES VOLL-
­UM­­FÄNG­LICH FESTLEGEN«
Mathias Wrba, Stellvertretender Geschäftsführer,
FELD M GmbH, München
›››  @screaminhias
Auftraggebers, aber auch des Auf­trag­
nehmers finden. Da der PO inhalt­lich
tief in das Projekt involviert sein muss,
ist ein hohes zeitliches Engagement
erforderlich – kurz: Diese Aufga­be
kann man nicht nebenbei erledigen.
Der Scrum Master sorgt dafür, dass
alle Beteiligten den Prozess einhalten.
Er ist dafür verantwortlich, dass die
vorgesehenen Meetings stattfinden –
in seiner Aufgabe als Moderator ach­
tet er darauf, dass die Teammitglieder
Konflikte ansprechen, damit sie ge­
löst werden können. Darüber hinaus
vermit­telt er die agilen Werte im Un­
ternehmen und beseitigt auftauchen­
de Hindernis­se, damit das Team effi­
zient arbeiten kann.
Übernimmt ein erfahrener Konzep­
ter (oder Designer oder Entwickler) ei­
PAGE eDossier 02.14 021
ne dieser beiden Rollen, darf diese
Person nicht gleichzeitig Teil des Ent­
wicklungsteams sein. Auch Pro­jekt­
manager oder Accounter könn­ten
die­se Rollen wahrnehmen. Es kommt
eher auf die Persönlichkeit an als
auf den fachlichen Hintergrund. Und
obwohl Konzepter häufig die Rolle
des POs und Projektmanager die des
­Scrum Masters einnehmen, sollte es
da keine Automatismen geben, weil
beide Rollen ein hohes Maß an Empa­
thie, Kommunikationsfähigkeit und Ausdrucke mit User
Stressresistenz erfordern. Storys sorgen für
Übersicht und ermög­-
lichen dem Team,
User Experience (UX) wird
aufkommende Fragen
gerade erst agil sofort zu diskutieren.
Ursprünglich kommen agile Prozesse Kleines Bild: User
aus der Softwareentwicklung. Die Fra­ Storys ver­ändern sich
ge, wie UX-Aspekte dabei berück- im Laufe des Projekts
022 PAGE eDossier 02.14 (Beitrag aus WEAVE 05.2013)
SO GELINGEN AGILE DIGITALPROJEKTE
UNTERSTÜTZEN SIE DAS TEAM
BEI DER EINFÜHRUNG!
1 6
BERATUNG EINHOLEN
Lassen Sie sich bei der Einfüh­
rung von Scrum und Co be­ra­
ten, sei es von erfahrenen Kol­
legen aus dem Unternehmen
oder durch einen externen Trainer. Dieser
sollte das Team nicht nur mit dem Hand­
werkszeug vertraut machen, sondern
ihm auch die agilen Werte nahe bringen.
2 12
METHODIK VERMITTELN
Bringen Sie alle Teammitglie­
der zum Start auf den gleichen
Wissensstand. Nur wenn alle
ein gemeinsames Verständnis
von den Abläufen haben, kann das Pro­
jekt rund laufen.
3
EIGENVERANTWORTUNG
KLAR MACHEN
Machen Sie deutlich, dass je­
der im Team die Verantwor­
tung für das Gesamtergebnis
hat. »Nach mir die Sintflut« oder gar
Schuldzuweisungen haben in agilen Pro­
jekten keinen Platz.
4
REGELWERK EINHALTEN
Verstehen Sie die Regeln von
Scrum und anderen agilen
Met­hoden nicht als Eineng­
ung, sondern nutzen Sie sie
zur Orientierung! Springen Sie ins kalte
Wasser und probieren Sie Scrum aus –
vermeiden Sie faule Kompromisse wie
»teilagil« oder »moderat agil«.
5
LERNAUFWAND
BERÜCKSICHTIGEN
Learning by Doing ist okay,
denn theoretisches Wissen
kann keine praktischen Erfah­
rungen ersetzen. Aber das bedeutet nicht,
dass Agil-Einsteiger den Prozess von heu­
te auf morgen beherrschen. Wer lernt,
braucht Zeit zur Reflexion, um die neuen
Erfahrungen zu verarbeiten.
SORGEN SIE FÜR GUTE BLEIBEN SIE AGIL!
­STARTBEDINGUNGEN!
11
DAS RICHTIGE USER STORYS
PROBLEM LÖSEN KLEINTEILIG
Hinterfragen Sie das Briefing FORMULIEREN
und betreiben Sie Research, User Storys sollten
statt mit dem Kopf durch die nicht zu umfangreich
Wand zu gehen. Nur so können Sie sicher sein, damit sich der Umsetzungsauf­
sein, dass das fertig entwickelte Produkt wand leichter und realistischer einschät­
dem Auftraggeber auch tatsächlich hilft. zen lässt. Ein Sprint sollte für eine User
7
Story reichen.
SPRINT NULL PLANEN
Überlegen Sie sich zu Beginn USER STORYS
von Sprint Null, welche Ergeb­ PRÄSENT HALTEN
nisse Sie benötigen, um mit Hängen Sie die User
dem eigentlichen Projekt an­ Storys an die Wände
fangen zu können. Was muss geklärt wer­ Ihres Projektraums,
den, welche Fragen müssen beantwortet sei­en es handgeschriebene Karteikar-
sein, welche Basics sind erforderlich? Da­ ten oder Ausdrucke aus einem Wiki.
durch nutzen Sie die Zeit sinnvoll und ­Dadurch weiß das Team jederzeit, wel­
schaffen ideale Startbedingun­gen. che Storys aktuell relevant sind, welche
8
Änderun­gen zuletzt besprochen wurden
ENGAGEMENT KLÄREN und welche Zusammenhänge zwischen
Teamwork ist in agilen Pro­ den je­wei­ligen Storys bestehen.
13
jekten noch wichtiger als in
Wasserfallprojekten. Nehmen GEMEINSAM
Sie daher nur Menschen ins ARBEITEN
Team auf, die sich auf agiles Arbeiten Diskutieren Sie Ideen
einlassen wollen. im Team, fragen Sie
9
Ih­re Kollegen aus an­
ROLLEN RICHTIG BESETZEN deren Disziplinen, und geben Sie selbst
Der Product Owner und der konstruktives Feedback – in agilen Pro­
Scrum Master tragen besonde­ zessen ist jeder Einzelne dafür verantwort­
re Verantwortung und stehen lich, das Beste aus dem Projekt zu machen.
14
unter hohem Druck. Fragen Sie
sich ehrlich, ob Sie eine solche Rolle wirk­ MEETINGDISZIPLIN
lich über­nehmen können. Lautet die EINHALTEN
Antwort »Nein«, achten Sie darauf, die »Stand up« zum täg­
richtigen Persönlichkeiten mit diesen lichen Austausch über
Jobs zu betrauen. den aktuellen Stand,
10
»Re­view« oder »Retrospektive« – jeder
PROJEKTRAUM im Team sollte die vorgesehenen Bespre­
EINRICHTEN chungstermine wahrnehmen.
15
Eine effiziente Kom­
munikation ist für RETROSPEKTIVEN
agile Projekte unver­ WIRKLICH
zichtbar. Daher sollten die Wege zwi­ DURCHFÜHREN
schen den Teammitgliedern kurz sein. Bisweilen fallen sie aus
Am besten versammeln Sie alle in einem Zeitgründen weg, aber
Raum, der ausreichend Platz zum Auf­ sie sind für die Motivation im Team eines
hängen von Artefak­ten wie User Storys der wichtigsten Meetings überhaupt: Das
oder ­Scrum Board bietet. Ideal sind au­ Team bespricht hier, was im abgeschlos­
ßerdem Whiteboards, damit das Team se­nen Sprint gut gelaufen ist und was es
schnell Ideen skizzieren kann. im nächsten verbessern will.

sichtigt werden, wurde jedoch aus­
geklammert – unsere Zunft ist aufs
Ausprobieren und auf Erfahrungs­
werte angewiesen. Beim Start des Pro­
jekts ist es wichtig, dem Briefing auf
den Grund zu gehen: Welches Problem
soll weswegen gelöst werden? In Brie­
fings fordern Auftraggeber eine App,
eine Facebook-Seite oder eine neue
Web­site mit allem Zipp und Zapp.
Aber ein reibungslos ablaufendes Pro­
jekt mit in sich stimmigem Konzept,
atemberaubendem Visual Design und
perfekt ausgefeilter technischer Um­
setzung nützt nichts, wenn sich am
Ende kein Nutzer für die Lösung inte­
ressiert. Am besten klären Sie die Fra­
ge nach dem richtigen Problem also
schon im Sprint Null. Sollte diese Fra­
ge schwer zu fassen sein, können Sie
ein separates Vorprojekt durchführen.
Scrum sieht vor, dass am Ende eines
Sprints der Nutzer selbst das Ergeb­
nis im Review Meeting bewertet. Prin­
zipiell ist es richtig, Nutzer in einem
Usability Test das Produkt testen zu
lassen – am besten nach jeder Iteration.
Im Projekt selbst ist es Aufgabe des
Konzepters, als der oft zitierte »An­
walt des Nutzers« die Nutzerbedürf­
nisse zu vertreten – gegebenenfalls
auch die mehrerer Zielgruppen mit­
hilfe von zuvor durchgeführtem User
Research und Personas. Außerdem
muss er die Informationsarchitektur
und konzeptionelle Fragen des Inter­
action und Interface Designs durch­
denken. Wie muss die Website oder
die App strukturiert sein? Wie laufen
Funktionen genau ab? Was passiert
im Falle eines Fehlers? Wann ist wel­
ches Element zu sehen? Die Antwor­
ten auf diese Fragen hält der Konzep­
ter in den Akzeptanzkriterien der ein­
zelnen User Storys fest und diskutiert
sie im Team. Übergreifende konzep­
tio­nelle Anforderungen werden bei
Scrum in der »Definition of Done«
»AGILES ARBEITEN ERFORDERT VON ALLEN
PROJEKTBETEILIGTEN DISZIPLIN UND
GEGEN­S EITIGEN RESPEKT. NIEMAND KANN
SAGEN: ›DAS IST NICHT MEIN JOB!‹«
Rainer Sax, freier User-Experience-Stratege und Service Designer, Hamburg
›››  @rainersax
hinterlegt, beispielsweise dass eine
ho­he Performanz wichtig ist und Ser­
veranfragen innerhalb einer bestimm­
ten Zeit beantwortet sein müssen.
Im Sinne der bereits erwähnten Ver­
antwortung aller für das Gesamtergeb­
nis sind auch die Kollegen aus ande­
ren Disziplinen gefordert – sie dürfen
und sollen den Konzepter hinterfra­
gen und bringen natürlich auch ihre
visuelle, redaktionelle oder techni­sche
Perspektive in das Projekt ein. Bei­
spiele hierfür sind der Designer, der
darauf hinweist, dass ein Element im
Raster bleiben muss und daher nicht
nach Belieben positioniert werden
kann, oder die Redakteurin, die ent­
sprechend ihrer Expertise zu beden­
ken gibt, dass Tex­te in Russisch oder
Finnisch länger laufen und dafür Platz
vorhanden sein muss.
Bei Aperto haben wir gute Erfah­
rungen damit gemacht, wenn die Kon­
zeption einen Sprint Vorsprung vor
Design und Development hat. Die Dis­
ziplinen können auch leicht versetzt
arbeiten. Es gibt keine starren Regeln:
In einem Projekt zur Entwicklung ei­
nes Wissensmanagementsys­tems et­
wa hatten Design und Konzept den­
selben Vorsprung. Stefan Freimark (ae)
SO FUNKTIONIERT SCRUM
// Bei Scrum arbeitet das Team in zwei- bis vierwö-
chigen Iterationen (»Sprints«). Ziel jeder Iteration ist
ein lauffähiges Produkt. Vor dem nächsten Sprint ent­
scheidet das Team neu, woran es als Nächstes arbei-
tet, um das Produkt zu verbessern. Um diese intensi­
ve und konzentrierte Arbeitsweise zu ermöglichen,
sind bestimmte »Artefakte« wie das Backlog (siehe
Glossar) oder das Burndown Chart sowie Abläufe und
Meetings vorgesehen. Die Regeln und Artefakte sol-
len die Kommunikation im Team fördern und den Fort-
schritt sichtbar machen. Eine ausführliche Einfüh-
rung bietet das Buch »Scrum in der Praxis« von Sven
Röpstorff und Robert Wischmann (siehe Seite 87).
PAGE eDossier 02.14 023
GLOSSAR
Akzeptanzkriterien: Sie sind Teil jeder
User Story. In ihnen legt das Team fest,
welche Punkte erfüllt sein müssen,
da­mit eine User Story als erfolgreich
implementiert gilt.
Backlog: In ihm sammelt das Projekt-
team User Storys. Es gibt zwei Arten
von Backlogs: Im Product Backlog ste­
hen alle Storys des gesamten Projekts,
die noch nicht umgesetzt wurden. Das
Sprint Backlog enthält dagegen die
User Storys, die das Team im aktuel­
len Sprint bearbeitet.
Burndown Chart: Es macht den Pro-
jektfortschritt sichtbar, denn es zeigt,
wie viele Storys noch zu erledigen sind.
Je weiter der Sprint fortgeschritten
ist, desto weniger Storys sind noch
umzusetzen - das Chart zeigt dann
eine abfallende Linie.
Retrospektive: Dies ist ein Meeting
zum Rück­blick auf den zurückliegen­
den Sprint. Was lief gut? Was soll-
ten wir verbessern? Die Retrospektive
dient dazu, aus den letzten Wochen
zu lernen, damit der kommende Sprint
besser verläuft.
Review Meeting: In ihm präsentiert das
Team die Ergebnisse des Sprints dem
Kunden. Das Ende eines Sprints ist
auch eine gute Gelegenheit, um einen
Usability Test durchzuführen.
Sprint: Eine Iteration von zwei bis vier
Wochen Dauer, in der das Team die vor­
ab vereinbarten User Storys umsetzt.
Sprint Null: Vor dem eigentlichen Pro-
jekt benötigen die verschiedenen Dis­
ziplinen Zeit, um nötige Grundlagen zu
schaf­fen. Beispielsweise definieren
die De­signer Farben und Anmutun­gen,
während die Technik das System auf-
setzt. Der Sprint Null sollte nicht we-
sentlich länger dauern als die späte­
ren Iterationen.
User Story: Eine Anforderung an das
Projekt, die immer nach diesem Sche-
ma formuliert ist: »Als (Rolle) möchte
ich (Handlung), damit (Nutzen).«
024 PAGE eDossier 02.14 (Beitrag aus WEAVE 05.2009)

Johannes Mainusch,
Vice President Operations bei Xing

// Es ist ein wolkenverhangener Som­
mernachmittag in Hamburg. Die Ent­
wick­ler bei XING haben die Jalousien
trotzdem halb heruntergelassen. Es
herrscht geschäftige Ruhe. Farbige
Zettel überall an den Wänden zeigen:
Hier wird agil gearbeitet. Knapp ein
Jahr ist es her, dass einige Mit­arbeiter
vor­schlu­gen, mit Scrum zu arbeiten.
Kurze Zeit später setzte ein Entwick­
lerteam die agile Projektmanagement-
Methode zum ersten Mal ein, um die
Event-Funktion zu realisieren, die En­
de 2008 live ging. Schon nach weni­
gen Wochen zeigte das Feature die er­
sten positiven Effekte. Heute – gut ein
Jahr später – entwickelt XING vie­le
ihrer neuen Produkte mit Scrum.
»Das hat drei wesentliche Vorteile für
uns: mehr Transparenz, weniger Ri­
siko und eine größere Flexibilität«,
sagt Johannes Mainusch, Vice Presi­
dent Ope­rations bei XING.
Wir sitzen im fünften Stock in ei­
nem gro­ßen Raum, in den durch zwei
Fens­ter­fron­ten Licht fällt. Heute mor­
erfolgreich verlaufen. Das war zur da­
maligen Zeit ein Durchbruch – aber
das reicht natürlich nicht. Immer noch
scheitern zwei Drittel aller IT-Vorha­
ben ganz oder teilweise! Scrum wird
sicherlich auch nicht der Weisheit
letzter Schluss sein, denn um wirk­
lich gut zu sein, muss man seine Pro­
zesse permanent weiterentwickeln.
Doch mit agilen Methoden wie Scrum
könnten an die 60 Prozent aller IT-
Projekte erfolgreich sein.«
Die Stärken von Scrum liegen in sei­
ner Vorgehensweise: Scrum stellt das
Magische Dreieck des Projektmanage­
ments aus Anforderungen, Budget und
Zeit auf den Kopf: Die Zeit ist die rele­
vante Vorgabe. Genauer gesagt die so
genannten Sprints, also Zeiteinheiten
von rund ein bis vier Wochen, in de­
nen eine bestimmte Anzahl von Auf­
gaben erledigt sein muss. Um diese
Zeiteinheiten mit Aufgaben zu bestü­
cken, zerlegt der Scrum Master das
gesamte Projekt gleich zu Beginn in

ZETTELS TRAUM
Scrum ist derzeit schwer angesagt, denn es verspricht nicht nur
mehr Spaß bei der Arbeit, sondern auch mehr Erfolg bei
der IT-Entwicklung. Wie das in der Praxis aussieht, zeigt ein
Blick hinter die Kulissen der XING AG in Hamburg

gen fand hier das Company Meeting
statt, wie jede Woche. Es herrscht ei­
ne Art Ruhe nach dem Sturm: CI-ge­
recht grüne Kissen liegen überall über
die ebenfalls CI-gerecht weißen Pol­
sterbänke verstreut.
Mainusch lehnt sich vor und be­
scheinigt agilem Projektmanagement
im Allgemeinen und Scrum im Be­
sonderen großes Potenzial: »Mit dem
Wasserfallmodell hat man es bereits
geschafft, dass schätzungsweise im­
merhin 30 Prozent aller IT-Projekte
möglichst kleine, unabhängige Ein­
zelteile, Backlog Items genannt. Las­
sen sich die Items nicht im Rahmen
eines Sprints realisieren, teilt er sie
wieder in kleinere Abschnitte auf. Das
Ergebnis eines Sprints ist aber in je­
dem Fall ein fertiges – und das heißt
hier: ein releasefähiges – Teilprodukt
des Gesamtvorhabens.
Genau diese Aufteilung eines Ge­
samtprojekts sorgt für erheblich mehr
Transparenz in der Entwicklung, als
dies bei klassischen IT-Entwicklungs­
methoden der Fall ist – und damit
eben auch dafür, dass Risiken sich
auf diese Weise wesentlich früher er­
kennen lassen. »Ein sehr erfahrener
Projektmanager wird dies auch bei
den klassischen Methoden tun«, gibt
Mainusch zu Bedenken. Doch kommt
er bei Scrum schlicht und ergreifend
nicht darum herum.
Nicht selten tendieren klassische
Projektmanager außerdem eher dazu,
an langfristigen Plänen festzuhalten.
»Deshalb steht beim klassischen Pro­

jektmanagement die Ampel häufig so
lan­ge auf Grün, bis der erste Meilen­
stein nicht eingehalten wird – an­
schlie­ßend springt sie auf Gelb«, sagt
Mainusch. »In Wirklichkeit ist das
Projekt allerdings in vielen Fällen zu
diesem Zeitpunkt bereits eindeutig
gescheitert.«
In täglichen Scrum Meetings berich­
ten alle Teammitglieder, was sie am
vergangenen Tag erledigt haben, was
für den kommenden Tag geplant ist,
Mark Weber,
Projektmanager bei Xing
Fotos: Sabine Ahrens
und auch, welche möglichen Prob­
leme es gab oder geben könnte. Der
Scrum Master ist dafür zuständig, die­
se Hindernisse aus dem Weg zu räu­
men. Am Ende eines jeden Sprints
findet darüber hinaus ein Retrospec­
tive Meeting statt, in dem der ver­
gangene Sprint zwecks methodischer
Verbesserung in einem Fazit beurteilt
und der kommende Sprint gecastet
wird. Zu diesen Meetings kann sich
jeder beim Scrum Master anmelden –
also natürlich auch die Manager.
PAGE eDossier 02.14 025
GLOSSAR
BACKLOG ITEMS Bei Scrum zergliedert man ein Gesamt­
vorhaben in kleine, voneinander unabhängige Einzel­auf­
gaben – die Backlog Items.
BURNDOWN CHART Dieses Diagramm zeigt, wie viele der
während eines Sprints abzuarbeitenden Story Points bereits
erledigt sind, visualisiert also zum einen den Fortschritt
des Projekts, motiviert aber zum anderen die Teammitglieder
auch durch den direkt sichtbaren Erfolg.
DAILY SCRUM MEETINGS Bei diesen täglichen Meetings
trifft sich das Team, um zu berichten, welche Aufgaben
am vergangenen Tag erledigt wurden, welche auf der
aktuellen Tagesordnung stehen und welche Hindernis­se
aufgetaucht sind oder auftauchen könnten.
INCREMENT Das fertige Zwischenprodukt am Ende eines jeden
Sprints.
PRODUCT BACKLOG Das Product Backlog beschreibt das
Endprodukt. Jeder im Team kann Anforderungen einbrin-gen
– allerdings entscheidet der Product Owner, welche Priorität
die einzelnen Aufgaben haben und im nächsten Sprint
schwerpunktmäßig abgearbeitet werden.
PRODUCT OWNER Er vertritt den Auftraggeber und ist für die
Priorisierung der Aufgaben und Anforderungen – also
für inhaltliche und fachliche Entscheidungen – zuständig.
SCRUM (ENGL. GEDRÄNGE) Agile Projektmanagement-Metho­
de, die Ken Schwaber, Jeff Sutherland und Mike Beedle
ausgehend von den Ideen der Lean Production
bei Toyota entwickelten. Wie diese soll auch Scrum durch
einen möglichst geringen Aufwand an Verwaltung und
Organisation eine schlanke Produktion garantieren.
›››  agilemanifesto.org
SCRUM MASTER Er hat die Rolle eines Trainers und soll
vor allem dafür sorgen, dass das Team ohne Hindernisse
arbeiten kann und das Scrum-Verfahren einhält. Im
Unterschied zu einem klassischen Projektleiter ist der Scrum
Master nicht für die inhaltliche Aufgabenvertei-
lung zuständig. Seit 2003 kann man sich als Scrum
Master zertifizieren lassen.
SPRINT Die Projektarbeit wird bei Scrum in Zeitabschnitte von
ein bis vier Wochen aufgeteilt, die Sprints. Anders als bei
herkömmlichen Projektmanagement-Methoden gibt der
Sprint den Arbeitstakt vor – Anforderungen und Budget
orientieren sich an ihm. Der Name ist nicht zufällig gewählt:
Das Team soll die gesteckten Ziele, also das Increment,
möglichst schnell und konzentriert erreichen.
SPRINT BACKLOG Enthält alle Aufgaben, die während
eines Sprints zu erledigen sind.
SPRINT REVIEW MEETING Zur permanenten Prozess­opti­-
mie­rung trifft sich ein Team am Ende eines Sprints, um
Probleme, Fehleinschätzungen, Erkenntnisse und deren
Bedeutung für zukünftige Sprints zu erörtern.
STORY POINTS Mit ihm bewertet das Team, wie umfangreich
die Entwicklung eines bestimmten Backlog Items ist.
Die Höhe der Punktzahl entscheidet, wie viele Items pro
Sprint bearbeitet werden.
USER STORY Produkte und Backlog Items werden bei Scrum
durch User Stories beschrieben. Dabei geht es nicht um eine
technische Definition, sondern darum festzuhalten, was der
User mit einer bestimmten Funktion et cetera tun will.
026 PAGE eDossier 02.14 (Beitrag aus WEAVE 05.2009)

Eben dieser Austausch war es, der

XING schon nach wenigen Wochen
überzeugte: Erstmals konnten die
Entwick­ler schon sehr früh die Früch­
te ihrer Arbeit zeigen – und das Ma­
nagement Einblick in den Fortschritt
des Projekts nehmen.
Scrum stärkt somit nicht nur den
Teamgeist, sondern sorgt auch für
Flexibilität: »Wir können jederzeit auf
neue Situationen reagieren«, erklärt
Mainusch. Zwar legt XING normaler­
weise die Aufgaben für zwei bis drei
Sprints im Voraus fest und entwickelt
natürlich auch eine langfristige Visi­
on, wo man mit den jeweiligen Tools
hinmöchte. Aber: »Der Businesswert
schwankt von Funktion zu Funktion
teilweise so stark, dass es keinen Sinn
macht, seine Zeit in eine detaillierte
Zukunftsplanung zu stecken«, erläu­
tert Mark Weber, Projektmanager bei
XING. Stattdessen lassen sich zu Be­
ginn jedes Sprints spontan neue Auf­
gaben ansetzen. Theoretisch könnte

CASE STUDY: WIE XING MIT SCRUM ENTWICKELT

// Aus einer Reihe neuer Ideen, mit
denen die Plattform XING weiter­
entwickelt und optimiert werden
sollten, stach im vergange­nen Jahr
das Feature Unternehmensprofi­le
heraus. Mit diesem neuen Tool sol­
len sich nicht nur Einzelpersonen,
mark weber Petra Schwenk Janine de jongh Tobias Geyer
sondern auch Firmen auf XING dar­ Project Manager Product Manager Manager Quality Manager Quality
stellen können. Assurance Assurance
Im Oktober 2008 führte XING
gemeinsam mit einigen Anwen­
dern erste Workshops durch und
testete die Usability anhand eines
Klick-Prototypen. Bis Ende Novem­
ber entwickelte das Unternehmen
aus diesen Analysen dann ein ini­
tiales Backlog.
Jenny lemnitz horaci Cuevas DAvid palacios abel almazán
Dabei handelt es sich im Prinzip Manager Engineering Manager Engineering Manager Engineering fernández
um eine Liste, die nach Wissens­ Barcelona Barcelona Manager Engineering
regionen geordnet ist und jedes Barcelona
ein­zelne Item als User Story be­
schreibt. Eine User Sory schildert, 1 TEAM
wie ein Anwender die unterschied­ Ein Team besteht bei XING in der Regel aus acht Personen: ein Scrum Master (Mark Weber), ein
lichen Funktionen nutzt. Diese Be­ Product Owner (Petra Schwenk), jeweils ein Mitarbeiter aus den Bereichen Qualitäts­sicherung
schreibungen ergänzte XING zum und User Experience sowie drei bis vier Programmierer. Diese Teamgröße hat sich für XING
als optimal erwiesen – zumal Scrum speziell für kleine Teams ausgelegt ist. In diesem Fall
Teil um visuelle Screenshot Dum­ stellte die Zusammenarbeit eine besondere Herausforderung dar, da drei Pro­grammierer in
mys, um die interne Kommunika­ Barcelona und einer in Hamburg saß. Um die Zusammenarbeit zu erleichtern, startete
tion zu erleichtern. man mit dreiwöchigen Sprints und wechselte später in einen zweiwöchigen Turnus.

der Business Owner das Gesamtpro­
jekt dann sogar abbrechen, ohne dass
ungetesteter Code auf irgendwelchen
Servern herumliegt, das Gesamtpro­
jekt scheitert oder Investitionen in
den Sand gesetzt werden – denn sämt­
liche Teilprodukte sind am Ende eines
Sprints, wie gesagt, releasefähig.
Praktisch nutzt XING diese Flexi­
bilität, um näher an den Wünschen
ihrer Anwender entwickeln zu kön­
nen: Mit der Einführung von Scrum
entschied sich XING im vergangenen
Herbst nämlich auch für die soge­
nannte Ship-it!-Strategie. Das bedeu­
tet, dass das Unternehmen neue Fea­
tures bereits in der Betaphase veröf­
fentlicht, um sie via Mitglieder-Feed­
back weiterzuentwickeln.
Ein Beispiel für ein solches Ship it! ist
das Feature Unternehmensprofile (sie­
he Seite 52 ff.). Als XIN­­G das Tool im
April dieses Jahres in einer ersten Be­
ta­ver­sion launchte, wertete es ledig­
2 ESTIMATION MEETING UND SPRINT PLANNING
Zunächst priorisierte der Project Owner die User Stories. Um die Menge der pro Sprint abzuarbeitenden
Backlog Items festzulegen, findet ein Estimation Meeting statt, bei dem das Planning Poker eine besondere
Rolle spielt: Der Product Owner stellt ein Backlog Item nach dem anderen vor, bis das gesamte Team diese
verstanden hat. Dann einigt man sich auf ein Referenz-Item, um den Entwicklungsauf­wand jedes Backlog
Items zu bestimmen. Mit den Planning-Pokerkarten bewerten die Teammitglieder in verdeckten Abstimmungs-
verfahren, als wie aufwendig sie die Entwicklung des jeweiligen Items einschätzen. Danach diskutiert das
Team in einem vorgegebenen Zeitrahmen (Timebox-Prinzip) und stimmt so lange ab, bis ein einheitliches
Urteil getroffen ist. Jedes Item erhält auf diese Weise eine bestimmte Anzahl Story Points. Während jedes
Sprints arbeitet das Team eine bestimmte Anzahl an Story Points ab – kann also im Umkehrschluss ermitteln,
welche Tasks erledigt werden können.
PAGE eDossier 02.14 027
lich alle Einträge über Arbeitgeber aus
sämt­lichen Nutzerprofilen aus und
erzeugte ab fünf gleichlautenden Ein­
trägen automatisch ein Unterneh­
mens­profil. Mittlerweile können sich
auch kleinere Unternehmen auf XING
darstellen. Das heißt, es gab zunächst
lediglich ein Tool in einem relativ ru­
dimentären Entwicklungsstadium –
aber es funktionierte.
Parallel zu dieser Maßnahme stell­
te XING ein umfangreiches Feedback-
Tool bereit, über das die Nutzer nicht
nur Kritik und Wünsche äußern, son­
dern sich auch einen Überblick darü­
ber verschaffen konnten, welche
Punk­te den anderen Usern wichtig
waren – und was sich davon bei XING
gerade in der Umsetzung befand.
Denn XING nutzte genau diese Rück­
meldungen, um weitere Sprint Back­
logs zu casten und Prioritäten zu set­
zen. »Wir hatten natürlich auch schon
eine ganze Reihe von Ideen, was wir
als Nächstes entwickeln wollten –
aber das Feedback zeigte uns so ein­
deutig, was als Nächstes in Angriff
genommen werden sollte, wie wir es
ansonsten wahrscheinlich nicht ge­
dacht hätten«, berichtet Mark Weber.
Dass es dabei auch harsche Kritik
vonseiten der Nutzer gab, war zu er­
warten. »Das war eben die große He­r­
ausforderung für das Management«,
räumt Johannes Mainusch ein. Doch
auch nach längerem Überlegen lässt
das ihn und seine Mitarbeiter nicht
an der grundsätzlichen Entschei­
dung zweifeln, denn: »Das ist Agilität
in Reinkultur«, erklärt er selbstbe­
wusst. Natürlich könne man auch oh­
ne solch einen gewagten Schritt ein
bisschen mit agilen Elementen he­
rumspielen – XING selbst hat dies vor
der Einführung von Scrum ja schließ­
lich auch getan. »Doch wenn sich das
Management nicht für diese Öffnung
entscheidet, ist es eben auch nicht
agil«, sagt Mainusch und klingt dabei
irgendwie ziemlich stolz auf die Ent­
wicklung des Unternehmens.
Und das kann er wirklich sein an
die­sem verhangenen Sommernach­
mittag. Denn auch wenn Schlagwör­
ter wie Schwarm­intelligenz, Crowd
Sourcing oder das Cluetrain-Manifest
heu­te gerne bemüht werden, erfordert
es immer noch reichlich Mut, diese
Werte und Überzeugungen tatsäch­
lich in der Praxis zu leben.  ik
 028 PAGE eDossier 02.14 (Beitrag aus WEAVE 05.2009)

3 SCRUMY UND SPRINTS

Üblicherweise notiert der Scrum Master die
für einen Sprint festgelegten Tasks auf
farbigen Zetteln und klebt sie an der Wand
in die Kategorie »Open«. Um die Kollegen
in Barcelona einzubinden, nutzte das
XING-Team auch die Browser-Anwendung
Scrumy Pro, eine digitale Scrum-Wand.
Sobald ein Teammitglied sich an die
Bear-beitung eines Tasks macht, hängt er
den Zettel in den Bereich »In Progress«.
Ist die Aufgabe erledigt, rückt er ihn in den
Abschnitt »Done«. Ein Burndown Chart
zeigt darüber hinaus pro Sprint, wie viele
Story Points bereits erledigt sind.
Am Ende eines Sprints müssen alle Story
Points abgearbeitet sein. Fertig – oder
auch »done« – ist ein Produkt aber erst,
wenn es veröffentlicht ist, also auch
die Quali­täts­sicherung und die User
Experience ihre Aufgaben erledigt haben.

Goal: Social Networking 4 SPRINT-HISTORIE UND -RETROSPEKTIVE

Sprint #1

Sprint #2

Sprint #3

Sprint #4

Sprint #5

Beta Release Sprint #6

Sprint #7

Sprint #8

Standards
Start/End: 14.05.–29.05.
Velocity: 34/34
Selected Backlog:
1. Visitors of my profile
2. Employee Listing: add contact,
send message, bookmark and
show
carreer level
3. On Demand Creation:
for CPs less 4 employees
4. Track visits on single
companies
Sprint für Sprint arbeitete das Team nun die verschiedenen Backlog
Items ab. Wichtig: Nach jedem Sprint findet ein Retrospective
Meeting statt, bei dem auch methodische Probleme und Verbesse-
rungsmöglichkeiten diskutiert werden. So ergänzte XING Scrum
beispielsweise um das Kanban-Verfahren. Der Grund: Scrum
funktioniert zwar bei allen Neuentwicklungen hervorragend, doch
sobald bei einem bereits veröffentlichten Produkt ein Bug
auftaucht, der sofort behoben werden soll, droht der ganze Sprint
durcheinanderzugeraten, da sich das Team ja schon auf eine
bestimmte Anzahl an Tasks festgelegt hatte. So entschied man
sich, bei der Maintenance dem Kanban-Prinzip zu folgen
und immer nur zwei Items auf einmal abzuarbeiten. Kommt ein
unerwarteter Bug dazu, hat er Vorrang.

26.11.08 23.04.09 to be continued...

5 DAS RELEASE
Fünf Monate und sechs Sprints später war es so weit: Die erste
Unternehmensprofil-Version konnte veröffentlicht werden (rechts).
Damals wertete das Feature automatisch die Einträge aller
XING-Mitglieder über ihre Arbeitgeber aus und erstellte daraus
automatisch Unternehmensprofile. Das Neue bei diesem Release
war, dass XING erstmals auch ein spezielles Feed­back-Tool namens
User Voice einband, über das XING-Mitglieder genaue Rückmel-
dungen geben können (unten). Die Ideen und Vorschläge analysierte
das Team danach und definierte so die Tasks für die kommenden
Sprints. So stellte sich beispielsweise schnell heraus, dass
es notwendig war, die Informationen aus XING-Profilen auch dann
zu einem Unternehmensprofil zusammenzubinden, wenn die
Mitglieder die Firma unterschiedlich beschrieben hatten.
Inspiration pur!

Gleich
zugreifen !

PAGE präsentiert die entscheidenden Trends

in Sachen Konzeption, Gestaltung & Technik.
Jetzt zugreifen: shop.page-online.de/page-mini