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.
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.
Also was genau passiert da, wenn man als Online-Team für eine Webseite oder App im Scrum-Prozess arbeitet?
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.
Regel Nummer 3: Rollen!
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 Morgen 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: Sprints
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: Poker
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.
Wie funktioniert der Scrum-Poker?
Scrum-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 mit der Zahl schätzt. Dann wird das Task noch mal gepokert.
So werden alle Tasks im Sprint geschätzt
Erstellung der Navigation, eines Formulars, einer Unterseite… Bei Sprint-Start wird anhand einer Zahl festgelegt, wieviel man an Arbeit schaffen kann.
Addiert man nun alle Schätzungen der Pakete, kann man sich nicht zuviel „auf den Teller laden“ 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.
Regel Nummer 7: Backlog
Der Sprint wird mit einem Backlog – sprich einem digitalen Tool begleitet.
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: Review
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. Was wir aus dem letzten Sprint gelernt haben und mitnehmen können.
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.
Aber in dem hinter mir liegenden Projekt habe ich gelernt, dass es super funktioniert. Und ich gehe noch weiter:
Es ist für mich die Zukunft der Online-Werbung. Vielleicht sogar die Zukunft der Werbung selbst.
Der Wasserfall-Prozess ist echt überholt.
Der Gedanke, dass bei einem größeren und komplexen Projekt (ich rede jetzt nicht von einer „popeligen“ Landingpage) sich ein Konzeptioner (also sowas wie ich) alleine in seinem Kämmerlein ein Wirefrämchen-Gelöt braut – ohne vorher so wirklich mit Front- oder Backend gesprochen zu haben, gruselt mich total.
Bei vielen Agenturen wird die Programmierung jedoch extern dazugekauft und sitzt nicht in der Agentur. Und das „dazukaufen“ passiert eben erst im Wasserfall nach Konzept und Design. Schwierig!
Klar, wenn der Konzeptioner gut ist, hat alles bestimmt eine tolle Struktur und gute Usability. Aber es ist doch mehr als sinnvoll vor Beginn einmal durchzusprechen „ob das alles so geht?!“
Und dann kommt der Designer, ohne meist so wirklich an Usability und Programmierung zu denken, sondern vor allem an seinen Design-Anspruch. Klar denken viele Designer super konzeptionell mit und diskutieren gerne mal meine Ideen wenn sie die Wireframes ins Design „übersetzen“. Trotzdem ist die Umsetzung eben nicht ihr Gewerk!
„Warum haben wir nicht vorher gesprochen?“
Wenn der Front-Ender jetzt erst „das Ganze“ in die Finger bekommt, passiert es gerne und häufig, dass dieser über den Kram flucht, den „die Anderen“ verzapft haben.
„Warum haben wir nicht vorher gesprochen?“
Tjaaaa…
Nun ist das Timing wahrscheinlich auch schon schrecklich knapp und die Kohle auch bald alle.
Also muss der Backender als Schlusslicht ganz ganz schnell arbeiten und damit rechnen, dass keiner für ihn vor- und mitgedacht hat. Uff. Das klingt irgendwie idiotisch, oder? Aber so wird’s ja immer gemacht! Und dann kann man keinem Front- und vor allem Backender verdenken, dass die Laune sinkt und sich Fronten zwischen Konzept und Design und Programmierung bilden. Weil es komplett an der Kommunikation mangelt!
Der große Unterschied: Wie war das also in unserem Scrum-Büro?
Wir hatten tatsächlich den Deal, dass so gut wie alles immer DIREKT angesprochen und das komplette Team (Konzept, Design, Frontend und Backend) dazu geholt wird, wenn ein Teil des Projektes besprochen wird.
Damit es hinterher kein „Davon wusste ich ja gaa nix!“ gibt.
Das funktionierte erstaunlich gut und schnell. Obwohl wir größtenteils noch nie miteinander gearbeitet haben.
Ich war ja sowieso als Freelancer an Bord und kannte niemanden aus dem Team. Und es wurde immer mitbedacht, welche Auswirkung die eigene „Aktion“ auf die anderen Gewerke hatte. Klingt wie Utopia, aber es klappt, weil wir dank Scrum einen wirklichen Rahmen haben.
Mir persönlich hat es unfassbar geholfen, alles gemeinsam zu durchdenken. Und ich habe echt viel gelernt!
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 komplett andere Sache, wenn man beim Briefing Fragen in einem Meeting oder per Telefon klärt, wenn man spekuliert wie was vielleicht aussehen wird. Im Gegensatz dazu, sich einfach nur umdrehen zu müssen, um zu wissen ob etwas für das Backend besser funktioniert, weil es Variante B und nicht A ist. Und zusammen dann über Variante C nachzudenken, die noch viel geiler ist! „Ach, das geht wirklich so?“ habe ich oft erstaunt gefragt. Und wieder was dazu gelernt. Cool!
Und gemeinsam mit Design und Frontend beispielsweise die optimalste Form einer mobilen Navigation zu finden, die für alle funktioniert. Wenn ich es mir wünschen könnte, würde ich alle großen Projekte so machen.
Was hat nun die Agentur davon?
Es heißt ja immer, dass ein Scrum-Projekt den Arbeitsprozess agil macht. Weiter oben erwähnte ich ja schon, dass dies nicht bedeutet, dass der Kunde ständig seine Meinung ändern kann.
Sondern die Agentur und das Team reagiert flexibel auf Ereignisse und Veränderungen. Das ist komplett was anderes!
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. Und darauf muss das Projekt angepasst werden.
Wäre der Konzeptioner im Wasserfall alleine losgelaufen, würde dies bedeuten, das im schlimmsten Fall alles neu konzipiert werden muss. Vielleicht ist der Konzeptioner auch schon runter vom Projekt und als Freelancer woanders gebucht? Dann ist der Designer gerade mittendrin in der Umsetzung – der Konzeptioner muss überarbeiten oder der Designer alle konzipieren und retten?
Und erst wenn alles „gerettet“ wurde können Front- und Backender anfangen. 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. Beim Wasserfall lenkt jedes Gewerk eben nur ein Rad und der Karren rollt im Worst case automatisch gen Dreck.
Das sollte jeder Agentur zu denken aufgeben.
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!
Jan
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
Matthias Guenther
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
rebeccanoeh
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