Agile Transformation erörtern

Cases, Trends & Meinungen

Der schlanke Chefkoch.

Um zur schlanken, agilen Organisation zu werden, muss auch das Top-Management Teil einer innovationsgetriebenen Teamkultur sein. So wie es der Chef von Chefkoch ist, Martin Meister – nach anfänglicher Skepsis. Die Geschichte einer dynamischen Zusammenarbeit, die zu rasantem Wachstum führte und das Führungsdenken veränderte. 

Mehr erfahren

Als Martin Meister 2014 den Chefsessel von Chefkoch übernahm, lautete sein Auftrag, das junge digitale Rezeptportal möglichst schnell zu exponentiellem Wachstum zu führen.
Zuvor hatte Gruner + Jahr das Startup übernommen. Mit Meister als Geschäftsführer sollte es nun erwachsen werden und dem Verlagshaus die ersehnten Gewinne bescheren.

Die Organisation stößt an ihre Grenzen.

Meisters Plan: Chefkoch mit neuen Erlösmodellen nach vorne zu bringen und dafür die Geschwindigkeit in der Produktentwicklung radikal zu erhöhen. Ihm war klar, dass damit das bisherige Team aus 30 Mitarbeitern an seine Leitungsgrenze stoßen würde. Chefkoch musste seine Organisation neu erfinden, um seinen ehrgeizigen Wachstumsplänen folgen zu können.

Der Ansatz: Agile Skalierung und Professionalisierung.

Meister wandte sich an Cassini, um den Prozess des organisatorischen Neuaufbaus einzuleiten. Cassini empfahl die Weiterentwicklung agiler, skalierungsfähiger Strukturen und Methoden – mit aller Konsequenz. Teamkultur statt Hierarchie, Selbstorganisation statt Kontrolle, Fehlerprinzip statt Perfektionssinn: Was in Grundzügen vorhanden war, sollte weiter professionalisiert werden. „Agile Werte entsprechen der Kultur von Chefkoch und auch meiner persönlichen Vorstellung von selbstmotivierter, innovationsgetriebener Arbeit. Dies nun konsequent auf den Weg zu bringen, war folgerichtig“, so Meister. Auch wenn das Veränderung bedeutete: „Die Herausforderung bestand in der durchgängigen Umsetzung der agilen Gedanken und Grundsätze in der Organisation und Entwicklungsarbeit“, macht Meister deutlich. Damit verbunden wären umfassende Anpassungen, ohne die jedoch das Ziel einer schnelleren Time-to-Market neuer Erlösmodelle und Produkte kaum zu bewerkstelligen wären. Dass eine ebensolche Beschleunigung im Sinne der kurzfristigen Wachstumsziele von Meister war, machte ihn zum Mentor und Mitstreiter der Veränderung. „Chefkoch und Cassini waren von Anfang an der perfekt Fit.“

Der Prozess der agilen Umgestaltung beginnt.

Es entstand eine enge Zusammenarbeit bei der agilen Transformation. Cassini optimierte Kanban und führte strategisch Scrum ein.
Mitarbeiter in der Entwicklung wurden in Methoden vom Design eines Minimal Valuable Products bis zu zum agilen, automatisierten Testing geschult. Parallel wurde die Führung in ihrem neuen Rollenverständnis von Agile Leadership gecoacht: Wie stärkt man die Selbstorganisationen, wie trägt man zu einer Atmosphäre des Teamspirits und selbstorganisierten Denkens bei, wie weit dürfen Freiräume reichen und wann muss Führung eingreifen? Ein Paradigmenwechsel hielt bei Chefkoch Einzug.

Die Organisation wächst explosiv.

Eine der großen Herausforderungen war der parallel rasant wachsende Personalbestand. In anderthalb Jahren wuchs die Organisation von 30 auf über 100 Mitarbeiter. Dies bedeutete, gleichzeitig mehrere Teams neu aufzubauen. Neue Rollen wurden definiert und besetzt – von Teamleiter über Scrum Master bis zu agilen Software-Entwicklern. Cassini unterstützte dabei das Recruiting und übernahm zwischenzeitlich die Rolle eines Interimsmanagers in den Bereichen Mobile, Scrum Master und QR.  
Innerhalb des Prozesses wurde die agile Organisation immer wieder überprüft, optimiert und feinjustiert, Rollen präzisiert und überdacht. Nach und nach agierte Chefkoch immer eigenständiger und entwickelte eine selbstlernende, bewegliche und trotz des Wachstums schlanke Unternehmenskultur der kurzen Wege: eine Kultur der beschleunigten Innovation.

