Agile und Scrum: Wie funktioniert agile Arbeit?

Wer etwas auf sich hält, arbeitet agil. Selbst Großunternehmen versuchen sich an agilen Methoden. Es ist dann die Rede von schnellen Iterationen und einer neuen Teamstruktur, von Scrum und Sprints. Sieht man genauer hin, meinen damit längst nicht alle dasselbe. Wir haben zwei Agile-Experten gefragt: Was bedeutet Agile, was ist Scrum?

Agile ist längst kein Nischenthema mehr: In einer Studie des ITK-Branchenverbands Bitkom aus dem vergangenen Herbst gab mehr als jedes zweite Unternehmen mit mehr als 2.000 Mitarbeitern an, bereits mit agilen Methoden zu arbeiten. Weitere 15 Prozent planen demnach den Einsatz noch in diesem Jahr. Scrum ist dabei die Methode der Wahl: 79 Prozent der befragten Firmen, die nach eigenen Angaben agil arbeiten, setzen auf Scrum.

Ursprünglich beschreibt Agile eine Herangehensweise an Softwareentwicklung. Im 2001 veröffentlichten „Manifest für Agile Softwareentwicklung“ sind vier relativ allgemeine Leitsätze und zwölf Prinzipien aufgelistet. Das Manifest fordert die enge Zusammenarbeit von Entwicklern und Kunden in kurzen Abstimmungsschleifen. Dem einzelnen Developer wird dabei ein großer Freiraum für seine Arbeit zugestanden.

Scrum ist eine Methode der agilen Zusammenarbeit im Team. Die Regeln, nach denen ein Produkt mit Scrum entwickelt werden kann, sind im Scrum Guide niedergeschrieben. Dort sind drei Rollen im Scrum-Team festgelegt: Das Produktentwicklungsteam arbeitet völlig selbstständig und wählt seine Arbeitsweise selbst. Neben den Entwicklern gibt es einen Product Owner, der für das Produkt und seine Funktionen verantwortlich, aber nicht Teil des Entwicklungsteams ist. Eine entscheidende, aber etwas nebulöse Rolle hat der Scrum Master: Dieser überwacht die Einhaltung der Regeln und begleitet den Arbeitsprozess. Dazu coacht er bei Bedarf das Entwicklungsteam und sorgt dafür, dass den Entwicklern alle nötigen Ressourcen zur Verfügung stehen, die sie für ihre Arbeit benötigen. Durch verschiedene Feedbackschleifen in festen Intervallen soll sichergestellt werden, dass die Ergebnisse der Arbeit ständig kontrolliert und optimiert werden. Innerhalb eines Teams sind tägliche Abstimmungsrunden vorgesehen. Nach Abschluss einer maximal einmonatigen Arbeitsphase — eines sogenannten Sprints — kommen alle Beteiligten zusammen, besprechen die Ergebnisse und planen die nächsten Schritte.

Christian Kroemer und Tobias Hingerl sind Softwareentwickler bei Comsysto Reply, arbeiten selbst nach Scrum und unterstützen Unternehmen beim Einsatz agiler Methoden. Wir hatten die Gelegenheit, mit den beiden Agile-Experten zu sprechen.

Zunächst einmal zum Einstieg: Was ist Scrum, was ist Agile? Und für wen sind agile Methoden geeignet?

Tobias Hingerl: Scrum ist ein Framework und damit eine von vielen agilen Vorgehensweisen. Gerne wird das vermischt oder sogar gleichgesetzt: „Agile ist Scrum“. Das ist allerdings Quatsch. Es gibt noch viele andere Modelle, Frameworks und agile Methodiken. Agilität ist die Basis von Scrum. Arbeitet man mit Scrum, ohne agile Werte zu vertreten, dann setzt man ein Tool ein, das man nicht versteht.

Christian Kroemer: Im Grunde ist Agile für fast jeden geeignet. Agilität ist ein Mindset, das ganz stark auf Lernen setzt. Hoffentlich hat fast jeder eine Tätigkeit, bei der es irgendwas zu lernen gibt. Da macht es Sinn, Punkte einzubauen, an denen man reflektiert, wie die Arbeit läuft und wo man sich verbessern kann. Agile macht deshalb eigentlich überall Sinn, wo mehr als zwei Personen zusammenarbeiten. Zumindest auf der zwischenmenschlichen Ebene kann man immer etwas verbessern.

