Mein erstes SCRUM Projekt. Und jetzt?

Posted on Okt 28, 2013 in Buzzwords, Workflow
Mein erstes SCRUM Projekt. Und jetzt?

SCRUM ist gerade eins der heißesten Buzz-Words. SCRUM soll der Heilsbringer für die Werbung sein. SCRUM soll effektiv und Geld sparend sein. Und SCRUM ist angeblich die Zukunft. Aber was ist SCRUM eigentlich? Und wie ist es, damit zu arbeiten?

Erstmal eine Definition: Scrum (englisch für „Gedränge“) ist ein agiles Projektmanaging-Modell für die Software-Entwicklung.
Es gibt dem Team einen beweglichen Rahmen, der ständig überprüft und angepasst wird. Angepasst vom Team – nicht etwa vom Kunden. Es geht hier nicht darum, dass der Kunde mit dem Team „wünsch dir was“ spielt und ständig seine Meinung in Bezug auf das Projekt und seine Umsetzung ändern kann. Sondern das Team bestimmt agil wie es das Projekt realisiert. Dazu komme ich gleich genauer.

Woher kommt der Begriff? Aus dem Rugby! Diese Formation heißt exakt so – funktioniert nur ein bisschen anders.

 Scrum tauchte in einer Studie 1986 das erste Mal auf und wurde 1993 als Arbeitsmodell von Jeff Sutherland vorgestellt.

Wenn ihr das Wort bei Google eingebt, findet ihr endlos viele Artikel dazu. Diesen Artikel (inklusive des Bildes unten) fand ich mit am hilfreichsten.
Ich habe vorher auch einiges gelesen, aber das hilft alles nicht wirklich, wenn man nicht einmal mit jemanden gesprochen hat, der in einem Scrum-Prozess gearbeitet hat oder – noch besser – selbst in einem arbeitet.

Scrum

 

Also was genau passiert da, wenn man als Online-Team für eine Webseite oder App im Scrum-Prozess arbeitet?

Bildschirmfoto 2013-10-28 um 14.44.14

Regel Nummer 1: Alle Gewerke bilden das Team. Durchgehend. Konzept, Design, Frontend und Backend.
Die beste Grundlage überhaupt und es spart so unfassbar viel Zeit und Geld. Arbeitet man einmal mit allen Gewerken in einem Raum, hat man nie wieder bei einem komplexen Projekt Bock auf das Wasserfall-Prinzip (dazu auch später mehr ).

Regel Nummer 2: Alle sitzen in einem Raum. Das gesamte Projekt durch.
Wie oft wurde schon versucht, durch Raumpläne Teams zu bilden und irgendwie hat es nie funktioniert. Auch wenn die Leute an einem Tisch sitzen, sprechen sie dennoch nicht über „das Projekt“. Nein, sie brauchen dazu die Grundlagen von etwas wie Scrum, damit die Kommunikation funktioniert.

e34d37c9af934d7016d91431cf2936a3

Regel Nummer 3: Zusätzlich zum Team gibt es zwei weitere Rollen: Den Scrum-Master, welcher hilft den Prozess einzuhalten, Hindernisse aus dem Weg räumt und neutral „für Ordnung“ sorgt.
Und den „Project-Owner“ a.k.a. PO a.k.a. der Kunde. Meist in der Werbung besetzt von technischer Beratung und Kundenberatung. Der PO ersetzt die Meinung des Kunden und handelt in seinem Interesse, ohne das der Kunde anwesend sein muss.

Regel Nummer 4: Jeden Arbeitsmorgen gibt es das „Daily“. Alle (Team + Master + PO) stehen (denn wer sitzt lenkt sich mit anderem Gedödel ab) für höchstens 15 Minuten zusammen und jedes Team-Mitglied beantwortet 3 Fragen:

– Was habe ich gestern gemacht?
– Was mache ich heute?
– Werde ich durch etwas behindert?

Was bedeutet dieses Meeting? JEDER im Team weiß IMMER was alle anderen gerade machen. Ergo: Keiner kocht  für Tage allein vor sich hin sein Süppchen und rennt kopflos in die falsche Richtung.

