Schwarze Schafe in der agilen Familie

Haben Sie manchmal den Eindruck, dass täglich neue Methoden und Frameworks rund um agiles Mindset entstehen? Können Sie die Unterschiede zwischen Scrum of Scrums, Scrumban, LeSS, SAFe, Nexus, DAD, Spotify-Modell, DSDM, Kanban oder XP erklären? Selbst wenn, es gibt ein paar schwarze Schafe in der agilen Familie, die in solchen Aufzählungen meist fehlen. Wie so oft sind aber gerade sie höchst interessant, da von ausgesprochen subversivem und ungewöhnlichem Charakter. Ich möchte sie Ihnen heute vorstellen.

1. Breaking Scrum

Scrum ist in Ihrem Team eingeführt, Sie haben übliche Schwierigkeiten überwunden, die Velocity steigt von Sprint zu Sprint und das Team setzt regelmäßig seine User Stories zur Zufriedenheit seiner Stakeholder um?  Dann ist es höchste Zeit, einen Gegenpol zu setzen. Erfolge dürfen in manchen Unternehmen nicht geschehen, sie sind verdächtig, stören die gewohnte Kultur und zeigen zu deutlich das Versagen des restlichen Unternehmens.

Breaking Scrum ist in solchen Situationen jederzeit einsetzbar, dafür sind nicht viele Voraussetzungen notwendig, oft geschieht es sogar von selbst. Der Product Owner wird befördert und hat keine Zeit mehr für das Team. Die Teammitglieder halten sich beim Daily Stand-Up zurück, da die Zusammenarbeit so gut funktioniert, dass der formale Informationsaustausch wenig Mehrwert verspricht. Statt das entwickelte Produkt auszuliefern und Feedback zu erhalten, priorisieren die Auftraggeber User Stories mit geringem Business Value.

Das Zauberwort ist Entropie. Bei Breaking Scrum halten wir uns nicht mehr an die Regeln, wir lassen sie schleifen, die Unordnung im Scrum-Universum nimmt unweigerlich zu. Das Gelernte und bereits Angewendete geht verloren, das Vorgehen wird zur Schablone, die an den Ecken einreißt. Damit können wir dem Team und dem Umfeld zeigen, wie bereits ein paar kleine Änderungen genügen, um die Auswirkungen zu spüren. Diese Abwärtsspirale ist emotional nicht sehr angenehm, hilft aber dabei, in einer späteren Phase agile Prinzipien und die Regeln des Frameworks wieder ernst zu nehmen.

2. Lean Scrum

Dabei handelt es sich um eine Weiterentwicklung von Breaking Scrum. Das Team wendet die Regeln mehr oder weniger formal an, aber mit wenigen konkreten Inhalten. Zum Aufwärmen am besten mit ein oder zwei Sprints, in denen das Team nicht voll ausgelastet ist. Danach geht man dazu über, das Sprint Backlog noch weiter zu reduzieren.

Es ist jederzeit möglich, während eines Sprints eine User Story dazu zu nehmen. Der Bedarf, sie beim Sprint Planning bereits fertig spezifiziert, vom Team verstanden und geschätzt zu haben, besteht daher nicht wirklich. Es könnte auch sein, dass demnächst Bugs entstehen, für die rechtzeitig genügend Zeitpuffer vorzusehen sind – sofern jemand die Anwendung testet und noch Fehler findet. Dafür sorgt ein leeres Sprint Backlog bestens vor.

So kann die Organisation Aufwände für Planung, für Inspect & Adapt einsparen. Das Erarbeiten von Maßnahmen in Retrospektiven erübrigt sich, die Rückschau ist schnell geschehen. Falls der Scrum Master damit nicht glücklich ist, fällt das angesichts der anderen Vorteile nicht allzu sehr ins Gewicht.

Ein Phänomen ist dabei allerdings zu beobachten: Ein Daily Scrum mit leerem Board dauert länger und droht die 15-Minuten-Grenze zu sprengen. Mangels vorliegender Tasks und Aufgaben, welche einen straffen Ablauf ermöglichen, besteht nun eine breit gestreute Variante der Informationsweitergabe, in der jeder die Möglichkeit hat, seine Lieblingsthemen einzubringen. Die Organisation als Ganzes kann so Thema werden, welche Person was gesagt, getan oder vielleicht nicht gemacht hat. Das strukturelle Ermöglichen dieser Kommunikation ist ein weiterer Vorteil von Lean Scrum, da es dafür einen Rahmen bildet.

3. Scrum for Zen

Scrum for Zen entzieht sich der allgemeinen Logik. Es lässt sich nicht erklären, ist unabhängig von Wort und Schriftzeichen. Es geht dabei um Einstellung, um Intuition, es bedeutet, im Einklang mit Scrum zu leben. 