Mitarbeiter werden zu Innovationstreibern.

Chefkoch konnte seine Entwicklungszyklen und damit die Time-to-Market neuer digitaler Produkte erheblich verkürzen. Wertschöpfende Ideen der Mitarbeiter bekommen Freiräume, werden gehört und haben ihre eigenen Gremien. Manch neue Produkte wie die die komplett überarbeitete Android App und Installationen auf Amazon Echo und Google Assistent entstanden unter ihrer Mitwirkung.
Als agiles Unternehmen konnte Chefkoch seine Position als führendes Rezeptportal Europas weiter ausbauen – mit über 3,5 Mio. angemeldeten Usern und 21 Mio. Unique Usern im Monat (Stand November 2017). Das entspricht ganz den ambitionierten Wachstumsplänen von Martin Meister: "Die gemeinsame Vision von Chefkoch und Cassini trägt Früchte."

Ihr Ansprechpartner:
Michael Schmitz
Partner
agile(@)no-spam.cassini.de 

Wie skaliert man die Rolle eines Product Owners?

Ein Team, ein Product Owner: Das Scrum-Framework ist hier klar in seiner Aussage. Doch was, wenn eine große Zahl von Teams gemeinsam ein Produkt entwickeln? Nur ein zentraler Product Owner würde hier schnell zum Flaschenhals werden. Bei mehreren Product Ownern droht ein erhöhter Koordinationsaufwand. Bei einer steigenden Anzahl von Entwicklungsteams ist dieser nicht mehr effizient zu decken. Wie lässt sich dieses Dilemma speziell in Großunternehmen lösen? Dieser Artikel von Cassini Berater Patrick Daut diskutiert Lösungsansätze und beschreibt eine favorisierte Organisationsstruktur im Detail.

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

Das Schmetterlingsprinzip: Wie Konzernen agile Flügel wachsen.

Beschleunigte Time-to-Market und mehr Flexibilität: Zunehmend setzen auch Konzerne auf Agile und Lean-Methoden. Und scheitern schon im Ansatz. Über die Gründe des Misserfolgs und wie Agilität in Großorganisationen das Fliegen lernt – nach dem Schmetterlingsprinzip. Ein Beitrag von Sascha Meyer und Franziska Wauch, Management Consultants bei Cassini.

Mehr erfahren

Der Flügelschlag eines Schmetterlings kann bekanntermaßen einen Tornado auslösen. Doch keine Angst: Wir sprechen von keinem Sturm des Wandels. Vielmehr sind es die vielen Veränderungen, die in der Summe Agilität selbst in komplexen Organisationen ermöglichen. Soviel vorab.
Immerhin: Viele Großunternehmen erkennen die Zeichen der Zeit und setzen auf agile Modelle für eine neue Dynamik. Doch scheitern sie damit allzu oft und viel zu früh. Bevor wir über das Schmetterlingsprinzip sprechen, sollten wir uns deshalb einigen typischen Fehlern bei der Einführung widmen.

Fehler Nummer 1: Der Pilot, der zu kurz springt.

Vielerorts beginnt Agilität als isoliertes Experiment. Ein Pilotprojekt wird ins Leben gerufen, um Scrum oder Lean innerhalb einer definierten Aufgabenstellung auszuprobieren. Zwar ermöglicht dieses Vorgehen sogar einen gewissen Proof of Concept. Jedoch spiegelt dies bei weitem nicht die Organisationsrealität wider. Informationen über die langfristigen Erfolgschancen von Agilität für die Gesamt-IT sind kaum belastbar und Anforderungen an die Skalierung schwerlich abzuleiten. Stattdessen laufen Organisationen Gefahr, das Pilotprojekt als Nice Try abzuhaken und schnell wieder zum gewohnten Muster zurückzukehren. Der Pilot wird zum Sturm im Wasserglas. 