Regel Nummer 5: Das Team legt selbst seine Arbeitspakete in sogenannten Sprints fest. Ein Sprint geht 1-4 Wochen lang. Bei uns beispielsweise dauerte ein Sprint 2 Wochen lang, was gut funktionierte.

Regel Nummer 6: Die Sprint-Planung wird „gepokert“. Ja ich weiß, nach all den anderen seltsamen Begriffen klingt es jetzt so richtig gaga.

Aber ich erklär auch das kurz: Während der Sprint-Planung (welche immer locker 4 Stunden dauert) wird genau besprochen was zu tun ist und in sogenannte Tasks filetiert.
Diese Tasks sind auch immer gleichzeitig Aufgaben für alle Gewerke.
Deshalb „pokern“ alle Gewerke um den Aufwand hinter diesem Task.

CrispPlanningPokerDeck

Pokern heißt, jeder hat Karten vor sich von 0-100 und schätzt damit, wie aufwändig die jeweilige Aufgabe ist.

Grundlage dieser Schätzung in einem Onlineprojekt wäre beispielsweise der klassische Teaser, welcher in der Arbeit aller Gewerke (er wird konzipiert, designt und in Front- und Backend programmiert) eine 5 bekommt.

Die Aufgabe wird also ganz genau besprochen, damit jeder weiß was in etwa da zu tun ist. Und dann wählt jeder verdeckt eine Karte, mit der Menge an Aufwand, die er schätzt. Alle halten diese Karten hoch.

Ist der Wert ähnlich, wird sich direkt auf einen Wert geeinigt. Sind die Werte weit auseinander, erklärt der niedrigste und höchste, wieso er diesen Aufwand schätzt. Dann wird noch mal gepokert.

Und so werden alle Tasks im Sprint geschätzt: Erstellung der Navigation, eines Formulars, einer Unterseite… Bei Sprint-Start wird festgelegt, wieviel man an Arbeit an einer Zahl schaffen kann. Addiert man nun alle Schätzungen der Pakete, kann man sich nicht zuviel vornehmen und weiß immer, wo man gerade steht.

Was ist der Nutzen? Ganz einfach: Jeder weiß genau, was er zu tun hat und was vor allem was sein Job im Geflecht dieses Projektes ist. Er weiß auch, dass die anderen nicht weiterarbeiten können, wenn er seinen Job nicht macht. Und andersherum.

physical_scrum_board2

Regel Nummer 7: Der Sprint wird mit einem Tool digital begleitet, das sogenannte Backlog.
Hier legt der PO die Anforderungen für das Projekt fest (Was muss gemacht werden?) und aus diesen Anforderungen wiederum werden die Tasks für den Sprint + das Pokern aufgebaut.
Macht man nun seinen Job im Sprint, sucht man sich sein Tasks im Backlog raus, weist es sich selbst zu und stellt es auf  „in Progress„. (Siehe oben ein analoges Scrumboard)
Ist man damit durch, wird es dem nächsten im Team zugewiesen oder – wenn alle der Meinung sind, dass dieses Task erledigt ist – wird es auf „done“ gestellt.
So arbeitet man sich dann durch den gesamten Sprint – und auch dies immer im Team.

Regel Nummer 8: Wird der Sprint abgeschlossen, stellen alle Team-Mitglieder im Sprint-Review die erledigten Tasks dem Project-Owner vor, welcher diese dann – im Namen des Kunden – abnimmt. Darauf folgt dann die Retroperspektive, bei welcher analysiert wird, was an dem Sprint gut und schlecht war und was man beim nächsten Sprint beachten sollte.

Dieses System wird solange durchgezogen, bis das gesamte Projekt fertig ist. Das ist Scrum im Schnelldurchlauf.

 

So. Als ich das alles das erste Mal erzählt bekommen habe, klang es spannend, aber für mich echt ganz schön nerdig und kaum vorstell- und durchführbar. (ja, für mich klang es nerdig!)

Aber in dem hinter mir liegenden Projekt habe ich gelernt, dass es total funktioniert. Und ich gehe noch weiter:

Es ist für mich die Zukunft der Online-Werbung. Vielleicht sogar die Zukunft der Werbung selbst.

