Sieben Scrum-Erkenntnisse: Wie Unternehmen in Zukunft agil arbeiten müssen

In den vergangenen Jahren haben immer mehr Unternehmen, die bisher mit konservativen Methoden wie Wasserfall oder per Unified Process - sei es RUP   oder Openup   - entwickelt haben, auf "lean" und agile Praktiken umgestellt. Es drängt sich der Eindruck auf, "als hätten praktisch alle namhaften Unternehmen in der IT-Entwicklung auf Scrum, Extreme Programming oder andere agile Methoden umgestellt", heißt es in der Studie Status Quo Agile  , die von der Hochschule Koblenz durchgeführt wurde. Sie befragten 350 teilnehmende Unternehmen, um herauszufinden, wie Unternehmen von Scrum ("Gedrängel") und anderen agilen Ansätzen profitieren. Auch in Bereichen wie Produktentwicklung und Prozessoptimierung spielen agile Methoden in der Internetwirtschaft eine zunehmend wichtige Rolle.

Treiber dieser Entwicklung ist vor allem die Erkenntnis, dass der bisherige klassische konstruktivistische Lösungsansatz, der nach einem festen Planungsmuster vorgeht, nicht hinreichend den heutigen Anforderungen gerecht wird. Unterm Strich bleibt eine "Scheingenauigkeit verbunden mit fehlender Flexibilität und geringer Zielorientierung", wie die Koblenzer Wissenschaftler es beschreiben. Der Begriff "agile Methoden" zielt auf eine ganze Reihe verschiedener Ansätze zur Organisation und Steuerung von Entwicklungsprozessen ab. Besonders im Fokus steht die Scrum-Methodik  , die insbesondere auf kurze Entwicklungszyklen ausgerichtet ist.

Mit Scrum wird man nie fertig werden, "weil es mehr ist als eine Methode für die Softwareentwicklung", weiß Dirk Lässig , Business Director Agile Consulting bei Valtech   . Es ist auch ein "Werkzeug für Veränderung in einer Organisation". Doch so werde es in der Industrie und generell meistens nicht verstanden, schränkt er ein. Stattdessen herrsche oft die Denkweise vor, mit Scrum arbeiten die Entwicklungsteams und so werde das Problem gelöst. "Doch das ist nicht alles", argumentiert Lässig.

Auch Stefan Pabst von der Interaktiv-Agentur Webit    klagt, dass sich Scrum noch immer - nur - in der Entwicklernische befindet. Er ist aber überzeugt, dass Scrum immer mehr aus der Ecke herauskommen muss und werde. Wichtigste Voraussetzung dafür: Menschen und Strukturen müssen geeignet sein für agile Methoden. Dies sei in Behörden beispielsweise eher nicht der Fall - hier bleibe wenig Spielraum für Denken und Handeln. Doch genau darum geht es bei Scrum: "zyklisch und iteratives Arbeiten und Optimieren."

Sieben Scrum-Erkenntnisse haben sich in den vergangenen Jahren herauskristallisiert. Sie zeigen, wie Internetunternehmen agile Methode effizient einsetzen können:

1. Mit Scrum werden die Schwachstellen offengelegt

Scrum wird viele Probleme innerhalb der Organisation aufdecken - es legt offen, warum Dinge nicht fertig werden, oder nicht so "smooth" laufen wie sie laufen sollten. "Oft wird Scrum dafür verantwortlich gemacht und nur eingeschränkt verwendet", resümiert Lässig.

Doch wer mit Scrum in regelmäßigen Abständen fertige Software liefern will, muss alles mit einbeziehen, was sich rund um die Wertschöpfungskette tut - gemeint sind die Kreation, die Integration oder der Test. "Wenn ich Scrum nur auf die Softwareentwicklung begrenze, dann habe ich die angrenzenden Bereiche ausgespart", sagt Lässig. Doch dann werde es eigentlich spannend, denn hier muss man "crossfunktionale Teams" bilden, um am Ende fertige Software zu haben. Verbindet sich Scrum mit Experience Design wird dies agile Experience Design genannt. "Ein spannendes Feld, bei dem man eine Brücke schlagen muss." Spricht man über Effizienz, dann sieht die Herausforderung in etwa wie folgt aus: Das Time to Market verkürzt, das Return on Investment erfolgt schneller.

