15F.A.Z. VOM 16. MÄRZ 2019

Viele Chefs wollen ihre Teams so organisieren wie Amazon und Google. Aber Begriffe wie „Scrum“, „Sprint“ und „Kanban“ verwirren manchen Mitarbeiter. Eine Erklärungshilfe.

Von Bastian Benrath

Ich soll künftig agil arbeiten –wie geht das?

Zwei Pizzen. Mehr soll es bei Amazon nicht brauchen, um ein Entwicklerteam

satt zu machen. Das heißt: Es arbeiten stets nur zwei Entwickler an einem Problem. So-bald das Problem zu groß wird, um es zu zweit lösen zu können, wird es aufgespalten in Teilprobleme, die wieder mit einem „Two-Pizza-Team“ lösbar sind. Haben zwei Kolle-

gen auf diese Art und Weise eine neue Funk-tion entwickelt, gehen sie nicht zu einem neuen Projekt über, sondern betreuen eben-so den Betrieb der von ihnen entwickelten Software. Amazon arbeitet so seit Jahren: „Das traditionelle Modell ist, dass man seine Software bis zur Mauer zwischen Entwick-lung und operativem Betrieb trägt, sie

16 F.A.Z. VOM 16. MÄRZ 2019

drüber wirft und dann vergisst. Nicht so bei Amazon“, sagte der Technologievorstand des Silicon-Valley-Konzerns, Werner Vogels, schon vor vielen Jahren. Bei Amazon heiße es: „Du baust es. Du leitest es.“

Amazon treibt so eine Organisationsform auf die Spitze, welche die Projektarbeit di-verser, auch deutscher Unternehmen in den vergangenen Jahren von Grund auf verän-dert hat: Agiles Arbeiten verändert die Ar-beitswelt. Einer repräsentativen Befragung des Digitalverbands Bitkom zufolge ist jedes zweite deutsche Großunternehmen mit mehr als 500 Mitarbeitern im IT-Bereich schon auf agile Methoden umgestiegen. Aber auch außerhalb des IT-Bereichs findet agiles Arbeiten immer mehr Anhänger, auch wenn die Arbeitsweise im Digitalbereich noch immer die höchste Verbreitung hat. Eine genaue, allseits akzeptierte Definition gibt es noch nicht, doch die meisten Quellen begegnen sich in dem Gedanken, dass dar-unter das strukturierte Arbeiten in kleinen Teams, mit einer systematischen Erfassung des Fortschritts, der andauernden Bereit-schaft zur Veränderung der Arbeitsweise und einer Orientierung an den Bedürfnissen des Kunden zu verstehen ist.

„Es hat etwas mit Ausprobieren zu tun“, so formuliert es Joachim Bernhardt, der im Projektbereich einer deutschen Großbank agile Methoden kennenlernte. Man müsse sich darauf einlassen, nicht in vertrauten Bahnen zu arbeiten, sondern regelmäßig quer zudenken. Den Weg zum Ziel vorher explizit nicht durchzuplanen habe ihn zu Beginn stets etwas zögern lassen, beschreibt der 59-Jährige, der eigentlich anders heißt, seine Erfahrungen. Vor allem die kurzen Kommunikationswege fand er aber sinnvoll: „Der stetige Abgleich ist sehr gut.“ Zugleich habe das agile Arbeiten jeden im Team stän-

dig „unter Spannung“ gehalten – was für den Arbeitsprozess förderlich gewesen sei.

Das Konzept des agilen Arbeitens stammt aus der Software-Entwicklung, was erklärt, warum vor allem Tech-Unternehmen als Vorbilder in Sachen Agilität gelten. Die in Deutschland am weitesten verbreitete agile Methode ist „Scrum“, wie der Bitkom in sei-ner Studie weiter herausgefunden hat. Dem-nach setzen fast 80 Prozent der Unterneh-men in der agilen Projektarbeit auf diesen methodischen Rahmen. Das Rückgrat eines Scrum-Projekts bildet das sogenannte „Back-log“. Das ist ein Verzeichnis, in dem alle zu erledigenden Aufgaben des Teams festgehal-ten und nach Wichtigkeit priorisiert werden. Häufig werden die Aufgaben und ihr Bear-beitungsstand auch auf einer zentral aufge-stellten Tafel mit farbigen Karten sichtbar gemacht. Der „Product Owner“ hat im Team eine Leitungsfunktion inne und wacht über das Backlog. In der Regel jeden Tag kommen die Teammitglieder in einer Kurzkonferenz zusammen, die „Daily“ oder „DailyScrum“ genannt wird. Dieses Treffen dient vor allem dem Statusabgleich. Oft beantwortet jedes Teammitglied drei Fragen: Was habe ich seit gestern getan? Was plane ich bis morgen? Und: Auf welche Hindernisse bin ich gesto-ßen, und wie können diese beseitigt werden? Um die Tagestreffen kurz zu halten, finden sie meist im Stehen statt. Manche Teams ge-ben sich auch strikte Zeitvorgaben – etwa, dass ein Daily nur maximal 15 Minuten dau-ert. Moderiert werden sie vom sogenannten „Scrum Master“, der als methodischer Fach-mann eine Art Team-Coach ist und darauf achtet, dass die Zusammenarbeit reibungs-los funktioniert, dafür aber nicht inhaltlich arbeitet. Entscheidend bei Scrum ist, dass der Projektzeitraum von vornherein festge-legt ist, aber die Ziele und die zu lösenden

17F.A.Z. VOM 16. MÄRZ 2019