Und da zitiere ich wieder den Wasserfall, der total überholt ist. Der Gedanke, dass bei einem komplexen Projekt (ich rede jetzt nicht von einer popeligen Landingpage) sich erst ein Konzeptioner (also so jemand wie ich) alleine in seinem Kämmerlein ein Wirefrämchen-Gelöt braut – ohne vorher so wirklich mit Front- oder Backend gesprochen zu haben – weil in den meisten Fällen diese gar nicht in der Agentur sitzen  sondern extern dazugekauft werden.
Das dann bestimmt eine tolle Struktur und gute Usability hat, aber „geht das alles so?“
Keiner weiß es so genau.

Und dann kommt der Designer, ohne meist so wirklich an Usability und Programmierung zu denken, sondern vor allem an seinen Design-Anspruch.

Danach kriegt es der Front-Ender in die Finger und flucht über den Kram, den die anderen verzapft haben. Nun ist das Timing wahrscheinlich auch schon schrecklich knapp und die Kohle auch bald alle.
Also muss der Backender ganz ganz schnell arbeiten und damit rechnen, dass keiner für ihn vorgedacht hat. Uff. Das klingt irgendwie idiotisch, oder? Aber so wird’s ja immer gemacht!

Wie war das also in unserem Scrum-Büro? Wir hatten tatsächlich den Deal, dass so gut wie alle immer angesprochen werden oder dazu geholt, wenn ein Teil des Projektes besprochen wird.

Damit es hinterher kein „Davon wusste ich nix!“ gibt.
Das funktionierte total schnell obwohl wir größtenteils noch nie miteinander zusammengearbeitet haben (ich war ja sowieso als Freelancer an Bord und kannte niemanden) und es wurde immer mitbedacht, welche Auswirkung etwas auf die anderen Gewerke hat. Klingt wie Utopia, aber es klappt, weil wir alle durch Scrum den Rahmen haben.

Mir persönlich hat es unfassbar geholfen, alles gemeinsam zu durchdenken.
Ich meine: es ist klar, dass im Team fähige Leute sitzen müssen. Die auch Bock darauf haben, eine Qualität zu produzieren und viel zu reden. Sich weiter zu entwickeln. Und ich bin mir sicher, dass auch jedes Teammitglied an dieser Zusammenarbeit wächst.

Warum ist Scrum vor allem für mich als Konzeptionerin großartig? Es ist eine Sache, Fragen mal in einem Meeting oder per Telefon zu klären oder sich einfach nur dafür umdrehen zu müssen, um zu wissen ob etwas für das Backend besser funktioniert, weil es Variante B und nicht A ist.
Und gemeinsam mit Design und Frontend die optimalste Form einer mobilen Navigation zu finden, die für alle funktioniert. Ich habe echt dazu gelernt. Und wenn ich es mir wünschen könnte, würde ich alle großen Projekte so machen.

tumblr_msib2rvyvi1r5dfr3o1_500

Was hat nun die Agentur davon? Es heißt ja immer, dass ein Scrum-Projekt den Arbeitsprozess agil macht. Weiter oben schrieb ich ja schon, dass dies nicht bedeutet, dass der Kunde ständig seine Meinung ändern kann. Sondern die Agentur und das Team kann flexibel auf Ereignisse und Veränderungen reagieren.

Wie es immer mal passiert: Es Kommt eine neue Information dazu. Oder  irgendwas wird plötzlich weggenommen… Also jetzt nichts kleines, sondern schon von großer Bedeutung.
Wäre der Konzeptioner im Wasserfall alleine losgelaufen, würde dies bedeuten, dass  neu konzipiert werden muss und der Designer jetzt mittendrin auch wieder was verändern muss. Dann fehlt erst recht die Kohle am Ende, da der Front- und Backender ja noch gar nicht anfangen konnte. Und nein, das ist kein Vorteil, denn wer weiß, ob die neue Konzeption dann auch für die Programmierung ok ist?
Ist man im Scrum kann man den Karren noch locker lenken, bevor er in den Dreck fährt.
Das sollte jeder Agentur zu denken aufgeben.