Fehler Nummer 2: Das Schnellboot, das zurückrudern muss.

Eine Alternative ist die Ausgründung von Organisationseinheiten in „Schnellboote“. Die Annahme ist per se ja auch richtig: Kleinere Einheiten agieren flinker und wendiger als das große Mutterschiff. Doch wehe, wenn der Erfolg kommt. Schnell sind Organisationen dann geneigt, ihre Strukturen wie Controlling und Richtlinien auf das agile Startup oder den neuen Geschäftsbereich zu übertragen. Zurück auf Kurs gebracht, geht unweigerlich auch die Beweglichkeit verloren. Die Dynamik verpufft. Dennoch kann das Schnellboot in gänzlich neuen Businesseinheiten oder für festgefahrene Unternehmungen durchaus als Katalysator dienen. 

Fehler Nummer 3: Der Big Bang als Kulturschock.

Eine drastische Methode, Agilität einzuführen, ist der große Knall: die agile Transformation auf einen Schlag. Dies erfordert einen dramatischen Kulturwandel. Mag sein, dass der radikale Change bei kleinen Unternehmen möglich ist. Bei einer gewachsenen mittelständischen oder gar Konzernstruktur ist dies jedoch mit großen, geradezu übermächtigen Widerständen verbunden. Der eingangs erwähnte Tornado des Wandels in Großorganisationen ist schlicht eine Illusion.

Dennoch weist uns der Big Bang auf eine der wichtigsten Grundvoraussetzungen für die Etablierung von Agilität in großen, komplexen Strukturen hin: Es geht um die Verankerung einer neuen Kultur. So wie eine Raupe verschiedene Stadien durchwandert, um zum Schmetterling zu mutieren, ist dies ein Prozess, der auch Zeit in Anspruch nimmt. Wie also funktioniert das Schmetterlingsprinzip? Über die vielen Flügelschläge.

Der erste Flügelschlag: Ein neues Führungsverständnis aufbauen.

Agile Transformation in Mittelstand und Konzern verläuft in verschiedenen Geschwindigkeiten. Während Methoden, Technologien und Strukturen relativ schnell veränderbar sind, brauchen Verhalten und Einstellungen der Mitarbeiter und damit die Kultur der Organisation wesentlich länger. Letzteres jedoch ist der wichtigste Treiber für den nachhaltigen Aufbau einer agilen Organisation. 

Zwischen Schock, emotionaler Akzeptanz, dem Ausprobieren agiler Methoden und schließlich der Integration des agilen Modells in die Arbeitsweise und Werteskala des Unternehmens gilt es, einen intensiven Weg der Vermittlung und Trainings zu gehen. Dafür muss insbesondere die Führung umfänglich gecoacht werden. Schließlich steht sie neben neuen fachlichen und methodischen Anforderungen auch veränderten Rollen und einem anderen Mitarbeiterverständnis gegenüber. Dieses Verständnis muss fachlich und methodisch aufgebaut und die Veränderung begleitet werden.

Der zweite Flügelschlag: Fehler zulassen und lernen.

Sind die Prinzipien der Agilität auf der Führungsebene verankert, können agile Methoden und Werkzeuge sukzessive in allen Teams eingeführt werden. Neben Fließen, Takten, Pullen, Nullen gilt vor allem: keine Angst vor Fail Fast. Retrospektiven und Lessons Learned machen die frühzeitige Weiterentwicklung und Verbesserung möglich. Die parallele Vermittlung agiler Grundwerte wie Partizipation, Selbstorganisation und Verantwortung helfen dabei, die Methoden und Werkzeuge weiter zu verinnerlichen. Darüber hinaus sollte das Ziel der Transformation verständlich aufgezeigt werden: Sinngebung ist wichtig. Um neue, selbstverantwortliche Rollen zu etablieren, hilft die Einrichtung vermittelnder bis intervenierender Coaching- und Interimsrollen.

Der dritte Flügelschlag: Verfeinern und ausrollen.

