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