„Grundlage ist, seine Arbeit ständig zu hinterfragen“

Warum sollte ich agil arbeiten wollen?

Christian Kroemer: Weil Du am Markt überleben willst. Ist man in einem eher unsicheren Kontext unterwegs, wie es wohl auch bei den meisten Startups der Fall ist, hilft es nichts, einen Fünfjahresplan zu erstellen und möglichst genau einzuhalten, sondern in möglichst kurzen Iterationen und Lernschleifen zu arbeiten. Ich glaube, agil arbeitet man, wenn man nach zwei Jahren sagen kann: Ich hatte vor zwei Jahren keine Ahnung, dass ich dort rauskommen würde, aber ich bin überzeugt, dass dieses Ergebnis das bestmögliche ist.

Tobias Hingerl: Grundlage ist, seine Arbeit ständig zu hinterfragen: Tue ich noch das Richtige? Und ich glaube, für ein Startup ist das sogar noch wichtiger als für ein großes Unternehmen, weil man sonst nach zwei Jahren einfach weg ist.

Tobias Hingerl (l.) und Christian Kroemer (r.) trainieren Scrum Master und arbeiten selbst als Software-Entwickler.
Tobias Hingerl (l.) und Christian Kroemer (r.) trainieren Scrum Master und arbeiten selbst als Softwareentwickler.

Das klingt ziemlich ähnlich zur Idee des Lean Startup: Ein Produkt so schnell wie möglich testen, um es zu verbessern oder früh scheitern zu lassen.

Christian Kroemer: Bei Lean Startup geht es darum, sich zu fokussieren auf das, was wirklich Wert stiftet und zu versuchen, alles andere wegzulassen. Für ein Startup ist das glaube ich relativ essenziell, weil man einfach sehr begrenzte Ressourcen hat. Bei Agile spielt das schon auch mit rein. Im Agilen Manifest steht ja beispielsweise: Ein funktionierendes Produkt ist für uns wichtiger als eine super ausführliche Dokumentation. Ich persönlich glaube, der Kern dahinter ist, dass man möglichst schnell lernen will. Ein Produkt — und sei es nur ein ganz rudimentärer Prototyp — kann ich jemandem zeigen und Feedback einholen.

Tobias Hingerl: Wenn ich irgendwo ein Dokument ausgearbeitet habe, in dem zwar alle Features beschrieben sind, aber ich habe noch nichts gemacht, dann weiß ich nicht, ob es auch funktionieren kann. Ich weiß auch nicht, wie aufwändig es ist. Ich kann von niemandem ein echtes Feedback bekommen. Insofern hilft einem genau dieser Lean-Ansatz, schneller zu erkennen, ob man das Richtige tut. Aber Agile ist noch mehr als iterativ zu arbeiten. Es ist vor allem auch Weglassen von Sachen, die nur Overhead sind, wie eben Fünfjahrespläne und das Controlling, ob man sie einhält. Das hilft einem nicht dabei, das Richtige zu tun, sondern höchstens, beharrlich das zu tun, was vor fünf Jahren richtig aussah.

Wo ist Scrum anwendbar? Nur in der Softwareentwicklung?

Tobias Hingerl: Das ist im Scrum Guide klar definiert: Bei Produktentwicklung und „complex adaptive problems“. Wenn Du das nicht hast, brauchst Du kein Scrum und vielleicht auch überhaupt keine agile Methode. Der menschliche Teil, durch Reflektieren besser zu werden, geht wahrscheinlich immer. Aber wenn dein Produkt nicht komplex ist, sprich: Du kannst vorher nicht genau planen, wo es hingeht, und nicht adaptiv, Du also flexibel und mit kurzen Vorlaufzeiten reagieren kannst, dann bringt eine agile Produktentwicklung eigentlich nichts.

„Das ist ein krasser Bruch zu klassischen Strukturen“

Was hat es mit den verschiedenen Rollen im Scrum-Team auf sich?

