Archiv des Autors: joerg.gutsche

Warum ich Scrum liebe

In einer Welt, die von ständiger Veränderung und wachsender Komplexität geprägt ist, bietet Scrum eine klare Struktur, um Projekte agil, transparent und effizient zu gestalten. Als Framework, das auf den Prinzipien des agilen Manifestes basiert, ermöglicht Scrum Teams, nicht nur schneller zu liefern, sondern auch mit Freude und Motivation zu arbeiten. Hier sind die Gründe, warum ich Scrum liebe:

  1. Klarheit und Fokus durch Timeboxing

Scrum unterteilt die Arbeit in Sprints – klar definierte Zeitabschnitte, in denen das Team an konkreten Zielen arbeitet. Dieses Timeboxing schafft Fokus und gibt dem Team ein Gefühl von Dringlichkeit und Klarheit. Es gibt keine endlosen Aufgabenlisten, sondern erreichbare Ziele, die nach zwei bis vier Wochen überprüft werden können.

  1. Transparenz durch tägliche Abstimmung

Die Daily Scrums sind kurz und knackig: Jedes Teammitglied teilt, woran es arbeitet, welche Herausforderungen es hat und was als Nächstes ansteht. Dieser tägliche Austausch fördert eine offene Kommunikation, hält alle auf dem gleichen Stand und hilft, Probleme frühzeitig zu erkennen. Es ist faszinierend, wie viel eine gute Zusammenarbeit bewirken kann, wenn die Informationen frei fließen.

  1. Flexibilität und Anpassungsfähigkeit

Scrum ist dynamisch. Wenn sich Anforderungen ändern – was in der heutigen Welt unvermeidlich ist – bietet Scrum die Flexibilität, darauf einzugehen. Während des Sprint Reviews und der Retrospektive reflektiert das Team, was gut lief, was nicht und wie es sich verbessern kann. Diese kontinuierliche Anpassung führt zu einem stetigen Lern- und Verbesserungsprozess.

  1. Teamarbeit und Empowerment

Eines der schönsten Dinge an Scrum ist die Rolle des Teams. Hier gibt es keine Hierarchien im klassischen Sinne. Das Entwicklungsteam entscheidet selbst, wie es seine Arbeit organisiert, und übernimmt die Verantwortung für die Ergebnisse. Der Scrum Master sorgt dafür, dass Hindernisse beseitigt werden, während der Product Owner die Vision liefert. Dieses Gleichgewicht schafft eine Kultur des Vertrauens und der Eigenverantwortung.

  1. Kundenorientierung

Der Kunde steht im Mittelpunkt von Scrum. Durch das Backlog-Refinement und die regelmäßigen Sprint Reviews wird sichergestellt, dass das Team immer an den wichtigsten Prioritäten arbeitet. Das Ziel ist nicht nur, Aufgaben abzuschließen, sondern echten Mehrwert zu liefern. Diese Kundenorientierung macht die Arbeit bedeutungsvoller.

  1. Lernen aus Fehlern

Scrum ermutigt Teams dazu, Fehler nicht zu fürchten, sondern aus ihnen zu lernen. In der Retrospektive gibt es Raum, um offen über Probleme zu sprechen und Wege zur Verbesserung zu finden. Es geht nicht um Schuldzuweisungen, sondern um Wachstum. Diese Fehlerkultur ist einer der stärksten Treiber für langfristigen Erfolg.

  1. Ein Gefühl von Erfüllung

Am Ende eines Sprints steht ein greifbares Ergebnis: ein Increment, das potenziell lieferbar ist. Dieses regelmäßige Erfolgserlebnis motiviert nicht nur das Team, sondern zeigt auch, dass die Arbeit einen Sinn hat. Es ist unglaublich befriedigend, in kleinen Schritten etwas Großes zu schaffen.

Fazit: Warum Scrum mehr als ein Framework ist