Einmal unternehmensweit lokal und unabhängig verteilt („locally and everywhere“), können die Verfeinerung und Zusammenführung erfolgen. Schritt für Schritt wachsen der agilen Großorganisation nun Flügel. Erste Veränderungen in Verhalten und Einstellungen können auf dieser Stufe bereits sichtbar werden. Gefördert wird der Austausch beispielsweise in Communities of Practice, an Round Tables oder auch an dedizierten Change-Tagen. Hier entsteht Raum für Austausch und Kreativität.  Das kann nicht nur in Unternehmen wie Google und Facebook erfolgreich sein.
Zuletzt kann der organisationsweite Rollout erreicht werden. Hier erfolgt die Integration in Governance-Strukturen, die Kundenausrichtung und -integration werden gestärkt. Die agile Organisation spiegelt sich dann auch in Themen wie dem Einkauf und Controlling wider. Bis dahin ist viel Zeit vergangen. Die Transformation zur agilen Organisation ist ein kein leichter Weg.

Der vierte Flügelschlag: Die permanente Transformation.

Zum wahren Höhenflug aber setzt Agilität in Großorganisationen an, wenn sie als permanenter Prozess verstanden und etabliert wird. Hier hilft die Integration von Change-Aspekten in den Einführungspfad selbst (siehe vorige Abb. 2). Die Auswahl der Methoden und Werkzeuge für die agile Organisation erfordert ein Verständnis dafür, welches Verhalten eine Organisation honoriert, welche Veränderungsbereitschaft und -fähigkeit sie hat. Diese Ausgangslage bestimmt auch die Gestaltung der Entwicklungsmaßnahmen, Interventionen und die Kommunikationsstrategie für Führungskräfte und Mitarbeiter. Und es gibt viel Fleißarbeit zu tun: Die kontinuierliche, konstante und zielgruppengerechte Einbindung der verschiedenen Stakeholder erfordert nicht nur eine strukturierte Kommunikationsplanung.

Der fünfte Flügelschlag: Den Transformationsfortschritt messen.

Dafür können bekannte und bewährte Werkzeuge wie die Balanced Score Card eingesetzt werden. Projekt- und Change- Management-Werkzeuge wie Stakeholder-Analyse, Risiko-Analyse, Change Readiness Check, Temperatur-Check etc. ermöglichen es, in den verschiedenen Phasen und Ebenen der agilen Transformation, Interventionen, Kommunikation und Entwicklungsmaßnahmen passend zu gestalten. Die Beobachtung der Veränderungskurve für verschiedene Teams und Gruppen ermöglicht die gezielte Einwirkung auf Widerstände und damit einen kontrollierten Verlauf der Transformation entlang der Veränderungskurven von Stakeholdern.

Fazit

Die Metamophose von einer klassischen zu einer agilen Großorganisation ist vor allen Dingen ein kultureller Wandel, der in den Köpfen und hier insbesondere bei der Führung beginnt. Er benötigt Zeit und sollte generalistisch ansetzen. Piloten, Schnellboote oder der Big Bang greifen in Wahrheit zu kurz, auch wenn sie im tiefen Kern das Richtige meinen. Sie gehen von dem Gedankenansatz aus, dass „Cocooning“ im Zeitalter des schnellen Wandels nicht weiterhilft, ja existenziell gefährlich ist. Doch sind Agilität, Flexibilität und Wandelbarkeit einmal etabliert, muss dies als Prozess begriffen werden, der niemals abgeschlossen ist. Sonst hören die Flügel des Schmetterlings auf zu schlagen.

Ihre Ansprechpartnerin:
Franziska Wauch
Management Consultant
agile(@)no-spam.cassini.de 

Wie agil kann die Vergabe sein? Eine Podiumsdiskussion auf dem Zukunftskongress.

Agile Prinzipien und öffentliche Beschaffung scheinen sich auf den ersten Blick auszuschließen. Denn ein fester Leistungsgegenstand lässt sich kaum mit den Grundsätzen der Flexibilität vereinbaren. Oder doch? Auf dem Zukunftskongress 2015 in Berlin kam es zur Podiumsdiskussion zwischen vier Experten. Die Erkenntnis: Die Vergabe kann durchaus dynamischer werden – trotz enger Rahmenbedingungen. 

Mehr erfahren