Tobias Hingerl: Zum einen gibt es das Entwicklungsteam. Innerhalb des Teams gibt es keine Rollen, keine Tester und keine Architekten, die den anderen im Team sagen, was sie tun sollen. Das Team sollte im Stande sein, alle anfallenden Aufgaben erledigen zu können. Die Stichworte sind: selbstorganisiert und cross-funktional. Zusätzlich gibt es einen Scrum Master und einen Product Owner. Der Product Owner wird häufig vom Kunden gestellt und verantwortet die Idee hinter dem Produkt und das Budget. Der Scrum Master hat eine eher unterstützende, coachende Rolle, die gar nicht so sehr ins Daily Business eingreift, sondern von außen beobachtet, vielleicht auch mal Impulse gibt und vor allem auch dafür verantwortlich ist, dass im Team kontinuierliches Lernen und kontinuierliche Verbesserung stattfinden. Wenn ein Team völlig neu in agilen Methoden ist, dann muss ein Scrum Master auch viel erklären, beibringen und vielleicht auch Meetings hart moderieren, damit das Team versteht, wie Scrum funktioniert. Das Ziel muss aber immer sein, impediments (Anm. d. Red.: Hindernisse) aufzulösen, damit das Team mittelfristig selbstorganisiert arbeiten kann.

Welchen Hintergrund haben Scrum Master typischerweise? Von einem Bekannten habe ich einmal gehört: „ITler, die keine Lust mehr auf IT haben“

Christian Kroemer: Schlechte Scrum Master findet man häufig aus dieser Ecke. Bei den Guten ist der Hintergrund glaube ich gar nicht so wichtig. Was alle guten Scrum Master gemeinsam haben ist, dass sie aus Überzeugung gerne mit Menschen arbeiten und Dinge vorwärtsbringen möchten. Ob jemand einen starken IT-Hintergrund hat, aus der Psychologie, Pädagogik oder sonst woher kommt, ist glaube ich gar nicht so wichtig. Ich habe gute Beispiele aus beiden Richtungen kennengelernt.

Ein Scrum Master muss fachlich nicht verstehen, was das Entwicklerteam arbeitet?

Christian Kroemer: Nicht unbedingt. Ich glaube, dass es hilft, das ist aber eine kontroverse Debatte in der agilen Community.

Tobias Hingerl: Viele Scrum Master arbeiten zur Hälfte selbst noch als Entwickler, so ist es bei uns ja auch häufig. Das macht die Arbeit dann aber auch manchmal schwieriger, weil Du zwei verschiedene Hüte aufhast mit zwei verschiedenen Verantwortlichkeiten. Der Entwickler möchte vielleicht etwas anderes als ein Scrum Master.

Ist es ein Problem, dass der Job eines Scrum Masters zu wenig für eine Vollzeitstelle ist und zu viel für eine Teilzeitstelle?

Christian Kroemer: Auch das ist eine häufig diskutierte Frage. Es gibt dazu einen schönen Satz: Ein guter Scrum Master kann zwei bis drei Teams gleichzeitig betreuen, ein sehr guter nur eines. Ob das stimmt, weiß ich allerdings nicht. Wenn ich als Scrum Master in einer Organisation arbeite, die wirklich agil tickt, habe ich vielleicht weniger zu tun. Dann habe ich aber die Zeit, einzelne Teammitglieder einzeln zu coachen und so das gesamte Team voranzubringen.

Jeder Scrum Master findet seinen eigenen Stil. Dazu braucht es aber ein paar Jahre Erfahrung. Wir können im Training vermitteln, wie Scrum funktioniert und wie man anfängt. Man kann in zwei Tagen aber niemandem wirklich beibringen, was es bedeutet, ein Scrum Master zu sein. Im Scrum Guide steht auch fast nichts dazu.

Wie sieht eigentlich die Weisungsbefugnis im Scrum-Team aus? Ein Scrum Master ist ja kein Vorgesetzter.

Tobias Hingerl: Das ist ein sehr wichtiges Thema. Wie das Team die Arbeit erledigt, hat nur das Entwicklerteam zu entscheiden. Das ist ein krasser Bruch zu klassischen Strukturen. Manche Unternehmen, die Scrum einführen, machen den bisherigen Teamleiter zum Scrum Master und den Abteilungsleiter zum Product Owner. Der Product Owner sagt dann dem Scrum Master, was zu tun ist und der Scrum Master gibt es ans Team weiter. Das ist nicht Scrum.

Christian Kroemer: Es gibt auch Lösungen, die vielleicht erst einmal überraschend für Scrum klingen: Wenn sich beispielsweise alle im Team einig sind, dass ein Entwickler der beste Software-Ingenieur ist und Architektur-Entscheidungen immer von ihm getroffen werden sollten, dann ist das okay. Wichtig ist nur, dass die Entscheidung aus dem Team herauskommt und nicht vom Vorgesetzten. Das Team muss aber auch in der Lage sein, dem Entwickler zu sagen, wenn er nicht mehr der Richtige dafür ist.

