Mit Methode zum agilen Unternehmen.

Wenn es um agile Modelle geht, jagt ein Schlagwort das nächste. Scrum, SAFe, DevOps: Im Wettbewerb der Frameworks und kulturellen Ansätze geht es um eine kluge Auswahl und eine unabhängige Entscheidung. Welche Kriterien spielen eine Rolle? Wie erzielt man ein Höchstmaß an Flexibilität und Skalierbarkeit? Wie vermittelt man jenseits von Methoden und Tools zentrale Prinzipien und Werte?

Damit Agilität nachhaltig gelebt wird.

Agil im Großen: Das richtige Framework für Sie.

SAFe, LeSS, Agile Scaling Cycle oder Spotify Engineering Culture: Es mangelt nicht an Alternativen, wenn es um Skalierungs-Frameworks für Großunternehmen geht. Aber welches ist für welchen Bedarf tatsächlich geeignet? Patrick Daut, Management Consultant, stellt Quervergleiche der vier Frameworks an, durchleuchtet ihre Gemeinsamkeiten und Unterschiede und entwickelt die wichtigsten Kriterien zu Auswahl. Denn so oder so: Auch Großunternehmen müssen schneller und flexibler werden, um immer dynamischere Märkte zu bedienen.

Ihr Ansprechpartner:
Patrick Daut
Management Consultant 
agile(@)no-spam.cassini.de 

Kanban und Scrum: Wenn sich Lean und Agile treffen.

Scrum oder Kanban? Die Anwendungsbereiche beider Modelle lassen sich nicht scharf voneinander trennen, denn es gibt zahlreiche Übergänge. Dies beleuchten die beiden Cassini Berater Patrick Daut und Peter Kalvelage. Sie raten dazu, zwischen beiden Methoden zu wechseln – wenn es Sinn macht.

Mehr erfahren

Herr Daut, Herr Kalvelage: Worin unterscheiden sich Scrum und Kanban?
Kalvelage: Scrum gibt ein komplettes Framework vor. Die Rollen zur Erreichung des Ziels sind definiert, der Ablauf ist vorgegeben – genau wie die Artefakte, die an bestimmten Punkten im Zeitverlauf entstehen. Ein Scrum-Team hat also einen klaren Orientierungsrahmen ...

Daut:
... während Kanban nun mal kein Framework, sondern ein Ansatz zur Prozessoptimierung ist, der sich an den klassischen Lean-Prinzipien orientiert. Am Anfang steht der aktuell in der Organisation gelebte Prozess, über den im ersten Schritt Transparenz hergestellt wird. Zur Visualisierung dient das bekannte Kanban-Board. Hat man den Prozess soweit im Griff, verbessert man ihn schrittweise, so dass immer weniger „Waste“ – vor allem in Form von Wartezeiten – entsteht.

Welche Einflussfaktoren sind bei der Entscheidung für die eine oder die andere Methode ausschlaggebend?
Daut:
Man muss den konkreten Fall betrachten. Grundsätzlich kann man sagen: Bei Scrum steht das Produkt und seine wertmaximierende Entwicklung im Vordergrund. Die agilen Prinzipien werden über konkrete Vorgaben umgesetzt. Kanban hat das Ziel effektiverer Abläufe durch die Anwendung möglichst schlanker Grundsätze. Im Zentrum stehen das Pull- und Flussprinzip. Deshalb wird Kanban oft in Betriebssituationen mit wiederkehrenden Prozessen und kleineren Aufgaben eingesetzt. Scrum dagegen bei komplexeren Projekten und in der Produktentwicklung.

Kalvelage: Wobei sich die Methoden im Laufe der Evolution eines Teams abwechseln können...

Daut: Warum auch nicht? Es ist durchaus möglich, zunächst Scrum einzuführen, um mit Hilfe des definierten Frameworks agile Denkweisen zu etablieren. Mit zunehmender Reife des Teams kann ein Wechsel zu Kanban eine größere Flexibilität ermöglichen. Oder man setzt Kanban ein, um von Scrum ausgehend den Arbeitsprozess weiterzuentwickeln. Es gibt also fließende Übergänge.

Kalvelage: Wie fließend sie sind, zeigt sich darin, dass Kanban theoretisch umgekehrt auch zu Scrum führen kann. Optimiert man einen gegebenen Prozess mit Kanban und stellt fest, dass es Sinn macht, bestimmte Rollen einzuführen – wie einen Scrum Master oder Product Owner –, kann man bei Scrum landen. Wenn man so will, kann man Kanban als ein Metaframework bezeichnen.