An der Diskussion nahmen Dr. André Schnackenburg (IT-Leiter, Statistikamt Nord) und Norman Müller (Partner, TCI Rechtsanwälte), Sascha Meyer (Management Consultant, Cassini) und Felix Dinnessen (Senior Consultant, Cassini), teil.

Alle Welt spricht von der unaufhaltsamen Digitalisierung. Fast im selben Atemzug ist dann vom neuen, unverzichtbaren Paradigma der Agilität die Rede. Wie wichtig werden in Zukunft agile Methoden im öffentlichen Sektor sein?

Sascha Meyer: Wir befinden uns bereits in einem rasanten Wandel von Technologie und Arbeitswelt: immer komplexere Systeme, übergreifende Vernetzung, hohe Veränderlichkeit von Rahmenbedingungen und Anforderungen sowie ein starker Kampf um die besten Talente. Schon diese Effekte, die die Digitalisierung auf Bürger und zukünftige Verwaltungsmitarbeiter haben, bedeuten für den Public Sector Veränderungen. Für mich ist das Ob gar nicht mehr die Frage, sondern nur noch, wann die öffentliche Verwaltung diesen Rahmenbedingungen folgt, um für die Anforderungen der digitalen Welt gewappnet zu sein. Vergabe, Vorgehen und Organisation werden sich durch den Einsatz agiler Vorgehensweisen verändern. Es ist daher nur konsequent, sich mit den Möglichkeiten einer „agilen Beschaffung“ auseinanderzusetzen – selbstverständlich unter Berücksichtigung der rechtlichen Rahmenbedingungen.

Dr. André Schnackenburg: Im Behördenumfeld hat die Time-to-Market sicher nur eine untergeordnete Bedeutung. Dennoch gibt es auch hier zahlreiche Gründe, agile Softwareentwicklung einzusetzen. Dabei stellen sich zwei wichtige Fragen: Wie viel Agilität nützt einer Behörde derzeit überhaupt? Und wie viel sie verträgt sie? Die agilen Ansätze erfordern nämlich eine beachtliche Mitwirkungsleistung des Auftraggebers: Es muss nicht nur ständig und zuverlässig Personal für die vielen Abstimmungen zur Verfügung stehen, sondern dieses Personal muss auch fachlich auf Augenhöhe mit dem Auftragnehmer diskutieren können.

Felix Dinnessen: Wenn durch agile Methoden Ergebnisse frühzeitig verwertbar sind, profitieren auch öffentliche Auftraggeber davon. Denn zu lange Projektlaufzeiten führen dazu, dass bei Bürgern und Behördenmitarbeitern die Akzeptanz gegenüber neuen Vorhaben schwindet – von Aspekten wie der Einhaltung gesetzlich vorgegebener Fristen ganz zu schweigen. Für öffentliche Auftraggeber ist es allerdings auch mit Risiken verbunden, wenn sie Softwareentwicklungsprojekte agil umsetzen. Die Herausforderung besteht insbesondere darin, finanzielle und vertragliche Planungssicherheit zu erzielen.

Norman Müller: Die Praxis zeigt, dass es auch für Projekte der öffentlichen Hand Vorteile gibt, wenn bei der Softwareentwicklung agile Prinzipien in bestimmten Konstellationen angewandt werden. Wenn man die Prinzipien konsequent umsetzt, können agile Projekte durchaus zu erheblichen Kosteneinsparungen führen. Dies liegt unter anderem daran, dass bedarfsgerechter entwickelt werden kann und Teilergebnisse schneller zur Verfügung stehen. Es ist auch nicht so, dass sich agile Prinzipien und die Anforderung, Leistungen vor der Vergabe möglichst abschließend zu beschreiben, zwingend widersprechen. Das Vergaberecht fordert eine funktionale Leistungsbeschreibung, das heißt, letztlich eine Beschreibung dessen, was der Auftraggeber im Ergebnis will. Was es also braucht, ist zumindest ein funktionaler Rahmen.

Die Vergabeprinzipien der öffentlichen Hand scheinen mit den Prinzipien der Agilität nicht ohne weiteres vereinbar. Wie groß ist dieser Graben wirklich und wie lässt er sich überbrücken?