Scrum und fernöstliche Weisheit sind kein Gegensatz. Shu-Ha-Ri, das japanische Konzept „erst lernen, dann loslösen und endlich übertreffen“ ist agilen Teams bekannt. Scrum for Zen entsteht aus der konsequenten Fortführung der Praktiken von Lean Scrum.

Es ermöglicht die Auflösung von Teamgrenzen und die Skalierbarkeit auf eine einzelne Person, was in großen Organisationen die Planung von Teams erleichtert. Aufmerksame Beobachter erkennen es am stets präsenten Scrum-Zen-Board, ein Whiteboard, eine leere Wand, ohne Linien, ohne Spalten oder Überschriften. Das Scrum-Zen-Board kann alles sein, der Meister findet es in seinem Inneren.

Aus den Scrum-Events werden Scrum-Zeremonien. Im Sprint Planning, beim Stand-Up und der Retrospektive achten die Teilnehmer auf Atmung und Haltung. Schweigend meditieren sie, um Scrum vollständig zu erfahren, frei von Ablenkungen des Projektalltags. In Refinements bereiten sie sich auf ihre regelmäßig wiederkehrenden Übungen vor.

Unternehmen, die ihre Kultur in Richtung Scrum for Zen verändern, können damit nach einer Übergangsphase Mitarbeiterfluktuation nachhaltig stoppen, da sie sich ernsthaft um die Weiterentwicklung ihrer Mitarbeiter kümmern und dabei auch ganzheitliche Aspekte berücksichtigen.

4. Scrum Nirvana

Scrum Nirvana ist mehr ein Ziel, das Ende des Leidens, der Austritt aus der Wiederkehr misslungener Projekte, das Loslassen von ungünstigen Rahmenbedingungen, Zielen und Terminen. Der Scrum-Buddha erwacht und versteht, oft erst nach einer endlosen Kette von Bemühungen, fachliche Anforderungen in der Softwareentwicklung zur Zufriedenheit von Auftraggebern und Kunden umzusetzen.

Auf dem edlen zwölffachen Pfad agiler Prinzipien wandelt er als Agile Coach, Agile Catalyst oder Scrum Master. Er lehrt durch sein Beispiel, durch das Tun, durch das Anfangen. Scrum Nirvana ist ein Zustand, den es zu erlangen gilt, kein Framework, keine Methode. Der Weg dazu ist lang und mühsam.

5. Exploratives Requirements Engineering

Sollten Sie mit den vorgestellten Verfahren ihr Ziel, ein gutes Produkt auf den Markt zu bringen, nicht erreichen, können Sie mit einer traditionellen Maßnahme reagieren. Exploratives Requirements Engineering eignet sich besonders, um den Bedarf nach Veränderung so sehr zu steigern, dass der geeignete Zeitpunkt für einen Neuanfang bald erreicht ist.

Es ist eine Methode, mit der Sie ohne viel Vorarbeit beginnen können, diese würde bei der Umsetzung nur belasten. Erstellen Sie spontan Anforderungen, ohne Zusammenhang, einem Muster folgend, das nur Sie erkennen, wenn überhaupt. Variieren Sie dabei Inhalte und Aussagen, erzeugen Sie Stückwerk, halten Sie die Überprüfbarkeit begrenzt.

Es ist ein intuitives Verfahren, eine Technik, mit der Sie unabhängig vom Reifegrad Ihrer Organisation jederzeit beginnen können. Das ehrliche und direkte Feedback von Entwicklern, Testern und Ihren natürlichen Verbündeten, nahestehenden Analytikern und Business Analysten, ist Ihnen sicher. Unabhängig von Methodenstandards und eingeführten Vorgehensmodellen können Sie damit rasch messbare Wirkung in Ihrer Organisation erzeugen.

Conclusio

Für jede neue Methode, jedes Framework, jedes Verfahren, gibt es geeignete Anwendungszwecke. Überlegen Sie sich gut, welche Sie einsetzen wollen, nicht jede wird für Sie und Ihre Situation geeignet sein. Wenn Sie alles selbst gestalten und anpassen möchten, ist die Wahrscheinlichkeit nicht allzu groß, dass Sie den Stein der Weisen finden. Im Zweifelsfall bleiben Sie lieber bei schlanken Verfahren, die sich auf wenigen Seiten beschreiben lassen.

Meine Empfehlung: Identifizieren Sie schwarze Schafe rasch und bleiben Sie bei Scrum, so wie es gedacht ist. Wenden Sie es unverändert an, seinen Ideen folgend. Halten Sie es nach Rückschlägen am Leben und feiern Sie damit Erfolge, bevor Sie versuchen, bei der Einführung agiler Denkweisen zu viele Schritte auf einmal zu machen.