2. Der Overhead von Scrum ist manchmal zu groß

Das Projekt muss eine gewisse Größe haben, ist Stefan Queißer , Geschäftsführer von Ostec   überzeugt. Eine der Faustregeln sei hier: mindestens 100.000 Euro als Projektbudget. "Wenn das Projekt zu klein ist, produziert Scrum oft einen zu großen Overhead als dass es noch effizient ist", weiß Queißer. Weiterhin habe das Projektteam im Idealfall 5 bis 8 Mitglieder. Bei beispielsweise drei Teammitgliedern könne man ohnehin alle Rollen besetzen.

Das Management muss die Augen auf machen und genau auf die Hindernisse achten, die in einem Sprint auftreten können, aber vom Scrum Master nicht behandelt werden können, weil sie organisatorischer Art sind, macht Lässig klar. Es gilt Sensoren dafür zu haben, um den Entwicklungsprozess kontinuierlich zu verbessern.

Oftmals könne man beobachten, dass das Management Scrum einsetzen möchte und einen Mitarbeiter zum Scrum-Master ausbilden lässt, der dann alles regeln soll. "Das geht schnell schief, da es an Akzeptanz fehlt", weiß Lässig. Wichtig sei es "die Einführung von Scrum gut vorzubereiten, sich entsprechend Zeit zu geben und genügend Ressourcen für Fortbildung zur Verfügung zu stellen". Eine Binsenweisheit? Mitnichten, denn wer nur sagt er macht Scrum, wird keine Effizienz erreichen. Es muss wirklich und ehrlich eingesetzt werden. Mit allen Konsequenzen wie etwa den Abbau von Hierarchien.

Das passiert bei Webit seit nunmehr fünf Jahren. Seither wurde nach eigener Aussage ein Qualitätssprung erreicht - organisatorisch wie auch vom Ergebnis her. Zwar sei das Teilen von Wissen sowie das Nichtbeharren auf Machtpositionen seit jeher das Motto der Interaktivagentur, aber durch die agile Methode habe sich dies noch weiter potenziert. Unterm Strich, so bilanziert Pabst, "wiegen die internen Verbesserungen den Overhead durch die Aufklärungsarbeit bei den Kunden auf."

Studienergebnisse von Status Quo Agile

Agile Methoden werden mehrheitlich mit klassischen Methoden kombiniert ("Sowohl-als-auch-Nutzung" oder Mischform) Die Nutzung agiler Methoden geht mit einer wesentlich veränderungsorientierteren Unternehmenskultur einher Fast ein Viertel der Anwender, die agile Methoden einsetzen, tun dies im Non-IT-Bereich Kanban, Extreme Programming und insbesondere Scrum sind die verbreitetsten agilen Methoden Scrum wird von durchgängig agilen Nutzern zu 100 Prozent als gut oder sehr gut bewertet. Umsteiger auf agile Methoden sehen deutliche Verbesserungen bei der Erfolgsquote Die Anwender agiler Projektmanagement-Methoden bewerten die von ihnen genutzten Praktiken in allen Kriterien (Gesamtbewertung, Termintreue, Mitarbeiterzufriedenheit...) besser als die Anwender klassischer Projektmanagement-Methoden. Dies gilt nicht nur für jedes einzelne Kriterium, sondern auch in allen direkten Vergleichen (klassisches Projektmanagement zu durchgängig agil, Sowohl-als-auch-Anwendung, Mischformen) Nur 5 Prozent der Nutzer agiler Methoden sehen keine Verbesserungen bei Ergebnissen und Effizienz. Quelle: Studie Status Quo Agile, Hochschule Koblenz