Daut: Genauso kann ein erfahrener Scrum-Master auf die Visualisierungsmethode des Kanban-Boards zurückgreifen oder Scrum nach Kanban-Prinzipien verändern – das Framework also verlassen. Diese Übergänge zeigen, dass das agile Scrum und das von Lean-Prinzipien abstammende Kanban analoge Ziele verfolgen.

Welche Methode lässt sich einfacher einführen?
Daut: Das lässt sich nicht pauschal beantworten. Meiner Erfahrung nach lässt sich aus einer Organisation mit funktional getrennten Abteilungen deutlich einfacher eine Struktur mit interdisziplinären Scrum-Teams bilden, wozu z.B. Anforderungsentwickler, Softwareentwickler und Tester gehören. Möchte man ein komplexes Produkt mit Kanban entwickeln, empfehle ich reifere Teams: Hat sich die Gruppe bereits gefunden und das Pull- und Flussprinzip verinnerlicht, ist die Gefahr deutlich geringer, am Ende ein Kanban-Board ohne merklichen Nutzen zu haben. Hellhörig werde ich bei Kanban-Einführungen, wenn sich die Karten nicht schnell über das Board bewegen. Das ist ein deutlicher Hinweis darauf, dass die Prinzipien noch nicht gelebt werden.

Kalvelage: Kanban macht Sinn, wenn die Arbeit durch einen Prozess fließt und am Kanban-Board visualisiert werden kann. Um Verschwendung zu optimieren, muss man die einzelnen Schritte messen können. Das heißt, größere Aufgaben oder zu implementierende Funktionalitäten müssen in Teile zerlegt werden, die weiterhin sinnvoll nutzbar bleiben. Keine leichte Aufgabe, die Übung erfordert. Reichen die Fähigkeiten dafür noch nicht aus, kann der Sprint im Scrum-Framework als Begrenzung dienen. Setzt man Kanban ein, hat man keine Hilfestellung.

Daut: Ja, bei Kanban muss bereits ein gewisses Verständnis für die Wertstromkette vorhanden sein. Man kontrolliert und optimiert den Prozess mit seinen Einzelschritten. Das Scrum-Team agiert im Rahmen des Frameworks freier und stellt in Iterationen ein Produktinkrement nach dem anderen fertig – was sich übrigens durchaus wieder mit den Einzelschritten bei Kanban vergleichen lässt.

Zu welcher Methode raten Sie bei Innovationsprozessen?


Kalvelage: Von seinem Wesen her zu Scrum, weil es dem Team kreativen Raum lässt, während Kanban eher auf eine Abarbeitung von Teilschritten hinausläuft. Hier müsste erst der Rahmen für Innovation gebaut bzw. der Prozess entsprechend optimiert werden. Scrum baut mehr auf die Erfahrung des konkreten Teams und der weiteren Rollen. Dafür ist man flexibler.

Welche Methode würden Sie als kundenorientierter bezeichnen?

Daut: Scrum beruht auf dem agilen Manifest, das auch das Prinzip Kundenorientierung beinhaltet. Das Framework gibt zu diesem Zweck Meetings und eine explizite Rolle vor. Der Product Owner nimmt die Sicht des Kunden ein und sorgt dafür, dass das Produkt dem Kunden nach jeder Iteration den maximalen Mehrwert bringt.

Kalvelage: Bei Kanban steckt das aber auch drin. Was der Kunde nicht braucht, wäre Verschwendung im Lean-Sinne. Aber tatsächlich müsste man Kanban anpassen – eben durch die Einführung entsprechender Rollen und Meetings. Mit anderen Worten: Kanban hindert einen nicht daran, sich kundenorientiert zu strukturieren. Aber richtig: Scrum bringt das schon mit.

Das klingt danach, als wäre Kanban ziemlich frei einsetzbar.
Kalvelage: Ja, denn Kanban bringt keinen eigenen Prozess mit, sondern nimmt den vorhandenen Prozess auf. Das kann ein Vorteil sein. Die Scrum-Methode hat ganz konkrete Annahmen, die für sehr viele Bereiche passen. Für andere aber nicht. Dann wäre Scrum für die eigene Arbeitsweise ein Regel-Overhead.

Daut: Bei Kanban entwickelt man aus einem gegebenen Prozess seine eigenen Arbeitsweisen. Das führt auch dazu, sich mehr mit den dahinterstehenden elementaren Ideen der Lean-Literatur auseinanderzusetzen.

Ohne die agile bzw. Lean-Kultur im Hintergrund ist alles nichts?