Sascha Meyer: Der funktionale Umfang – also die Frage „Was soll entwickelt werden?“ – sollte auch bei agilen Projekten zu Beginn konzeptionell bekannt sein. Was allerdings bewusst vermieden wird, ist eine detaillierte Anforderungsbeschreibung. Man stellt sich also ausdrücklich nicht die Frage: „Wie soll es umgesetzt werden?“. Diese Details werden erst durch die Kooperation von Auftraggeber und Auftragnehmer iterativ erarbeitet. Gerade diese Zusammenarbeit zwischen Nutzern und Entwicklern sorgt dafür, dass im Entwicklungsprozess passgenauere Ergebnisse entstehen.

Dr. André Schnackenburg: Um die agile Softwareentwicklung mit dem Vergaberecht zu vereinbaren, spielen je nach Szenario bestimmte Formen der Ausschreibung eine wichtige Rolle. Das schwierigste Szenario ist wohl die vollständige Vergabe – inklusive Projektleitung – an einen Dritten. Dafür wurde in Abstimmung mit dem Beschaffungsamt des Bundesministeriums des Innern ein Weg entwickelt – mit einer Rahmenvertragskonstruktion, die sich an das Drei-Partner-Modell für Beratungsdienstleistungen des Bundesverwaltungsamts anlehnt. Dieser Rahmenvertrag  ermöglicht die Vergabe einer vollständig agilen Softwareentwicklung an Dritte. Dieses Konstrukt verlangt einen sehr effizienten Steuerungsmechanismus, der aber auch in Anlehnung an das Drei-Partner-Modell gestaltet werden kann.

Norman Müller: Durch agiles Vorgehen werden eine ganze Reihe von Prinzipien auf die Probe gestellt, zum Beispiel die Planbarkeit, die Kostensicherheit und die Vergleichbarkeit von Angeboten verschiedener Bieter im Vergabeverfahren. Es stellt sich auch die Frage, ob ein agiles Projekt auf werkvertraglicher Basis und damit unter der rechtlichen Gesamtverantwortung des Auftragnehmers durchgeführt werden kann. Wann und wofür Abnahmen erteilt werden, ist dann eigentlich nur noch eine Folgefrage – wenngleich eine spannende. Um die Risiken möglichst gering zu halten, müssen die Regeln für das agile Vorgehen im konkreten Projekt sorgfältig gestaltet werden, ebenso wie die entsprechenden Verträge. Erfolgversprechend erscheinen hier vor allem Ansätze einer rahmenvertraglichen Konstruktion auf werkvertraglicher Grundlage. Auf dieser Basis lassen sich dann Einzelverträge abschließen, die beispielsweise einzelne Sprints abbilden. Entscheidend ist dabei, dass der Auftragnehmer für das Projektergebnis insgesamt verantwortlich bleibt, insbesondere auch für die Erreichung der funktionalen Anforderungen aus dem Vergabeverfahren. Weil agile Prinzipien eine erhebliche Mitverantwortung des Auftraggebers vorsehen, ist das sicherlich eine Herausforderung.

Felix Dinnessen: Ich bin der Ansicht, dass die entscheidenden Weichen dafür, gleichzeitig Planungssicherheit zu erhalten und die gewünschte Flexibilität in der Umsetzung zu bewahren, schon durch die Leistungsbeschreibung im Vergabeverfahren gestellt werden – auch wenn die Ergebnisse erst in der Auftragsausführung spürbar werden. Damit die Leistungsbeschreibung dieser Herausforderung gerecht wird, sollten in ihr die Business-Anforderungen definiert sein, zum Beispiel in Form von Prozessen und Use Cases. Des Weiteren gehören die Grundzüge der zukünftigen Softwarearchitektur in die Leistungsbeschreibung. Und was bei agilen Projekten besonders wichtig ist, ist die Beschreibung auch der nicht-funktionalen Anforderungen. Dazu zählen etwa Projektmanagement und -vorgehensweise oder die Verfahren für Einzelbeauftragung und Abnahme. Und last but not least: auch die Anforderungen an die Pflege und Weiterentwicklung des Leistungsgegenstands gehören in die Leistungsbeschreibung. Eine Leistungsbeschreibung, die den funktionalen Rahmen der gewünschten Lösung absteckt, ist auch eine wichtige Voraussetzung dafür, um Angebote qualitativ bewerten zu können. Nur den Preis als Zuschlagskriterium heranzuziehen, greift zu kurz. Es braucht eine Leistungsbeschreibung mit inhaltlicher Aussagekraft. Zumal sich der agile Projektansatz insbesondere zur Umsetzung komplexer Vorhaben eignet. Solche Vorhaben machen in der Regel eine Interaktion bzw. eine intensive Auseinandersetzung mit den Bietern und ihren Lösungsansätzen nötig. Als Vergabeart kommt darum häufig nur das Verhandlungsverfahren in Frage.