3. Eine Frage der Unternehmens-Philosophie

Für Stefan Pabst ist die Arbeit nach Scrum-Maßstäben eine Philosophiefrage: "Man muss sich gedanklich darauf einstellen, dass man durch agiles Arbeiten auf bestimmte Dinge verzichten muss, die im Vorfeld geplant waren", sagt Pabst. Dafür erfahre man aber neue Dinge, die zuvor nicht eingeplant wurden. Aus seiner Sicht sind die Strukturen in den Unternehmen bei weitem nicht so weit gediehen, um Scrum effizient zu nutzen. "Aber natürlich lassen sich die Partner nicht nach ihren Vorkenntnissen bei den agilen Methoden aussuchen", ist Pabst realistisch.

Handle es sich etwa um einen öffentlichen Auftraggeber, dessen innere Struktur von einer starken Hierarchie geprägt ist und der gezwungen ist ein Lastenheft zu führen, versucht Webit trotzdem intern agil zu arbeiten. "Wir versuchen die Anforderungen des Kunden zu abstrahieren, granular zu gestalten, Kanban einzusetzen und agil zu entwickeln", bestätigt Pabst.

4. Wie Agenturen mit Scrum gesteuert werden

Wenn Kunden eine ECommerce-Implementierung zum Festpreis beauftragen, sollten Agenturen den Kunden davon überzeugen, "dass es keine gute Idee ist, die Implementierung in einen festen Vertrag zu gießen", betont Lässig. Zu viele Ideen seien noch gar nicht durchdacht, weil keiner in diesem Stadium genau beschreiben kann was zu tun ist, macht Lässig klar.

Der Kunde hat ein Ziel, das er erreichen möchte, und dabei hilft die agile Entwicklung. Aber was im Einzelnen der Kunde genau will ist vorab noch nicht klar. Um dies herauszufinden biete sich eine "kollaborative Phase" an, die aus dem agilen bekannte Artefakte erzeugt. Es müsse geklärt werden, "welche Features genau dazu beitragen, die Kundenziele zu erreichen", so der Mann von Valtech. Mit dieser Inception bekommt der Kunde Sicherheit und einen Eindruck darüber, wie gearbeitet wird, "nämlich kollaborativer", fasst Lässig zusammen. Weniger sinnvoll sei es daher einen Festpreis anzupeilen, als vielmehr in einen agilen Modus zu wechseln.

Wenn Agenturen mit Scrum arbeiten, hat Pascal Klaus , freiberuflicher Projektleiter E-Commerce bei Otto Group, drei Varianten skizziert:

1. Agentur ist Teil eines Scrum-Teams: Agentur wird nach Tagessatz bezahlt. Kontrolle durch das Team.
2. Agentur bekommt abgegrenzte Aufgabe=> Sie entscheidet selber wie sie vorgeht, rechnet klassisch ab.
3. Agentur und Unternehmen einigen sich darauf, wo es hingehen soll und stecken die Randbedingungen ab, inklusive Scrum als Vorgehensmodell.

Idealerweise komme der Product Owner aus dem Unternehmen oder es findet eine enge Abstimmung des Product Owner mit dem Unternehmen statt. Es gibt kurze Rechnungsläufe, eine große Offenheit und die Abrechnung erfolgt nach Tagessätzen, zudem ist das Taskboard für den Auftraggeber jederzeit einsehbar, bringt es Klaus auf den Punkt. Die Entwicklung sollte außerdem beim Auftraggeber stattfinden, um nicht in das Risiko zu laufen, dass parallel andere Aktivitäten durchgeführt werden. "Für Auftraggeber, die es gewohnt sind Agenturen stark im Preis zu drücken indem sie kleinere Fehler suchen, ist Scrum nicht geeignet", legt sich der ECommerce-Projektleiter fest.