Scrum ist für mich mehr als nur eine Methode zur Projektorganisation – es ist ein Denkansatz, der Kollaboration, Transparenz und kontinuierliche Verbesserung in den Mittelpunkt stellt. In einer Zeit, in der sich Anforderungen ständig ändern, bietet Scrum Stabilität durch Flexibilität. Es zeigt, dass der Weg zum Ziel genauso wichtig ist wie das Ziel selbst – und das macht es so besonders.

Vielleicht liebt ihr Scrum noch nicht oder nicht mehr, weil ihr es schon probiert habt, aber nicht richtig erfolgreich wart?
Ich kann euch versprechen: Wenn ihr es mit mir ausprobiert, werde ich alles daran setzen, dass ihr begeistert und erfolgreich seid. 😊

Nicht schon wieder eine Retrospektive… 😩

Sicher kennt ihr das: Die nächste Retrospektive steht vor der Tür und es geht ein allgemeines Aufseufzen durch den Raum… Vorne werden 2 Linien an die Wand gemalt, 3 Überschriften: „Start, Stop, Continue“. Dann wird nach einem langen Checkin, in dem jeder gefühlt seine Lebensgeschichte erzählt „gebrainstormed“. Die Ergebnisse landen in irgendeinem Tool, in das später niemand mehr reinschauen wird. Bis zur nächsten Retro. Aber auch dann wird niemand mehr auf die Ergebnissee der letzten Retro schauen, es wurde Platz geschaffen für ein neues Meeting…

Ich halte die Retrospektive für eins der wichtigsten Events des Scrum Frameworks. Natürlich geht es in allen Events um Inspect & Adapt. Aber in der Retrospektive steht dies besonders im Vordergrund. Nach jedem Sprint nehmen wir uns die Zeit und schauen, wo man noch Bremsen lösen kann. Wo noch Trainings-/Lernbedarf ist. Wo man sich allgemein verbessern kann. Wo zwischenmenschliche Friktionen aus der Welt geschafft werden müssen, die die Teamperformance negativ beeinflussen.
Was Aufbau und Methodik der Retrospektive anbelangt: Darüber sind ganze Bücher geschrieben worden. Über eins (@DianaLarson: Agile Retrospectives: Making Good Teams Great) haben wir wir erst kürzlich im Linkedin Lean Coffee sprechen können.
Ich denke: Egal, ob man sich hier der Best Practices bedient oder sich im Retromat umschaut oder noch woanders: Das Wichtigste ist eine gute Vorbereitung und das Festhalten der Ergebnisse. Retrospektiven können und sollten abwechslungsreich sein. Langeweile muss nicht sein. Ich persönlich finde es wichtig, während des Sprints ins Team reinzuhorchen und zu schauen, wo denn aktuell Problemfelder vorhanden sind. Dementsprechend bereite ich die Retro vor und wähle Methoden aus.
Oft möchte auch das Team selbst entscheiden, worauf es einen Schwerpunkt legen möchte. Damit man sich trotzdem gut vorbereiten kann, kann man das Team vorher per Umfrage abholen.
In der Retro muss das Team sich sicher fühlen. VEGAS Prinzip (What happens in Vegas, stays in Vegas) kann nicht oft genug betont werden. Um das zu erreichen ist es durchaus auch mal erlaubt, das Büro zu verlassen, um sich mit dem Team im Café um die Ecke, am Rhein oder einem anderen schönen Ort niederzulassen.
Was die Ergebnissicherung betrifft: Ich persönlich bevorzuge, die Action Items aus der Retro, zwei bis drei spezifische messbare, ausführbar, realistisch und terminierte (SMART) Aufgaben, ins Backlog wandern zu lassen mit dem Ziel, sie nicht aus dem Auge zu verlieren und im nächsten Sprint tatsächlich auch anzugehen. Alternativ nimmt man große Stickies und klebt sie auf das Whiteboard in die Nähe des Kanban-Boards, wenn man sich täglich im Büro sieht. Wichtig ist, dass man sie nicht aus dem Blick verliert. Dieser Radiator Effekt ist leider mit den Online Tools etwas verloren gegangen.

