Agiler ohne Scrum - kann das funktionieren?
Viele Menschen verbinden das Stichwort „Agilität“ automatisch mit dem Begriff Scrum. Obwohl beides natürlich oft in Zusammenhang steht und obwohl Scrum wohl der bekannteste agile Ansatz ist, geht Agilität auch ohne Scrum. Mit diesem Thema hat sich Jürgen Knuplesch auf der Plattform Entwickler.de beschäftigt. Im Rahmen einer Serie von Artikeln über Scrum und agiles Arbeiten erzählt Jürgen Knuplesch beispielhafte Geschichten, anhand derer er seine Überzeugungen vermittelt. Wir fassen im Folgenden seinen Artikel für Sie zusammen.
Der Mensch und der Markt
Jürgen Knuplesch beginnt seinen Artikel mit dem Postulat, dass Komplexität ein Maß für Vorhersagbarkeit, nicht aber für Verständlichkeit ist. Menschen sind komplex: Sie sind anpassungsfähig, aber handeln nicht unbedingt vorhersehbar. Ein Mensch kann auf denselben Reiz zweimal sehr unterschiedlich reagieren, weil er lernt und sich anpasst. Stellen Sie sich vor, ein fünfjähriges Kind nennt Sie einen Idioten. Da reagieren Sie sicher ganz anders, als wenn dies ein gleichaltriger Arbeitskollege tut. Es kommt also immer auf den Kontext an. Eine allgemeingültige Antwort auf die Frage: „Wie reagieren Sie, wenn Sie jemand Idiot nennt?“ gibt es also nicht.
Ebenso wie der Mensch ist auch der Markt ein komplexes adaptives System. Kommt ein neues Produkt auf den Markt, reagieren Mitbewerber oft schnell darauf und entwickeln Produkte, die damit konkurrieren können. Hier setzt Jürgen Knuplesch an, denn für ihn verhält es sich mit agiler Beratung genauso. Hier wird auf die Selbstorganisation im Team gesetzt, weil das Team besser als ein Scrum Master den Kontext beurteilen kann.
Ebenso wie der Mensch ist auch der Markt ein komplexes adaptives System. Kommt ein neues Produkt auf den Markt, reagieren Mitbewerber oft schnell darauf und entwickeln Produkte, die damit konkurrieren können. Hier setzt Jürgen Knuplesch an, denn für ihn verhält es sich mit agiler Beratung genauso. Hier wird auf die Selbstorganisation im Team gesetzt, weil das Team besser als ein Scrum Master den Kontext beurteilen kann.
Anpassung an komplexe Systeme
Es gab in der Vergangenheit schon sehr viele Versuche, einen allgemeingültigen und überall anwendbaren Ansatz für die Abwicklung komplexer Projekte zu finden. Und die Bemühungen gehen weiter, denn auch wenn viele Manager bereits einen Weg gefunden haben und eine Methode bevorzugt anwenden, so ist ein perfekter und unanfechtbarer Weg einfach nicht vorhanden. Die Erfinder des Scrum wollen eher, dass Scrum als ein Framework, nicht zwingend als ein Prozess, wahrgenommen und bezeichnet wird. Hier spielt auch der eben erwähnte Kontext eine entscheidende Rolle. Scrum war von vornherein dazu gedacht, sich Schritt für Schritt dem jeweiligen Kontext anzunähern und eine von diesem Kontext abhängige Lösung zu finden. Kontinuierliche Veränderung ist die Lösung. Jürgen Knuplesch betont an dieser Stelle, dass die schlichte Einführung von Scrum ein Unternehmen nicht automatisch zu einem agilen Unternehmen macht. Scrum kann für agile Methoden eingesetzt werden – muss aber nicht.
Eine Cash Cow hat Langeweile
Hier beginnt Jürgen Knuplesch, eine seiner lehrreichen Geschichten zu erzählen. Es geht um ein Team, das an einem Produkt arbeitet, welches von vielen Kunden bereits länger genutzt wird. Das Team beschäftigt sich mit der Bearbeitung von bekannten Bugs, entdeckt neue Bugs und bearbeitet auch diese. Es finden fortwährend Tests statt. Routineaufgaben. Bugs reduzieren. Alle sind gelangweilt. Wie kann hier noch motiviert werden? Was kann der Manager sagen, um das Team zu begeistern? Der Manager, den sich Jürgen Knuplesch ausgedacht hat, nimmt die Herausforderung an und erinnert sein Team daran, dass die Wartungsverträge die Cash Cow des Unternehmens sind. Das Team, das die Bugs reduziert, verdient die Brötchen für die ganze Firma. Es macht den Weg frei für die Neuentwicklung und Innovation, wo (noch) keine Brötchen verdient werden. Jürgen Knuplesch möchte, dass sein imaginäres Team sich nicht als die armen Opfer sieht, welche die langweiligen Aufgaben übernehmen müssen, sondern als die Helden der Firma, welche die Existenz aller sichern. Bei jeder Gelegenheit weist der Manager sein Team auf diese Tatsache hin. Er unterbreitet seine Sichtweise auch den Neuentwicklern, die sich gerne in einer privilegierten Position sehen. Ein Ansatz, der Früchte trägt. Eine gute Idee.
Der Manager betrachtet den Prozess der Bug-Reduzierung und will, dass sein Team damit aufhört, die Realität an die Prozesse anzupassen, sondern sich so zu organisieren, dass es der Realität besser entspricht. Jeder Bereich hat einen Entwickler. Das Ideal der crossfunktionalen Gewaltenteilung wird weiterhin verfolgt. Aber die Aufgaben sind einfach zu gewaltig für die Anzahl an Entwicklern. Kein unrealistisches Szenario. Alle Entwickler sind sich darüber im Klaren, dass es viel zu viel Arbeit gibt.
Es wird gemeinsam mit dem Product Owner entschieden, die Backlogs personenbezogen umzuplanen. Nicht ideal, aber es zeigt Erfolg. Der Backlog wird etwas übersichtlicher und die Priorisierung ist klarer. Leider ist der Product Owner wegen mangelnder Kenntnisse im Bereich der Entwicklung keine wirkliche Hilfe. Er kann nur aus der Sicht des Kunden die Prioritäten erkennen, was die Absprache mit den Entwicklern manchmal erschwert. Dies bringt eine höhere Verantwortung für die Entwickler mit sich. Damit verabschiedet sich das Team von Scrum. Patch Inkremente werden allein durch den Termin bestimmt, der mit dem Kunden ausgehandelt wurde. Patch Manager und Product Owner arbeiten eng zusammen. Aber mit Scrum hat das alles nicht mehr viel zu tun. Aber: was wirkt, das muss als positiv betrachtet werden.
Was Jürgen Knuplesch mit seiner Geschichte klar machen will, ist, dass Scrum nicht als oberste Direktive betrachtet werden darf. Scrum ist ein gutes Konzept, das oft zum Ziel führt. Aber ungewöhnliche Umstände erfordern ungewöhnliche Maßnahmen. Manchmal fordern sogar ganz normale Umstände ungewöhnliche Maßnahmen. Zu viel Arbeit, zu wenige Leute, zu viel Stress. Der Mensch ist ja bekanntermaßen ein adaptives System, das sich anpassen kann. In gewisser Weise ist die Abkehr von Scrum in manchen Situationen sogar noch agiler als der Einsatz von Scrum.
Der Manager betrachtet den Prozess der Bug-Reduzierung und will, dass sein Team damit aufhört, die Realität an die Prozesse anzupassen, sondern sich so zu organisieren, dass es der Realität besser entspricht. Jeder Bereich hat einen Entwickler. Das Ideal der crossfunktionalen Gewaltenteilung wird weiterhin verfolgt. Aber die Aufgaben sind einfach zu gewaltig für die Anzahl an Entwicklern. Kein unrealistisches Szenario. Alle Entwickler sind sich darüber im Klaren, dass es viel zu viel Arbeit gibt.
Es wird gemeinsam mit dem Product Owner entschieden, die Backlogs personenbezogen umzuplanen. Nicht ideal, aber es zeigt Erfolg. Der Backlog wird etwas übersichtlicher und die Priorisierung ist klarer. Leider ist der Product Owner wegen mangelnder Kenntnisse im Bereich der Entwicklung keine wirkliche Hilfe. Er kann nur aus der Sicht des Kunden die Prioritäten erkennen, was die Absprache mit den Entwicklern manchmal erschwert. Dies bringt eine höhere Verantwortung für die Entwickler mit sich. Damit verabschiedet sich das Team von Scrum. Patch Inkremente werden allein durch den Termin bestimmt, der mit dem Kunden ausgehandelt wurde. Patch Manager und Product Owner arbeiten eng zusammen. Aber mit Scrum hat das alles nicht mehr viel zu tun. Aber: was wirkt, das muss als positiv betrachtet werden.
Was Jürgen Knuplesch mit seiner Geschichte klar machen will, ist, dass Scrum nicht als oberste Direktive betrachtet werden darf. Scrum ist ein gutes Konzept, das oft zum Ziel führt. Aber ungewöhnliche Umstände erfordern ungewöhnliche Maßnahmen. Manchmal fordern sogar ganz normale Umstände ungewöhnliche Maßnahmen. Zu viel Arbeit, zu wenige Leute, zu viel Stress. Der Mensch ist ja bekanntermaßen ein adaptives System, das sich anpassen kann. In gewisser Weise ist die Abkehr von Scrum in manchen Situationen sogar noch agiler als der Einsatz von Scrum.
Autorin: IAPM intern
Schlagworte: Agiles Projektmanagement, Scrum, Führungskultur