Kalvelage: Bei Scrum besteht die Gefahr, sich in den Vorgaben zu verlieren und die Idee zu vergessen. Deshalb ist es wichtig, sich mit dem agilen Mindset dahinter zu beschäftigen. Kanban zwingt einen schon eher dazu, die Prinzipien zu verinnerlichen. Sonst ist letztlich gar nichts da – außer das Board.

Daut:
Der Kontext muss stimmen. Werden die Leitgedanken von Lean und Agilität nicht verstanden, kann keine der beiden Methoden ihre Vorteile ausspielen. Die Ideen dahinter müssen mittransportiert werden. Werden nur die formalen Elemente umgesetzt, bleibt der Erfolg aus.

Ihr Ansprechpartner:
Peter Kalvelage
Senior Consultant
agile(@)no-spam.cassini.de

 

 

Ihr Ansprechpartner:
Patrick Daut
Management Consultant
agile(@)no-spam.cassini.de 

SAFe oder LeSS? Skalierung im Diskurs.

Wenn Skalierung von Scrum, dann besser SAFe oder LeSS? Gute Frage, der sich auch die beiden Cassini Berater Patrick Daut und Sascha Meyer im Interview stellten. Ein Dialog über die Vor- und Nachteile der beiden Frameworks, mit denen große Organisationen agile Entwicklungsmethoden an ihre Anforderungen anpassen. Es geht um klare Vorgaben, Freiheiten und: Gigantomanie.

Mehr erfahren

Welche zentralen Fragen stellen sich bei der Skalierung von Agilität?

Daut: Zwei Fragen gehören unmittelbar zusammen. Die eine richtet sich auf die Wahl des passenden Frameworks als Tool. Die andere auf die Entwicklung der agilen Kultur im Unternehmen. Beides lässt sich nicht getrennt voneinander betrachten.

Meyer: Darum stelle ich Kunden gleich zu Beginn die Frage: Was erwarten Sie? Was soll am Ende als Ergebnis stehen? Das Skalierungs-Framework selbst ist letztlich nur ein methodisches Stützrad, um Organisationen Agilität beizubringen.

Das Skalierungs-Framework ist also zweitrangig?

Meyer: Ja, aber Frameworks können Unterstützung leisten. Sie geben Mitarbeitern eine Struktur an die Hand und damit Sicherheit. Die würden sie sonst schnell verlieren, was wiederum den Change-Prozess in der agilen Transformation erschweren würde. 

Daut: Da schließe ich mich an, zumal die Einführung des Frameworks als Teil des Veränderungsprozesses auch die agile Kultur im Unternehmen fördern kann. Voraussetzung ist, dass man sich nicht nur auf die Abarbeitung des Handbuchs beschränkt, sondern an der Veränderung des Mindsets arbeitet.

Wenn es um das richtige Skalierungs-Framework geht, welches würden Sie empfehlen: SAFe oder LeSS?

Daut: Das hängt von einer ganzen Reihe von Faktoren ab. Was will man damit erreichen? Wie groß ist die Organisation und welche agilen Erfahrungen liegen bereits vor? SAFe beschreibt sehr klar, wie der Prozess aussieht – mit allen Teilschritten bis zum Ergebnis. Es gibt eine ganze Fülle von Rollen vor und gibt hier Orientierung. SAFe ist sicher von Vorteil für Unternehmen, die mit Agile noch gar keine Erfahrung haben.

Und wie ordnen Sie LeSS ein?

Daut: Bei LeSS hilft es, Agilität schon zu leben. Die Vorgaben sind weniger konkret. SAFe sagt dir, dass du z.B. mit 100 von 300 Mitarbeitern in der Entwicklung ein organisatorisches Konstrukt namens Agile Release Train bilden sollst, das sich in einzelne Themen und vordefinierte Rollen aufsplittet. LeSS ist hier deutlich offener und lässt einem mehr Entscheidungsfreiheiten, was man mit den 300 Mitarbeitern anstellt. Andererseits bedeutet dies auch, eine eigene Vorstellung von der Anpassung zu entwickeln. Aber auch SAFe verlangt im Laufe der Einführung eigene Anpassungsleistungen.

Meyer: Für mich ist die Frage des Einstiegspunktes zentral. Während SAFe mit seinen detaillierten Vorgaben dafür geeignet ist, von Null aus zu skalieren, ermöglicht LeSS eine Skalierung bestehender agiler Strukturen, ohne bereits gelebte Agilität zu gefährden. Für Mitarbeiter, die schon agil sind, kann die Einführung von SAFe viel Overhead bedeuten. Es könnte sie aus ihren agilen Strukturen reißen und sie dadurch ausbremsen. LeSS skaliert die vorhandene Agilität mit. Man entwickelt für die bestehenden Teams eine gemeinsame Sprache und stabile Grundlage, begrenzt sie dabei aber nicht durch neue Vorgaben und Rollen.