Wenn Scrum in Agenturen eingesetzt wird, muss der Kunde mitmachen und sich auf den Prozess einlassen, unterstreicht Queißer. Zwar könne man Scrum auch ohne Wissen des Kunden machen, aber wenn man beispielsweise Zwei-Wochen-Sprints hat, komme es schon mal vor, "dass der Kunde am zweiten Sprinttag eine Änderung wünscht und man diese erst nach zwei Wochen bearbeitet", macht Queißer klar. Das könne dann schnell etwas "unflexibel wirken" und setze ein "gewisses Maß an Fingerspitzengefühl" beim Product Owner voraus.

Queißer macht auch deutlich, dass der Einsatz von Scrum in Agenturen "besondere Anforderungen an die Angebotserstellung und Rechnungslegung" erfordert. Über die Zeit suchten zwar immer mehr Firmen direkt nach Agenturen, die Scrum einsetzen. In alt eingesessenen Unternehmen sei es aber trotzdem oft noch so, "dass der Einkauf die Verhandlungen über Preise und Modalitäten führt und erstmal gar nicht weiß, wie mit Scrum umzugehen ist." Dann weiche das Angebot und die offiziellen Anforderungskriterien oft von den tatsächlichen ab, "damit zum einen der Einkauf glücklich ist und der Projektmanager auf Kundenseite eine moderne Produktentwicklungsmethode nutzen kann", so Queißer.

Glossar zur agilen Gegenwart

Agiles Manifest  : 2001 verfasste Prinzipien zur agilen Softwareentwicklung, zunächst von 17, heute von mehr als 1000 Personen unterzeichnet und in mehreren Sprachen übersetzt. Design Thinking: Nutzerorientierter Ansatz zur kreativen Problemlösung und zur Entwicklung von Innovationen durch interdisziplinäre Teams. Product Owner: Person, die die Business-Seite in Scrum vertritt und durch das zu entwickelnde Produkt einen Mehrwert erreichen will. Scrum: Rahmenwerk für ein Vorgehen in der agilen Softwareentwicklung und Werkzeug zum Verändern von Organisationen. Wichtige Merkmale sind die Arbeit in selbst organisierten, interdisziplinären Teams, die kontinuierliche Prozessverbesserung sowie häufiges Feedback vom Kunden. Sprint: Festgelegter Zeitraum, in dem ein Scrum-Team die Lösung für eine bestimmte Aufgabe erarbeitet. Während dieses Zeitrahmens darf niemand in den Lösungsprozess eingreifen. Quelle: Valtech

5. Keine Qualitätsunterschiede bei Frontend- und Backend-Entwicklung

In seiner persönlichen Historie konnte Pascal Klaus "keinen Qualitätsunterschied in der Entwicklung von Front- oder Backends mit Scrum ausmachen." Teilweise, bestätigt Klaus, würden bei der Backend-Entwicklung "spezialisiertere Technologien eingesetzt", weswegen der klassische Scrum-Ansatz nicht greifen würde, dass jeder sich einen beliebigen Task ziehen könnte. Eventuell gebe es für eine bestimmte Story nur einen oder zwei Entwickler, die mit der Technologie umgehen können. "Zu Problemen hat das bislang jedoch noch nicht geführt", sagt Klaus. Im Betriebsbereich einer Applikation wiederum eigne sich Scrum weniger. Hier komme häufiger Kanban zum Einsatz, weiß der Spezialist von Otto.

Für Lässig steht fest: Je mehr Aktivität man hineinzieht in den Sprint, umso agiler wird die Organisation. Schon aus dieser Betrachtung heraus ergibt sich, dass es reichlich "suboptimal" ist, wenn die eine Agentur die Softwareentwicklung macht und die andere das Kreative. Designer sollten bei jedem Sprint mitarbeiten, so Lässig.

Allerdings sei auch klar, dass es im Backend andere Herausforderungen gibt als im Frontend, wie etwa die Integration mit anderen Systemen. Doch aus Lässigs Erfahrung heraus geht der Trend dahin, "dass man Partnerprojekte hat, die auch agil entwickelt werden." Zwar gebe es noch immer die schwierigen Integrationsphasen, aber insgesamt würden die parallelen Projekte kompatibler, bestätigt Lässig.