Aufgaben flexibel neu festgelegt werden können, wenn im Arbeitsprozess eine Not-wendigkeit dazu entsteht. Ein Scrum-Pro-jekt ist deshalb aufgeteilt in Zeitschritte, sogenannte „Sprints“. Diese haben eine vor-definierte Dauer, meist eine oder zwei Wo-chen. Am Ende jedes Sprints gibt es eine ausführlichere Konferenz, in der die Ergeb-nisse des Sprints einem größeren Team oder auch der übergeordneten Ebene vorgestellt werden. Wenn es dadurch sinnvoll erscheint, die Aufgaben des kommenden Sprints zu ändern, werden diese Änderungen über-nommen und festgelegt.

Eine im Kern ähnliche Projektmethode ist „Kanban“, allerdings wird hier die praktische Arbeit etwas anders organisiert. Kanban wird dem Bitkom zufolge am zweitmeisten in deut-schen Unternehmen eingesetzt, wenn gleich mit weitem Abstand hinter Scrum; auf Kanban greifen der Befragung zufolge 17 Prozent der Unternehmen zurück, die agile Arbeits-weisen nutzen. Der Unterschied zu Scrum liegt vor allem darin, dass es keine festen Leiterinnen oder Moderatoren gibt. Statt-dessen steht das sogenannte „Kanban-Board“ im Zentrum, aus dem hervorgeht, wer zur-zeit für was zuständig ist. Jede Aufgabe wird dort von einer Karte repräsentiert, die wäh-rend des Projekts von „Backlog“ durch meh-rere Stufen bis auf „Erledigt“ wandert. Da-durch wird leicht sichtbar, wo sich Arbeit staut und welche Kollegen überlastet oder unterfordert sind. Das Team organisiert sich bei Kanban selbst, indem es den gemeinsa-men Arbeitsfortschritt am Board abliest und sich neue Arbeit holt. Meetings spielen eine untergeordnete Rolle. Kanban erfordert in-sofern mehr Eigenverantwortung. Bei Scrum hingegen besteht die Gefahr, dass die Team-mitglieder ihre Arbeitsbelastung unterschät-zen und sich zu viel vornehmen. Zudem

18

können die Konferenzen zu Zeitfressern werden.

Spricht man mit Menschen, die Erfahrung in dem Bereich haben, wird schnell klar, dass agiles Arbeiten Fähigkeiten fordert, die in der klassischen Büroarbeit eher unterent-wickelt sind. Beispielsweise ist es essentiell, dass Teammitglieder sachlich, möglichst hie-rarchiefrei und präzise kommunizieren kön-nen. Sind die Mitarbeiter daran nicht ge-wöhnt, kann es in der doch eigentlich so flexiblen Arbeit ganz schön knirschen. Lukas Fleischer beispielsweise arbeitet in einem größeren Medienunternehmen agil an der Entwicklung eines Digitalprodukts, auch er heißt in Wahrheit anders. „Für Software-Pro-jekte ist es schon eine gute Arbeitsmethode“, sagt er. Aber: „Ich denke nicht so, wie ein Programmierer denkt.“ Sein Team identifi-ziert notwendige Änderungen, die am Pro-dukt vorgenommen werden sollen, und be-nutzt eine Online-Plattform, um sie an externe Programmierer weiterzugeben. „Wenn alle Seiten es gut machen, funktioniert es rei-bungslos“, sagt er. Nur: Es erfordere durch aus Übung, die Arbeitsaufträge so zu formu-lieren, dass sie von den Programmierern auch verstanden würden und das Ergebnis sie aus dem redaktionellen Blickwinkel auch zu frieden stelle.

Zudem merkt auch Fleischer an: „Man wird schon schneller gestresst.“ Wenn ein neuer Arbeitsauftrag ankomme und man mit etwas anderem beschäftigt sei, so dass man auf ihn einige Stunden nicht reagiere, kom-

me durchaus rasch die Aufforderung der Teamleitung, sich darum bitte zu kümmern. Dieser Druck habe aber auch die positive Seite, dass sich das Team dadurch gegensei-tig diszipliniere, bemerkt Joachim Bernhardt aus der Bank. Insbesondere in den regelmä-ßigen Meetings komme das zum Tragen: „Sich vors Team zu stellen und sagen zu müssen, dass man etwas noch nicht gemacht hat, tut man nicht so gerne.“

Seinen Ursprung hat das agile Arbeiten übrigens auf einer Skihütte im amerikani-schen Bundesstaat Utah. Dort, im Snow-bird-Skigebiet in der Nähe von Salt Lake City, traf sich im Februar des Jahres 2001 eine Gruppe von 17 renommierten Soft-ware-Entwicklern. Ihnen allen war gemein, dass sie sich Gedanken über bessere Wege der Software-Entwicklung machten und nach einem Ansatz suchten, der in der digi-talen Welt schnell auf wechselnde Anforde-rungen reagieren kann.

Sie verfassten, was sie das „Manifest für agile Software-Entwicklung“ nannten und was später, mit Blick auf die Anwendung in anderen Branchen, nur noch das „Agile Ma-nifest“ genannt wurde. „Reagieren auf Ver-änderung“, heißt es darin, sei wichtiger als das Befolgen eines Plans, „Individuen und Interaktionen“ wichtiger als Prozesse und Werkzeuge. Im Protokoll des Treffens ist nachzulesen, dass es dabei durchaus das Ziel war, den „Firmenbürokraten Angst zu ma-chen“ – und stattdessen den Nutzen des Kunden in den Mittelpunkt zu rücken.

WWW.FAZ.MEDIA/BILDUNGSMARKTJETZT ENTDECKEN

Machen Sie kluge Köpfe noch klüger... mit dem F.A.Z. Bildungsmarkt für Schule, Studium und Weiterbildung.