Und wer fährt jetzt mit welchem Framework am besten? Gibt es bestimmte LeSS- und SAFe-Branchen?

Daut: Es gibt Branchen, in denen das eine oder andere Framework sinnvoller ist. LeSS passt gut in Branchen wie IT oder E-Commerce, also zu Unternehmen, die es gewohnt sind, sich schneller zu drehen. Der Startpunkt ist hier ein ganz anderer als in klassischen Branchen wie Banken, Versicherungen oder Unternehmen der Ingenieurdisziplinen. Hier findet eher SAFe Anwendung. Dort herrscht oft noch eine strikte Trennung zwischen ganzen Bereichen: Anforderungsmanagement hier, Entwicklung da und Test nochmal separat. Die Abteilungen sind hier in der Ausgangssituation nicht so flexibel miteinander verbunden wie etwa beim E-Commerce. So hat die Komplexität von SAFe durchaus auch den Vorteil, dass es Lösungsideen an die Hand gibt, wie man mit regulatorischen und branchenspezifischen Vorgaben umgehen kann, im Automotive-Bereich beispielsweise, wo Prozessmodelle eingehalten werden müssen.

Meyer: Tatsächlich sind regulatorische Anforderungen ein wesentlicher Punkt: Wie hoch ist mein Bedarf an Governance und Compliance? Wenn ich eher in regulierten Märkten unterwegs bin wie im Finanz-, Automotive- oder öffentlichen Sektor, dann brauche ich eine gewisse Plan- und Nachweisbarkeit. Hier spielt SAFe seine Stärken aus. Organisationen, die eher innovationsgetrieben sind und einen hohen Bedarf an kurzfristiger Flexibilität bei hoher Volatilität im Markt haben, sollten über LeSS nachdenken.

Sehen Sie neben den jeweiligen Vorteilen auch Kritikpunkte bei SAFe bzw. LeSS?

Meyer: Meine Kritik an SAFe ist der Hang zur Gigantomanie in den letzten drei Jahren. Das Framework wurde immer größer und komplexer. Damit sichert Scaled Agile Inc. durch notwendige Lizensierung und Trainings aber schlicht seinen Umsatz. Andererseits ist es das einzige Framework, das für richtig große Organisationen beschrieben wurde, für 100 Entwickler an einem Projekt und mehr. Es ist auch das einzige Framework, das sich mit Fragen wie Budgetierung oder Organisationszuschnitt zumindest beschäftigt hat.

Daut: Mein Hauptkritikpunkt an LeSS ist, dass es für eine richtig große Entwicklungsorganisation zu viel Freiraum und entsprechend zu wenig Führung vorsieht. Eine bewusste Entscheidung. Man muss sich aktiver damit auseinanderzusetzen, was zur agilen Transformation beiträgt. Zumal: Man hat keine andere Wahl, als sich mit agiler Kultur auseinanderzusetzen oder mit dem Produktzuschnitt. Mitarbeiter sind bei LeSS dafür auch deutlich näher am Produkt.

Welche Rolle spielt eine Beratung bei der Entscheidung für oder gegen ein Skalierungs-Framework?

Daut: SAFe und LeSS sind im Grunde Produkte am Markt. Die Entscheidung für ein Framework entwickelt sich bewusst aus Fragen zur Größe der Entwicklungsorganisation, zu Branche und Regulierung, zum angestrebten Produkt und möglichen Teilprodukten sowie zur bestehenden Agile-Reife. Wir helfen dabei, diese Daten zu analysieren und eine Vorgehensweise abzuleiten. Soll es ein bestimmtes Framework sein oder baut man sein eigenes Entwicklungsmodell – unabhängig von Frameworks? 

Meyer: Ein häufiger Fall aus der Praxis ist die Grundsteinlegung mit einem vorgegebenen Framework, das man dann individuell ans Unternehmen anpasst. Ein für das Change-Management wichtiger Aspekt: Die Anpassung des Frameworks erfolgt zusammen mit den Mitarbeitern. Wir begleiten den Prozess mit fachlichem Input und unserer Erfahrung. Wir stellen z.B. Szenarien der Skalierung auf und überprüfen sie gemeinsam mit den Mitarbeitern auf ihre Tragfähigkeit. Wir bieten neutrale Beratung und neutrale Produktauswahl, aber eben auch die Begleitung des eigentlichen Changes. Denn mit einem agilen Framework allein schafft man noch keine agile Kultur. 

Ihr Ansprechpartner:
Patrick Daut
Management Consultant
agile(@)no-spam.cassini.de