Scrum ist tot, es lebe Scrum

“Wir haben uns bewusst gegen Scrum entschieden…”.
“Wir haben Scrum wieder abgeschafft…”.
“Wir haben uns vom Scrum Master getrennt. Der wollte immer ‘Scrum by the book’…”.

2019 habe ich in einer Agentur Scrum eingeführt und bin bei vielen Entwicklern anfangs auf heftigen Widerstand gestoßen.

Was steckt dahinter? Warum ist Scrum in vielen Umgebungen erfolgreich, in anderen nicht? Welche Argumente werden gegen Scrum ins Feld geführt?

“Zu viele Meetings” und ”man bekommt zwischen den Meetings kaum etwas geschafft”, hört man wohl am häufigsten.

Insgesamt kann man beachtlich viel falsch machen, Stefan Wolpers hat einen ganzen Guide darüber verfasst (Scrum Anti-Pattern Guide).

Laut Scrum Guide ist Scrum einfach zu verstehen, aber schwer zu meistern. Wenn ich ehrlich bin, habe ich in meiner Karriere mehr schlechte als gute Implementierungen gesehen.

Als ich in den 90ern Lehrer werden wollte, gab es harte Anforderungen. Für Geschichte war eine alte und eine neue Sprache Pflicht. Englisch Voraussetzung. Ich musste mein Latinum nachholen und mein Schulfranzösisch auffrischen. Neben den Hauptfächern musste ich Pädagogik und Philosophie belegen. Dann die Praktika: Als erstes ein Betriebspraktikum. Dann ein Jahr Foreign Language Assisant an einer Highschool in England. Und schließlich noch eins an einer deutschen Schule. Hätte ich mein Ziel weiterverfolgt, hätte ich noch 2 Jahre Referendariat drauflegen müssen. Hätte ich dann im Unterricht immer alles richtig gemacht? Sicher nicht. Aber ich hatte eine gute Vorbereitung.

Scrum Master kann jeder werden. Die Anforderungen sind nicht hoch. Die meisten waren vorher Projektleiter oder Entwickler. Sie werden auf eine 2-tägige Schulung geschickt – fertig.

Es geht mir nicht darum, Kollegen zu verurteilen. Das liegt mir fern.

Die Menschen sind nicht das Problem – sie tun ihr Bestes. Das Problem ist das System.

Verschlimmernd kommt hinzu, dass junge Kollegen selten einen Mentor haben, der sie begleitet. Scrum Master Prüfung bestanden und los geht’s! Dabei wäre es gerade in der Anfangszeit wichtig, sich Feedback zu holen. Ich hatte auch keinen, aber ich habe mir immer regelmäßig Feedback aus dem Team eingeholt.

Wenn die Menschen keine Erfahrung haben, wirkt sich das natürlich aus, vor allem auf die Scrum Events. Meetings sind schlecht vorbereitet, immer nach Schema F, werden sinnentfremdet oder fallen einfach aus.

Das Daily ist häufig einfach ein 15-minütiges Statusmeeting, in dem die Entwickler dem PO berichten, wo man steht. Dabei soll das Daily ein selbstorganisiertes Meeting der Entwickler sein, in dem man die Arbeit der nächsten 24h organisiert, um dem Sprintziel näher zu kommen.

Das Review Meeting verkommt auch häufig zur bloßen Produktdemo. Oft kommen nicht einmal die Entwickler zu Wort. Dabei haben wir hier die Möglichkeit, Feedback einzuholen. Wir können besprechen, was als nächstes das Wichtigste sein wird, und haben die Möglichkeit uns neu zu orientieren.

Die Retrospektive fällt häufig aus („nicht schon wieder…“) oder sie wird nach Schema F durchgeführt (Was war gut, was war schlecht…). Ich halte die Retrospektive mit am wichtigsten von allen Scrum Events. In allen Events geht es um inspect & adept, vor allem aber in der Retrospektive.