Wer hat dann die Personalverantwortung und wer führt die Gehaltsverhandlungen?

Christian Kroemer: Das sehe ich nicht bei einem Mitglied des Teams. Wenn Du weißt, dass Du in zwei Monaten mit Deinem Scrum Master Gehaltsverhandlungen führen wirst, tust Du vielleicht Dinge einfach nur, um gut auszusehen, obwohl es dem Team überhaupt nicht hilft. Das ist ein Anreiz, der in die falsche Richtung geht. Es gibt auch Firmen, die mit einem Open Salary arbeiten. Die Kollegen entscheiden dann darüber, was Du verdienst. Und die werden Dich sicher nicht dafür belohnen, dass Du den Helden spielst, aber eigentlich nichts tust.

Wie sehen die Review-Runden bei Scrum aus?

Tobias Hingerl: Es gibt zwei Formate: das Review-Meeting und die Retrospektive. Beide finden nach einem Sprint statt, der mindestens eine und maximal vier Wochen dauert. Beim Review-Meeting schauen sich alle Stakeholder gemeinsam das Produkt an: Entspricht es den Erwartungen? Wenn nicht, wird es im nächsten Sprint angepasst. Die Retrospektive ist die teaminterne Feedbackloop: Wie setzen wir Dinge um? Der Scrum Master moderiert das typischerweise. Es wird immer wieder diskutiert, ob auch der Product Owner an der Retrospektive teilnehmen soll, gerade wenn der vom Kunden gestellt wird.

„Es gibt Kunden, mit denen agile Zusammenarbeit erst einmal keinen Sinn macht“

Was sind die Vorteile agiler Arbeit gegenüber klassischer Projektarbeit mit Budget, Zeitplan und Hierarchie?

Tobias Hingerl: Zu allererst die Anpassungsfähigkeit. Ein Beispiel: Als Student habe ich in einer Bundesbehörde gearbeitet. In der ersten Phase wurden zwei Jahre lang Lastenheft und Pflichtenheft geschrieben. Danach folgten viereinhalb Jahre Entwicklung. Nach sechs Jahren wurde dem Kunden dann das Produkt gezeigt. Kein Mensch weiß aber, ob das Produkt das ist, was der Kunde vor sechs Jahren formuliert hat. Es weiß auch anfangs niemand, ob das vorher festgelegte Budget und die Timeline überhaupt eingehalten werden können. Das ist offen gesagt einfach unehrlich. Im Agilen kann das so nicht passieren. Man erhält viel früher Feedback. Dadurch wird das Ergebnis besser.

Christian Kroemer: Weitere Vorteile sehe ich auch auf der soften Ebene: Zumindest hier in Deutschland und speziell in München und ganz speziell in der IT haben wir einen relativ klaren Arbeitnehmermarkt. Effektiv können wir beide uns beispielsweise aussuchen, wo wir arbeiten möchten. Ich glaube, das klassische Projektgeschäft ist nicht unbedingt das Umfeld, mit dem man die besten Leute bekommt. Da werden Pläne gemacht, die typischerweise sehr ambitioniert sind. Dadurch entsteht im Team großer Druck. Das ist schon einmal nicht gut, wenn man möchte, dass Mitarbeiter sich wohlfühlen. So gibt es auch keine Anreize für Mitarbeiter, sich Gedanken zu machen, ob sie eigentlich das Richtige tun. Sie folgen dem Plan und Du verlierst die kreativen Leute. Außerdem ist es deutlich motivierender, wenn ein Entwickler direkt vom Kunden hört, dass er ein konkretes Problem gelöst hat als wenn der Projektmanager sagt: „Super, wir haben die Deadline gehalten“, aber der Entwickler hat keine Ahnung, warum.

Gibt es nicht Beschwerden von Kunden, die sagen: Ich zahle so viel Geld und habe jetzt die ganze Zeit Arbeit mit Euch?

Christian Kroemer: Ja, es gibt solche Kunden. Mit denen macht agile Zusammenarbeit erst einmal keinen Sinn. Wir haben aber auch schon Projekte so umgesetzt, dass wir intern trotzdem agil arbeiten. Dem Kunden schicken wir dann ganz unverbindlich einen Zwischenstand. So kommt meistens automatisch Feedback, an dem wir uns orientieren können.