Was passiert nun als nächstes? Ich weiß, dass schon einige Agenturen SCRUM testen.. aber es ist noch die Ausnahme. Es sind Versuchballons. Das übliche Geschäft wird davon kaum berührt.
Es wird sicher noch einiges an Zeit dauern, bis SCRUM direkt bei der Projektplanung bedacht wird, mehr Mitarbeiter und Freelancer Erfahrung damit machen und es irgendwann total normal ist, seine Arbeit zu pokern und sich als Scrum Master zertifizieren zu lassen.

Ich freue mich schon auf das nächste Projekt, bei dem ich wieder so arbeiten kann.

Habt ihr schon Erfahrungen mit SCRUM gemacht? Wäre sehr gespannt auf eure Meinung!

 

10 Comments

  1. Jan
    28. Oktober 2013

    Hi Rebecca,
    gute Zusammenfassung der wichtigsten Regeln. Ich habe grade auch ein großes Prohekt gemacht, wo die Programmierung mit Scrum gearbeitet hat. Dort macht es auch am meisten Sinn. Doch durch die Sprintzyklen hat diese Arbeitsweise auch auf die Arbeit der Kreativagentur abgefärbt. Wir waren angehalten, unsere User Stories (Konzept, Layout, Kundenfreigaben) passend zu den Sprints zu liefern. Das erfoldert einen gut organisierten PM und ein Team, welches sich den Sprints anpasst. Etwas „verschult“ das Ganze, aber auch effizient.

    Für digitale Kreativagenturen bietet sich meiner Meinung nach für das Gesamtprojekt eine Mischung von Wasserfall (GK und FK) und Programmierung (Feinspezifizierung dann agil) an. Aber natürlich sollte schon innerhalb des GK eine enge Abstimmung mit der IT des Kunden und Proggies stattfinden, um frühzeitig einen Realitätscheck zu haben.

    Zum Trend: Ich beobachte das viele Agenturen bereits erfolgreich Elemente von Kanban oder Scrum benutzen, nur das es nicht deren Begriffen bedarf. Daily meetings morgens und/oder auch abends hatten wir zu Spitzenzeiten auf vodafone auch, dies ist einfach ein PM-Tool, um Struktur in komplexe Projekt zu bekommen.

    Sprint-Planung: Nichts anderes machen wir alle in unserer wöchentlichen Kapa-Planung.
    Bei Scrum ist dies nur noch kleinteiliger, da man es je Userstory innerhalb eines Projektes aufteilt. Dies kann ein erfahrener PM aber auch gut alleine machen. Wenn es aber ein Großprojekt (Relaunch, international) ist, ist es natürlich super, wenn der PM zusätzlich noch auf einen Requirements Engineer zur Seite hat…

    Wie Du aber richtig schriebst, bei kleinen/mittleren Projekten (NL, Banner-Flight, Landingpages, CRM Konzepte) ist die agile Arbeitsweise nicht besonders zielführend. Bei komplexen Großprojekten führt heute meist kein Weg daran vorbei, weil die IT des Kunden oft so arbeite bzw. dies grade einführt und eine ähnliche Arbeitsweise auch von Ihren digitalen Dienstleistern erwartet.

    Scrum-Master Kurs: Wenn Du auf Unternehmensseite arbeitest, bezahlt der Arbeitgeber i.d.R. eine solche Weiterbildungsmaßnahme. Als Angesteller einer Werbeagentur zahlt dir dies allerdings keiner….

    Agile Grüße 😉
    Jan

    Reply
    • rebeccanoeh
      28. Oktober 2013

      Da hast du definitiv recht: die PMs und somit POs müssen einen wirklich guten Job machen und natürlich müssen die Team-Mitglieder mit dem Prozess mitgehen.
      Ich bin gespannt, wie sich das Thema entwickelt.. schön zu hören, dass es auch anderen Agenturen schon <2sprießt<2 😉

      Reply
  2. Chris
    30. Oktober 2013

    „…schön zu hören, dass es auch anderen Agenturen schon sprießt“

    Äh… „schon“? Ich musste in der Tat mehrfach auf das Datum dieses Blogeintrages schauen, um mich zu vergewissern, keinen „Knick in der Optik“ zu haben. Scrum das aktuellste, heisseste Buzzword? Was ist das hier? Pseudoaktuelles IT-Geschreibsel? Fakt ist vielmehr, dass Scrum bereits seit einigen Jahren existiert. Dass es vielfach ausprobiert und wieder verworfen wurde, weil es oftmals eben doch in ein „Wünsch Dir was“ des Kunden ausartet. Aber toll, dass es nochmal zu einem textuellen Lobgesang gereicht hat. (Und nebenbei: ich arbeite in einer Agentur, die Scrum – oder genauer gesagt Kanban – bereits seit geraumer Zeit praktiziert und aus Erfahrung: kostensenkend ist das nicht)

    Reply
    • rebeccanoeh
      30. Oktober 2013

      Wow, ich habe meinen allerersten Troll auf meinem Blog! Ich bin echt stolz. Thank you for reading and come again 😀

      Reply
  3. Jan
    31. Oktober 2013

    Nur weil etwas schon seit Jahren existiert, heisst doch nocht, das es Flächendeckend eingesetzt wird.

    Arbeitsweisen und ebenso Design und Umsetzungstrends (liquid, flat, responsive, parallaxe) sind nun mal erst buzzwords und erreichen erst später (aber nicht immer) das Plateau der Produktivität (Hype Live Cycle).

    Reply
    • rebeccanoeh
      31. Oktober 2013

      Lieber Jan, Regel Nummer 1: don’t feed the troll. 😉

      Reply
  4. Matthias Guenther
    5. November 2013

    Hallo Rebecca, auch wenn es Werbung (sorry), wir haben gerade ein Buch zu agilen Prozessen wie Scrum geschrieben.

    Scrum wird ja schon seit über 10 Jahren in der Softwareentwicklung angewandt, im Projektmanagement ist es gerade ein Buzzword und im Publishing bzw. in der Kreativbranche wird es kaum angewandt.

    Daher handelt unser Buch „Agiles Publishing“ genau davon, wie können wir agile Denk- und Handlungsweisen im Publishing bei App-, Web- und Printprojekten anwenden. Auf unserer Webseite gibt es Leseproben und Stimmen zum Buch und auch verlinkte Artikel.

    Über Feedback würden wir uns freuen und vielleicht hilft es ja bei deinem nächsten Projekt.

    Reply
  5. Jan
    5. November 2015

    Hey Rebecca, grade mal wieder hier drüber gestolpert, weil wir das Thema grade versuchen in den gesamten Kea Prozess einer Digital Agentur einzuführen. Problem sind immer noch die gleichen. Bei Zusammenarbeit mit Klassik Agenturprozessen läuft das einfach nicht 😉

    Sonst natürlich gut.

    Kennst du mittlerweile gute Tools, die den Backlog abbilden? oder einfach Jira/Confluence nehmen?

    Schönen Gruss aus Zürich
    Jan

    Reply
    • Matthias Guenther
      8. Juni 2016

      Hallo Jan,

      agile Arbeitsweisen funktionieren hervorragend in digitalen Agenturen, siehe hier:
      http://blog.publishingnetwork.ch/2014/02/25/agiles-publishing-das-momentum-halt-an/

      Das Tool ist eigentlich sekundär, wichtiger ist das Verändern der Arbeits- und Denkweisen: Nie fertig werden, in Iterationen auf die Vision zu bewegen, Ziele immer wieder anpassen, viel Zusammenarbeit, viel Kommunikation, Auftraggeber einbeziehen.

      Grüße
      Matthias

      Reply
    • rebeccanoeh
      8. Juni 2016

      Hi Jan,
      wir haben direkt mit Jira gearbeitet – sowohl bei Deepblue als auch zuletzt beim Relaunch der NIVEA.de und das hat wirklich gut funktioniert.
      Zudem muss ich Matthias komplett Recht geben, dass das Tool deutlich zweitrangig ist und die Denkweisen einfach angepasst werden müssen. Das wird auch noch einige Jahre dauern, bis all diese Prozesse von den klassischen Kollegen und auch Kunden wirklich durchgeholt werden und die Zusammenarbeit dann besser flutscht. Aber nur so funktioniert der Weg in die Zukunft der Agenturen, denke ich. 😉
      Liebe Grüße
      Rebecca

      Reply

Leave a Reply