Retrospektiven kann man spannend gestalten. Man findet so viele Anregungen im Netz, angefangen beim Retromat. Auch Spezialliteratur, die sich nur mit diesem Event beschäftig, ist ausreichend vorhanden. Eine gute Idee ist, als Scrum Master hier und da Schwerpunkte zu setzen und Methoden so auszuwählen, dass auf aktuelle Probleme eingegangen werden kann. Wichtig ist, dass am Ende tatsächlich Handlungsanweisungen herauskommen, die SMART (specific, measurable, achievable, realistic, time-bound) sind. Eine gute Idee ist, diese im Backlog anzulegen, um ihre Umsetzung dort zu tracken. Kein Muss, aber sicher eine gute Praxis.

Sprint Plannings verkümmern oft in einem bloßen Anlegen von Unteraufgaben im entsprechenden Taskmanagement Werkzeug, z.B. Jira. Dabei geht es darum, dass das Team nicht nur das WAS, sondern auch das WIE bespricht. Wie setzen wir etwas um? Was gilt es in Bezug auf die Definition of Done zu beachten? Idealerweise sind die Product Backlog Items im Refinement so vorbereitet worden, dass man für solchen Dinge auch wirklich Zeit hat. Bei einer Sprintdauer von 4 Wochen sind für das Planning 8h erlaubt. 8h können sehr lang sein, wenn sie falsch eingesetzt werden. Sie können aber auch lustvoll, voller Kreativität und Energie sein, wenn das Team als Team die Planung des Sprint Backlogs angeht.

Ich muss gestehen, dass ich vieles anfangs selbst nur oberflächlich verstanden habe. Erst in dem Moment, als ich die Rolle des Scrum Masters übernahm und selbst in der Verantwortung stand, habe ich angefangen, mich intensiver mit dem Thema auseinanderzusetzen. Und erst dann ist mir hier und da ein Licht aufgegangen.

Führt man ein Framework ein, sollte es einen bestimmten Zweck erfüllen.

Ich führe in der Software-Entwicklung nicht REACT ein, weil es hip ist, sondern weil es mir viel Arbeit abnimmt, erprobt und qualitativ hochwertig ist. Unter anderem.

Warum ist es eine gute Idee, Scrum einzuführen?

In erster Linie geht es darum, dass das Team zusammen erfolgreich ein Produkt entwickelt. Meistens haben die Mitarbeiter so noch nie zusammengearbeitet. Weder über Gewerkgrenzen hinweg noch innerhalb des Teams. Scrum Werte wie beispielsweise Offenheit sind ihnen fremd und müssen erst gelernt werden. Den Vorteil, den ich in Scrum sehe, sind die fest verankerten Feedbackzyklen. Mit einem unerfahrenen Team würde ich immer versuchen, mich auf eine Sprintlänge von einer Woche zu einigen, um in kurzen Abständen Arbeitsweise prüfen und anpassen zu können.

Des Weiteren ist die Rolle des Scrum Masters fest vorgeschrieben. Er begleitet den Change- und Lernprozess und ist in summa für ihn verantwortlich. Er ist da, um Product Owner und Team zu unterstützen, zu coachen, zu unterweisen.

Wie oft sieht man, dass diese Rolle einfach unbesetzt bleibt. „Nein, den Scrum Master bezahlen wir nicht. Da sehen wir keinen Nutzen.“ „Nein? Ach so, gut ok…“

Erfolg hat viele Gründe. Aber beginnen sollte man mit dem Coach. Hätte Liverpool den Erfolg der letzten Jahre ohne Jürgen Klopp gehabt? Wären wir ohne Nagelsmann nicht wieder in der Vorrunde ausgeschieden? Eine Person, die den Change Prozess begleitet, vorlebt, erklärt, Dinge im Mindset der Menschen ändert, ist immanent wichtig.

Photos by https://unsplash.com/