Die Zusammenarbeit zwischen Auftraggeber und -nehmer spielt im agilen Ansatz ja eine große Rolle – der iterative Prozess. Wie lässt sich dies sinnvoll auch im öffentlichen Sektor abbilden? Und existiert das erforderliche Know-how?

Dr. André Schnackenburg: Mir scheint hier ein Ansatz sinnvoll, wie ihn derzeit zum Beispiel die Freie und Hansestadt Hamburg verfolgt. Hier wurde ein behördenübergreifender Projektmanagement-Pool aufgebaut. Dieser Pool stellt Behörden, die im Projektmanagement unerfahren sind, Personal zur Verfügung. So können auch diese Behörden Projekte entweder vollständig selbst durchführen oder Projekte, die sie vergeben haben, sicher steuern. In diesem Pool gibt es auch Personen, die als Scrum-Master zertifiziert sind. Aber egal, ob das Projektmanagement nun agil, fast agil oder klassisch ist – die meisten deutschen Behörden haben den Schritt nach vorn noch vor sich. Es wird darauf ankommen, das eigene Personal und die Unternehmenskultur nachhaltig für Projektarbeit zu ertüchtigen.

Sascha Meyer: Die Spielregeln der gemeinsamen Zusammenarbeit sind etwas, das die Parteien schon im Rahmen der Vergabe klären und fixieren sollten. Welches Kooperationsverständnis gibt es? Wer stellt den Product Owner und welche Rechte und Pflichten hat er? Auch das Einigungsverfahren muss definiert werden, damit kontinuierliche Absprachen möglich sind und der Umgang mit Anpassungen klar ist. Zudem muss es eine Definition of Done geben, die festlegt, welche Qualität für auslieferbare Pakete gefordert ist. Auch die gemeinsame und kooperative Steuerung des Projekts muss vor Beginn der Zusammenarbeit ausgestaltet sein. Hier ist es wichtig zu klären, ob man gemeinsame Gremien etablieren will, etwa einen Lenkungsausschuss, und wie eine Schlichtung erfolgen kann.

Norman Müller: Auch wenn man für gute rechtliche Rahmenbedingungen gesorgt hat – sie können ein vertrauensvolles Miteinander letztlich weder erzwingen noch ersetzen. Der vertragliche Rahmen schützt eben nicht vor allen praktischen Problemen in Projekten. Trotzdem sollten die Verträge so ausgestaltet sein, dass sie sich als Druckmittel eignen, um den Auftragnehmer zu einer ordnungsgemäßen Vertragserfüllung anzuhalten. Gleichzeitig sollte sich der Auftraggeber möglichst vor einer zu großen Abhängigkeit von einem Auftragnehmer schützen. Im Rahmen agiler Projekte stellen sich hier teilweise neue Fragen. So wird etwa im klassischen Wasserfallprojekt häufig ein Festpreis für die Gesamtleistung vereinbart, was in einem wirklich agilen Projekt kaum möglich ist. Und was passiert, wenn ein Auftragnehmer seine Möglichkeit missbraucht, den Aufwand für einen Sprint zu definieren? Auch wenn die folgende Lösung nicht in allen Konstellationen möglich ist: Man kann in solchen Projekten zwei oder mehr Auftragnehmer um die Einzelverträge konkurrieren lassen, damit das Projekt letztlich nicht nur von einem, sondern von mehreren Auftragnehmern durchgeführt wird.

Ihr Ansprechpartner:
Felix Dinnessen
Senior Consultant
agile(@)no-spam.cassini.de 

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 

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