Tobias Hingerl: Ich glaube, da hat mittlerweile auch ein Umdenken stattgefunden. Ich kenne nicht mehr viele Kunden, die sagen: Kommt in einem Jahr wieder und zeigt mir das Ergebnis. Die Leute sehen ja selbst, dass das nicht funktioniert.

Ist es für den Auftraggeber nicht viel schwieriger zu planen, was ein Projekt kosten wird und wie lange es dauert, wenn der Dienstleister agil arbeitet?

Christian Kroemer: Manche große Kunden brauchen für den Einkauf einen Fixpreis. Wir kommunizieren dann ganz klar: Diese Zahl ist unser Best Guess zum aktuellen Zeitpunkt, aber wir verstehen Eure Domäne nicht wirklich gut, wir kennen Eure Technologie nicht, Ihr werdet in einem halben Jahr bestimmt Änderungswünsche haben und wir möchten das auch. Wir wollen dem Kunden viel Freiheit geben, aber dafür können wir ehrlicherweise nicht hundertprozentig versprechen, wie das Ganze dann aussieht. Wenn ein Kunde dann sagt: „Das mache ich nicht mit“ ist es wahrscheinlich das Beste, den Auftrag gar nicht erst anzunehmen. Sonst werden unsere Mitarbeiter nur frustriert. Diese Unehrlichkeit wollen wir so nicht spielen.

Es gibt spannende Vorschläge, mit dieser Unsicherheit vertraglich umzugehen. Dauert ein Projekt länger als geschätzt, können sich Dienstleister und Kunde beispielsweise die Mehrkosten nach einer festgelegten Formel teilen. Wird man schneller fertig, steigt dann die Marge des Dienstleisters, aber der Kunde muss auch weniger bezahlen. Dadurch bringt man beide Seiten in ein Boot und vermeidet einen Kampf gegeneinander. Das ist nur ein Beispiel von vielen. Wenn man sich kennt und sich vertraut, ist ein fester Tagessatz aber natürlich das einfachste.

„Es ist wichtig, Dinge explizit zu machen und sie kontinuierlich zu verbessern“

Die Arbeitsweise mit Agile und Scrum wirkt sehr formalisiert. „Scrum Guide“ und „Agiles Manifest“ klingen ein bisschen nach Heiliger Schrift. Ist es Ketzerei, von der reinen Lehre abzuweichen? Oder sind das nur Richtlinien?

Christian Kroemer: Wir hatten vor kurzem einen Workshop bei Peter Götz, der das Konzept für Scrum.org, eine der führenden Organisationen, mitvertritt. Er sagte, dass es ihm grundsätzlich völlig egal ist, ob jemand Scrum richtig macht oder nicht. Möchte man etwas anders machen, ist es völlig okay. Das kann trotzdem agil sein und für Dein Umfeld genau das Richtige. Aber formal betrachtet ist es dann halt nicht Scrum — was auch nicht schlimm ist. Nur wenn Du etwas Scrum nennst, soll auch wirklich Scrum drin sein. Gerade große Konzerne, die agil werden möchten, kleben aber häufig das Label „Scrum“ auf etwas völlig anderes drauf.

Wenn ein Startup sagt: Wir wollen agil werden und Scrum anwenden — Was wären die ersten Schritte die man umsetzen müsste, um dahin zu kommen?

Christian Kroemer: Ich würde mich erst einmal überhaupt nicht auf Scrum festlegen. Es gibt auch andere Methoden, wie beispielsweise Kanban. Das sagt: Es ist wichtig, Dinge explizit zu machen und sie kontinuierlich zu verbessern. Wenn Du Kanban einführst, änderst Du erst einmal überhaupt nichts. Du fängst mit Deinem Status quo an und respektierst, dass Dinge so sind, wie sie sind. Denn vermutlich hast Du ja nicht nur Idioten in der Firma, sondern Leute, die aus Gründen Dinge tun. Dann erhöhst Du die Transparenz so stark wie möglich, machst alles explizit und etablierst irgendeine Form von Retrospektiven, Reflexion und kontinuierlicher Verbesserung. Allein das ist schon super agil, unabhängig davon, ob das jetzt Scrum heißt oder wie auch immer.