Im Optimalfall sei der Designer des Frontends komplett in das Scrum-Team integriert und arbeitet im Sprint-Rhythmus mit, bestätigt auch Queißer. Doch die Realität sieht meist anders aus: "Das Design ist schon fertig, bevor ein Team mit der Umsetzung anfängt." Aus Scrum-Sicht sei das zwar alles andere als optimal "aber Designer tun sich manchmal etwas schwer mit Scrum", macht der Mann von Ostec klar. Wenn man ein Team soweit hat, dass der Designer sich voll integrieren kann, sei das "fast schon der heilige Gral von Scrum."
Ansonsten sieht Queißer wenig grundsätzliche Unterschiede bei Qualität und Effizienz zwischen Front- und Backend. Es sei insgesamt nicht ganz so entscheidend, was für ein Team Scrum einsetzt. Wichtiger sei in jedem Fall, "dass Scrum richtig eingesetzt wird." So gebe es beispielsweise auch Marketing-Teams die Scrum einsetzen und damit extrem erfolgreich sind. Scrum sei eben eine Produktentwicklungsmethode und als Framework anzusehen, meint Queißer.

6. Aufklärung statt Ideologisierung

Statt Grenzen und Fallstricke sieht der Mann von Valtech in Srum vor allem eine Herausforderung. Gleichwohl weiß er, dass Fallstricke drohen, wenn die organisatorischen Veränderungen nicht beachtet werden und Scrum auf eine reine Entwicklung beschränkt wird, ohne die gesamte Wertschöpfungskette mit einzubeziehen.

Er plädiert daher für mehr Aufklärung, damit die klare Zielrichtung und der Effekt von Scrum deutlicher werden. "Es gibt noch genug vorgefertigte Ansichten zu dem Thema".
Auf der anderen Seite sieht Lässig die Gefahr, dass Scrum zu ideologisiert betrachtet wird. Wer nur predige, hole aber die Leute nicht ab. "Man muss Scrum verstehen, Agilität zu verkünden ist der falsche Ansatz."

7. Was nach Scrum folgt

Pascal Klaus hält Scrum nicht für ein Allheilmittel. Es eigne sich "einfach nur für bestimmte Zwecke." Unternehmen passen Scrum ihrem Unternehmen an. Oftmals führe es auch dazu, "dass Scrum der agile Nukleus ist, um die Agilität in das Unternehmen zu führen. Von der IT ins Management." So könnte darin vielleicht die Weiterentwicklung liegen, mutmaßt der ECommerce-Experte. "Agile Management-Methoden, die ins Marketing und in den Vertrieb diffundieren."
Wenn 100 oder 1000 Leute ein Produkt entwickeln, dann handelt es sich um Large-Scale-Scrum, gewissermaßen die nächste Entwicklungsstufe von Scrum. Die Herausforderung bei Large-Scale-Scrum liegt darin, über die Teamgrenzen hinaus zu gehen, bestätigt Lässig. Verschiedene Teams arbeiten disziplinübergreifend zusammen an einem Produkt. Die Wertschöpfungskette wird damit deutlich erweitert.

Stefan Pabst sieht Probleme bereits in mittelgroßen Projekte, wenn es beispielsweise zwischen einer klassischen Leadagentur und der ausführenden Internetagentur Kompetenzgerangel gibt. "Hier stoßen die agilen Methoden oft an ihre Grenzen, weil eine Leadagentur, die im klassischen Denken verharrt, generell dem agilen Denken entgegensteht", sagt Pabst, der aber zuversichtlich ist, dass sich auch diese klassischen Agenturen zunehmend verändern werden, schon deshalb weil sich ihre Aufgaben mit denen der Internetagenturen immer stärker verzahnen werden.

Seine Prognose: Agile Methoden werden in zehn Jahren zum Normalfall gehören.