Was die Pharmaindustrie von der Erfolgsgeschichte agiler Methoden lernen kann

Gerade in Branchen wie der Pharmaindustrie, die stark von außen reguliert werden, sind es Teams gewohnt, dass Prozesse und Abläufe klar definiert sind, dass es eine eindeutige Zuordnung von Zuständigkeiten gibt und die Entscheidungsbefugnisse ebenso klar verteilt sind. Dabei haben die Mitarbeiterinnen und Mitarbeiter innerhalb der täglich zu durchlaufenden Prozesse kaum Gestaltungsfreiräume, da die Entscheidungskompetenzen auf Gremien oder Managementebenen verlagert sind. Als Endresultat tragen die einzelnen Mitarbeiterinnen und Mitarbeiter kaum Verantwortung. Und auch die Produktentwicklung bleibt hiervon nicht verschont.

Wie Einzelkämpfer im Staffellauf

Ikujiro Nonaka und Hirotaka Takeuchi haben dieses Phänomen bereits 1986 in ihrem berühmten Artikel „The New New Product Development Game“ sehr treffend beschrieben. Sie verglichen das mehrheitlich in Unternehmen genutzte Produktentwicklungskonzept mit einem Staffellauf, bei dem ein Läufer den Staffelstab an den nächsten übergibt.

Wer schon einmal eine Staffel bei einem Marathon gelaufen ist, weiß, dass gerade die Übergabe gewisse Risiken mit sich bringt: Hat die vorherige Läuferin, der vorherige Läufer eine gute Zeit erzielt, so möchte man diesen Vorsprung natürlich ausbauen. Auch umgekehrt verhält es sich ähnlich: Liegt man bereits zurück, will man nicht noch mehr Zeit verlieren. Als Konsequenz findet die Übergabe des Staffelstabs – bzw. heute des Zeitmessers – immer unter enormem Zeitdruck statt und häufig gehen wertvolle Informationen zwischen den LäuferInnen verloren.

Was bei der Staffel Streckenverlauf oder Windbedingungen sind, können in der pharmazeutischen Produktentwicklung Informationen zu Spezifikationen oder Formulierung sein. Zudem verleitet eine so klare Trennung der Verantwortlichkeiten dazu, nicht über den eigenen Tellerrand hinauszusehen. Beim Staffellauf beispielsweise wird jede Läuferin, jeder Läufer für sich an der eigenen Kondition und der persönlichen Bestzeit auf dem jeweiligen Streckenabschnitt des Marathons arbeiten. In Unternehmen wird die Auswirkung dieser klaren Trennung zwischen den Expertenteams noch deutlicher. Das Team, das mit der eigentlichen Entwicklung beschäftigt ist, optimiert diese Phase so für sich, dass der Staffelstab möglichst kurz im eigenen Team verweilt und schnell zur nächsten Entwicklung übergegangen werden kann. Bei diesen Verbesserungen haben die Teams selten den gesamten End-to-End-Prozess im Blick, sondern häufig nur ihren Zuständigkeitsbereich. Die Resultate sind nicht mehr optimal funktionierende Schnittstellen und ein fehlendes Verantwortungsbewusstsein für den gesamten Prozess, den das Produkt durchlaufen muss.

Der Rugby-Ansatz für selbstorganisierte Teams

Die beiden Autoren Ikujiro Nonaka und Hirotaka Takeuchi schlagen in ihrem Artikel den sogenannten Rugby-Ansatz als Lösung vor. Sie referieren hier auf jene Phase beim Rugby, in welcher der Ball innerhalb des Teams immer wieder übergeben wird, während das Team auf dem Spielfeld Raum gewinnt. Das gesamte Team arbeitet somit Hand in Hand, hat jederzeit alle Informationen verfügbar und kann innerhalb des Spielzugs sofort auf Aktionen des Gegners reagieren. Auf den Entwicklungsprozess übertragen zielt dieser Ansatz auf möglichst weit überlappende Phasen mit selbstorganisierten und selbstlernenden Projektteams ab, die den gesamten Prozess in ihrer Verantwortung haben.

Basierend auf diesen Erkenntnissen errichteten die beiden Autoren nicht nur einen wichtigen Grundpfeiler für das Framework Scrum, sondern waren in ihrer Denkweise so manchem Unternehmen des 21. Jahrhunderts voraus. Für die pharmazeutische Industrie hieße das, dass es beispielsweise keine klare personelle Trennung mehr nach einzelnen Phasen wie Forschung, Entwicklung, Präklinik, Produktion, klinisches Studiendesign gibt, sondern sich das Team von Anfang an aus allen Expertinnen und Experten zusammensetzt, die zur Produktentwicklung benötigt werden. So wie es beispielsweise bei Biotech-Startups oft der Fall ist.

Stellen Sie sich vor, Sie müssen nicht mehr wochenlang auf Meetings mit den Expertinnen und Experten warten, sondern haben diese zu 100 % im Team und damit jederzeit verfügbar!

Mit Scrum die Marktanforderungen an Ihr Unternehmen befriedigen

Jeff Sutherland und Ken Schwaber bauten vor 23 Jahren diesen Ansatz durch das Framework Scrum noch weiter aus. Sie wollten weg von überladenen Projektmanagement-Methoden – hin zu einem „leichtgewichtigen“ Ansatz, der Unternehmen dabei hilft, die an sie gestellten Marktanforderungen wieder befriedigen zu können. Denn unsere Welt wird immer schnelllebiger. Meiner Erfahrung nach ändern sich die Rahmenbedingungen so rasant, dass die Anforderungen an ein Projekt nach 6 Monaten schon ganz anders aussehen können und eine mehrjährige Produktentwicklung nach einem festen Plan nur selten das eigentliche Bedürfnis der Nutzer befriedigen kann.

Heute arbeiten die Scrum-Teams mit kurzen Iterationen, in denen sie inkrementell, also in kleinen Schritten, Produkte entwickeln, zu denen sie direkt Feedback der Nutzer einholen können. Sie entwickeln nicht mehr hinter verschlossenen Bürotüren fernab von den eigentlichen Anwendern des späteren Produkts, sondern befinden sich im stetigen Austausch mit ihnen und nähern sich so Iteration für Iteration dem finalen Produkt. Dieses schrittweise Vorgehen erlaubt den Teams, sich ändernde Rahmenbedingungen flexibel in die Entwicklung einfließen zu lassen. Zudem werden Entscheidungen dort getroffen, wo die Informationen liegen: direkt im Entwicklungsteam. Das lange Warten auf Ansagen des Managements oder der Gremien würde der Produktivität des Teams nur im Weg stehen.

Scrum erfordert ein Umdenken

Die Einführung von Scrum in einer Organisation geht jedoch über die Veränderungen der operativen Prozesse hinaus und erfordert auch eine veränderte Haltung aller Beteiligten. In Bereichen wie dem Bankensektor und der Automobilbranche ist das bei den führenden Unternehmen bereits passiert. Die Pharmaindustrie befindet sich unserer Erfahrung nach noch ganz am Anfang dieses Wandels, auch wenn sich erste Unternehmen wie Böhringer-Ingelheim der Herausforderung bereits stellen.

Aufgrund der langen Entwicklungszeiten und des stark regulierten Umfelds, sind besonders kreative Köpfe für die Verwirklichung eines cross-funktionalen Arbeitens gefragt. Doch die Erfolgsgeschichte agiler Methoden zeigt sehr schön, dass es sich heute rentiert, den Anwender und Kunden wieder in den Fokus zu rücken. Zudem wird es für Unternehmen immer überlebenswichtiger, schnell auf Änderungen am Markt reagieren zu können. Unflexible Prozesse, das Warten auf Entscheidungen und Teams, die sich nicht für das Endprodukt und den Gesamtprozess verantwortlich fühlen, stehen dem eindeutig entgegen. Dabei sollten wir alle doch ein vorrangiges Interesse haben: in kürzester Zeit für den Kunden werthaltige Produkte auf den Markt zu bringen.

3 Modelle für die vernachlässigte Koordinationsebene zwischen strategischem Management und operativen Teams

Während der Mittagspause eines unserer ScrumMaster-Trainings schütteten mir die Leiterin der HR-Abteilung und ein erfahrener ScrumMaster ihre Herzen aus. Ihr Unternehmen sollte zur agilen Organisation werden, aber sie wussten nicht recht weiter: „Bei uns fehlt die Koordinationsebene. Wir haben auf der einen Seite agile Teams, die an Projekten und Produkten arbeiten. Auf der anderen Seite steht die Geschäftsleitung, die Kontrolle, Zugriff und Verantwortliche will, um effizient durchregieren zu können. Der Austausch zwischen Teamebene und strategischer Leitungsebene findet nur vereinzelt statt, es wird zu wenig kommuniziert.“

Diese Situation hat zur Folge, dass sich die agil arbeitenden Teams alleingelassen fühlen. Die ScrumMaster fangen an, Scrum intern als Methode zu verteidigen, weil das Warum dahinter aus dem Blick geraten ist. Sie stoßen täglich auf Impediments, die außerhalb des Teams liegen, doch im Unternehmen findet sich kein tragfähiges Modell, um teamübergreifende Impediments systematisch zu lösen. Es macht sich bei der Geschäftsleitung der Eindruck breit, dass „agil“ nicht so richtig funktioniert und der Ruf nach mehr disziplinarischer Führung wird laut. Letztlich stockt die so optimistisch begonnene agile Transition des Unternehmens.

Was ist los?

Es fehlt eine Koordinationsebene zwischen dem Oben und Unten, zwischen Strategie und Umsetzung, zwischen Unternehmenszielen und Teamzielen, zwischen Führungsmethoden und Produktentwicklungsmethoden.

Wenn agile Methoden in einem Unternehmen eingeführt werden, dann sieht das häufig so aus: Scrum, Kanban und Co. werden anstelle des klassischen Projektmanagements eingeführt und eingesetzt. Das geschieht auf Projektteam- bzw. Produktteamebene. Die Geschäftsleitung betrachtet diese Teams als ungefährliche Spielwiese für agiles Arbeiten. Und das war’s dann. Die wenigsten Unternehmen verzahnen von Anfang an die operative Teamebene systematisch mit der strategischen Leitungsebene.

Und immer wieder stelle ich fest, dass agile Methoden und Konzepte für die Organisationsebene den verantwortlichen Führungskräften schlicht und einfach nicht bekannt sind. Unternehmensagilität scheitert also auch am fehlenden Methodenwissen.

Drei Modelle für eine bessere Koordination

Es gibt eine Vielzahl an etablierten Methoden bzw. Modellen, um Agilität auf Unternehmensebene umzusetzen und dadurch das Oben und Unten zu koordinieren. In diesem Blog möchte ich kurz und knapp und ohne Anspruch auf Vollständigkeit drei wichtige Methoden bzw. Modelle vorstellen.

1. Objectives and Key Results, kurz OKRs, wie Google und Co. sie einsetzen:

Bei OKRs handelt es sich um ein Zielmanagementkonzept, mit dem alle Ebenen eines Unternehmens aufeinander abgestimmt und gemeinsam ausgerichtet werden. Ausgehend von der Unternehmensvision werden Jahresziele oder Moals, und daraus Company OKRs abgeleitet, möglicherweise gibt es auf Bereichsebene Bereichs-OKRs. Auf der Teamebene werden Team-OKRs entwickelt, die auf die Bereichs- bzw. Company-OKRs einzahlen. Dabei gibt es Impulse sowohl von oben als auch von unten, die in einem Kommunikationsprozess aufeinander abgestimmt werden. OKR arbeitet mit OKR-Zyklen, die man sich wie große Sprints auf Unternehmensebene vorstellen kann. Ein OKR-Zyklus dauert in der Regel drei oder vier Monate. So ist sichergestellt, dass mehrmals pro Jahr auf allen Ebenen des Unternehmens geprüft und korrigiert wird, ob der Kurs noch stimmt. Starre Jahresplanungen gehören der Vergangenheit an. Während des geschützten Raums eines OKR-Zyklus wird gearbeitet, ohne dass von oben oder von der Seite hineinregiert wird. Schließlich wird mit OKR-Reviews und OKR-Retros auf den Arbeitserfolg geschaut und Verbesserungen werden umgesetzt.

2. Kanban Flight Levels, wie sie von Klaus Leopold entwickelt wurden:

Warum Kanban nur auf Teamebene machen? Immer da, wo optimiert werden muss, immer da, wo zu viel Arbeit ins System gekippt wird, hilft es, mittels Visualisierung den Arbeitsfluss zu erkennen und diesen zu optimieren. Auf Flight Level 3, der Ebene des strategischen Portfoliomanagements und der Vorstandsentscheidungen besteht in vielen Unternehmen die Gefahr, dass zu viel gleichzeitig angestoßen wird. Das mittlere Flight Level 2 sorgt dafür, dass „oben“ die Folgen von Entscheidungen unmittelbar gespürt werden und gleichzeitig die Teamebene „unten“ – dank der Koordinationsebene – Gehör bei „denen“ da oben findet. Hier werden die Interaktionen zwischen Teams und Abteilungen über den gesamten Prozess koordiniert, end-to-end von der Idee bis zur Wirkung. Und schließlich gibt es mit Flight Level 1 die operative Ebene, die Teamebene.

Kurz zusammengefasst: Auf Strategieebene gibt es ein Kanban-Board mit den Initiativen, Fokusthemen und Jahreszielen. Auf den Teamebenen gibt es Boards mit der operativen Arbeit und dazwischen gibt es Boards mit Koordinationsthemen.

3. Das Transition-Team im Zusammenspiel mit den ScrumMaster-Teams:

Scrum-Teams werden zum zahnlosen Tiger, wenn es keine starken ScrumMaster oder Agile Coaches gibt, die Impediments auf die Leitungsebenen hochspielen und dort lösen lassen. Transitions-Initiativen stocken, wenn Impediments nicht von oben angegangen werden. Mit dem Konzept des Transition-Teams wird von Anfang an sichergestellt, dass die agilen Pilotteams nicht alleine gelassen werden und der Wandel vom Top-Management aktiv mitgestaltet wird. Das Transition-Team ist mit echten Treibern der Transformation zur agilen Organisation besetzt und besteht aus Mitgliedern der Geschäftsleitung bzw. des Vorstandes sowie Vertretern der Scrum-Teams und weiteren Schlüsselrollen. Es arbeitet selbst nach Scrum und entwickelt somit iterativ und inkrementell das Unternehmen weiter. Wichtigster Partner des Transition-Teams ist das ScrumMaster-Team. Im Zusammenspiel wird sowohl die strategische als auch die operative Ebene der Transformation umgesetzt.

 

Die oben vorgestellten Konzepte können separat oder in beliebiger Kombination in einem Unternehmen zum Einsatz kommen. Doch Vorsicht: Auch diese Konzepte sind kein Erfolgsgarant für Business-Agilität. Der Wandel im Unternehmen kann damit genauso scheitern wie bei der Einführung von Scrum oder Kanban auf Teamebene. Diese Konzepte funktionieren nur dann, wenn das Top-Management von Anfang an integraler Bestandteil der Transition ist und die neue Koordinationskultur vorlebt. Nur dann können die neuen Vorgehensweisen Altes ersetzen. Nur dann verändern sich Unternehmenskultur, Führungsverhalten und Business-Agilität.

Was wünsche ich mir?

Ich wünsche mir eine größere Bekanntheit dieser Methoden und Konzepte für Agilität auf Unternehmensebene. Ich wünsche mir, dass künftig in Trainings und Workshops über Business-Agilität geredet wird. Dann werden die vielen agilen Transformationsvorhaben zu echten Erfolgsstorys.

Und eins darf niemals vergessen werden: Agilität und agile Methoden sind kein Selbstzweck. Es geht um Nutzerorientierung. Es geht um Prozessoptimierung und dabei um Qualität und um Geschwindigkeit. Geschwindigkeit von der Idee bis zur Wirkung, bei der Gewinnung von Feedback vom Markt und beim Lernen.

In diesem Sinne: Lassen Sie uns im Gespräch bleiben zum Thema Business-Agilität.

 

Foto von Aurélien Lemasson-Théobald auf Unsplash

Innovation & Bau? Das Potential von Agile, Lean und BIM

Die Baubranche boomt zurzeit, doch trotz der großen Nachfrage nach Planungs- und Bauleistungen weist diese noch immer eine viel zu geringe Produktivität und Innovationskraft auf. Welche Voraussetzungen müssen also in Planungsbüros und im Baugewerbe geschaffen werden, damit die Vorteile der Digitalisierung und das Potential von BIM erfolgreich genutzt werden und neue innovative Geschäftsmodelle entstehen können? Und welche Rolle spielen dabei agile Methoden und das Lean Management?

Profitabilität und Innovation im Bau sind möglich

Entgegen dem allgemeinen Trend in der Baubranche gibt es in Deutschland sehr wohl einige hochinnovative und sehr profitable Bau- und Planungsunternehmen. Gerade Generalunternehmen können ein großes Innovationspotential ausschöpfen, wenn ein Großteil der Wertschöpfung beim Planen und Bauen im eigenen Haus geschieht. Dadurch wird der Bauprozess in weiten Teilen kontrollier- und optimierbar. Ein klarer Fokus auf Produkte hilft, die Zügel in der Kundenkommunikation und in der Weiterentwicklung der Produkte in der Hand zu behalten. Auf dieser Basis wird projektübergreifende Serienfertigung mit dem damit verbundenen Innovationspotential möglich. Eine lernende Organisation und eine Kultur dezentraler Entscheidungen sind der Schlüssel für Veränderungsfähigkeit und Innovationskraft.

Wenn nun eine kontinuierliche Verbesserung von Prozessen und Innovation im Bau durchaus möglich ist, warum gilt dann die Baubranche weithin als wenig innovativ? Die Antwort liegt zum Teil im Projektgeschäft als solchem und zum Teil in der Zusammenarbeitskultur. Nur wenigen Planungsbüros und Unternehmen gelingt es, trotz Projektgeschäft eigene Standards zu etablieren und entlang der Wertschöpfungskette Schnittstellenverluste in der Zusammenarbeit zu minimieren.

Die Planungsbüros und Bauunternehmen, die heute erfolgreich mit eigenen Standards arbeiten, beschäftigen sich oftmals schon seit Jahren und Jahrzehnten damit.

Diese Unternehmen haben während der verschiedenen Phasen der Digitalisierung, von Datenbanken über CAD bis hin zu Cloud und BIM, stets aktiv eigene Systeme und Standards etabliert und weiterentwickelt. Dabei war Effizienz in der Datengenerierung und Datenübermittlung stets ein wesentlicher Treiber der Entwicklung. Innovation kann da entstehen, wo es gelingt, auf dem Markt die eigenen Planungs- und Bauprodukte mehrwertschaffend für Kunden zu platzieren und dabei die durch Standardisierung, Automatisierung und Digitalisierung möglichen Potentiale voll auszuschöpfen. Aus den daraus resultierenden Neuerungen in der Bauabwicklung können dann neue Geschäftsmodelle mit großen Wachstumspotentialen entstehen.

Gerade im Baugeschäft entsteht Innovation eher langsam und stetig als schnell und disruptiv, denn schließlich müssen technische Neuerungen erst in das komplexe Gesamtgefüge der Bauentstehung integriert werden und letztlich sichtbaren Mehrwert für Kunden generieren.

Schauen wir uns anhand von einigen Beispielen an, wie Innovation im Bau aussehen kann:

Die vorgenannten Beispiele verdeutlichen, dass Neuerungen in der Baubranche bestimmte Voraussetzungen entlang der Wertschöpfungskette brauchen, um sich am Markt durchzusetzen und zu etablieren. Eine ganz wichtige Voraussetzung sind etablierte Prozesse in großer Stückzahl und eine etablierte Gewerke- und Bauphasen-übergreifende Zusammenarbeit.

Eine partnerschaftliche Zusammenarbeit ist die Basis

Die Vertragskultur im Bauwesen in Deutschland motiviert tendenziell zu einem Gegeneinander-Arbeiten und Absichern anstatt zu einer partnerschaftlichen Zusammenarbeit. Daher sind Innovationen, die sich am Markt durchsetzen eher von denjenigen zu erwarten, die bereits eine Lösung für eine gute Zusammenarbeit entlang der Wertschöpfungskette gefunden haben und deshalb nach vorne schauen und optimieren können, anstatt im Absicherungs-Schriftverkehr zu versinken. Demzufolge gehört die Zukunft denjenigen, denen es gelingt, gute Zusammenarbeit und optimierte Prozesse mehrwertbringend für den Kunden auf die Straße zu bringen. Das können z. B. Generalüber- und -unternehmer, Generalplaner oder in kleinem Maßstab Baumeister sein, die mit einer Handvoll Handwerker vertrauensvoll mit dem Bauherrn zusammenarbeiten.

Dabei dürfte es in Deutschland denjenigen Unternehmen leichter fallen, neue Wege zu gehen, die sich auf privatwirtschaftliche statt öffentliche Aufträge konzentrieren, die eine große Bandbreite der Wertschöpfungskette abdecken und idealerweise im Ausland gewonnene Lernerfahrungen mit integrativen und partnerschaftlichen Vertragskulturen mitbringen.

Agile, Lean Construction und BIM dürfen nicht überschätzt werden

Ist eine partnerschaftliche Zusammenarbeit zwischen Gewerken und Bauphasen in Grundzügen etabliert, dann kann mit Methoden wie Agile, Lean Construction und BIM darauf aufgebaut und in weiterer Folge die Prozesse optimiert werden. Wer jedoch glaubt oder hofft, dass die vorgenannten Methoden aus sich heraus für Innovation sorgen könnten, übersieht, dass eine Kultur der Zusammenarbeit bereits vor Anwendung neuer Methoden funktionieren oder mit deren Hilfe hergestellt werden muss. Zusammen mit vielfach bewährten Prozessen wird eine Grundlage für die Weiterentwicklung des Bewährten hin zu etwas Neuem geschaffen. Und dann erst ist der Weg frei für Innovation im komplexen Geschäft des Planens und Bauens.

Was ist eure Sicht auf Innovation in der Baubranche? Welche Erfahrungen habt ihr mit Agile, Lean Construction und BIM gemacht? Wo seht ihr die Zukunft der Baubranche?

Ihr seid eingeladen, mit uns zu diskutieren und gemeinsam Ideen zu entwickeln. Kommt am 13. März 2019 zum Meetup „Innovation & Bau? Das Potential von Agile, Lean und BIM“. Wir freuen uns auf euch!

Hier könnt ihr euch anmelden!

Scaling Agile – a different approach – Leadership 4.0

What do companies like Leap, Freitag, Patagonia and even Apple have in common? They came up with a different kind of leadership; In order to create an agile or self-organizing culture, you need to have people in top-management positions that have a different understanding on how to run a company. In the final video of this tutorial series about scaling agile, Boris Gloger introduces some new ideas about how to change the way decisions are made and how to create an environment in which everyone has the same goal.

In jedem steckt ein Genie. Man muss es nur wecken können.

Jeder ist ein Genie! Aber wenn du einen Fisch danach beurteilst, ob er auf einen Baum klettern kann, wird er sein ganzes Leben glauben, dass er dumm ist.“ – Albert Einstein

Mit diesem Bild des Fisches, der immer wieder vergeblich versucht, den Baum zu erklimmen, beschreibt Albert Einstein sehr bildlich ein Dilemma, dessen Auswirkungen wir tagtäglich zu spüren bekommen. Obwohl oder gerade weil wir uns in einer stark leistungsorientierten Gesellschaft befinden, fokussieren wir uns sowohl im beruflichen als auch im privaten Kontext viel zu häufig auf unsere Schwächen. Dasselbe gilt für den Umgang mit unseren Mitmenschen: Wir thematisieren tendenziell eher ihre Fehler anstatt ihrer Glanzleistungen.

Fragen Sie sich doch einmal selbst: Was sind Ihre Stärken und was Ihre Schwächen? Mir persönlich fallen sofort fünf Dinge ein, die mir nicht liegen oder die ich in Zukunft besser machen möchte. Bei der Formulierung einer Liste von fünf Stärken liegt mir der Stift schon deutlich schwerer in der Hand. Woran das liegt, ist schnell beantwortet: Von klein auf widmen wir einen Großteil unserer Zeit den fehlenden Kompetenzen. Egal ob Schulfächer, Tätigkeiten in der Ausbildung oder Aufgaben im Beruf – uns wird recht schnell klargemacht, worin wir noch besser werden müssen.

Was bringt uns wirklich weiter?

Müssen wir uns mit aller Kraft zu Dingen zwingen, die uns gar nicht liegen? Dass wir unsere Zeit viel besser in unsere Talente investieren können, verdeutlicht eine Studie, die bereits 1950 in Nebraska durchgeführt wurde. Diese verglich die Lesefähigkeit von normal begabten StudentInnen mit der von anderen StudentInnen, die sich durch eine besondere Lesebegabung auszeichneten. Es zeigte sich, dass normal begabte StudentInnen durch Übung von ursprünglich 100 gelesenen Wörtern auf bis zu 250 Wörter pro Minute kommen können. Aber: Die begabten KollegInnen konnten ihre Lesefähigkeit von anfangs 250 auf bis zu 2.900 Wörter pro Minute steigern. Sie erreichten somit ein fast 12 Mal besseres Ergebnis und hatten dabei auch noch Spaß.

Mir ist dieses Thema gerade im Bereich der Team-Facilitation so wichtig, weil ich davon überzeugt bin, dass Teams nur optimal funktionieren, wenn jeder seine individuellen Stärken einbringen kann. Ich selbst habe den Anspruch, in meinen agilen Teams ein Arbeitsumfeld zu schaffen, in dem man Spaß an seinen Aufgaben hat und die Teammitglieder jeden Tag mit guter Laune und voller Tatendrang zur Arbeit kommen. Eine wichtige Rahmenbedingung ist deshalb für mich, dass jede Kollegin und jeder Kollege die individuellen Talente nutzen kann. Denn nur so hat man das Gefühl, etwas erreichen zu können und Tag für Tag seinen Teil dazu beizutragen, dass das Team immer ein Stückchen besser wird. Und nur so kann man die erstrebten Ziele umsetzen und vielleicht sogar übererfüllen.

Durch einen Kompetenzworkshop das Bewusstsein für die individuellen Fähigkeiten stärken

Um die Stärken eines jeden Einzelnen gezielt einsetzen zu können, muss man sich diese jedoch erst einmal bewusstmachen. Ich unterstütze meine Teams gerne durch einen gemeinsamen „Kompetenzworkshop“ dabei, sich auf ihre individuellen Fähigkeiten zu fokussieren. In diesem Workshop darf jeder innerhalb von 15 Minuten seine eigenen Kompetenzen in Form eines „Kompetenzbaums“ visualisieren.

In den fest verankerten Wurzeln werden die Kernkompetenzen und das erlernte Wissen dargestellt. Der stetig wachsende und kräftiger werdende Stamm, der von Baum zu Baum ganz spezifische Strukturen haben kann, zeigt die Erfolgsfaktoren jedes Einzelnen. Dort ist Platz für die USPs (unique selling points = Alleinstellungsmerkmale), die jedes Teammitglied einzigartig und unabdingbar machen. Die Krone des Baums bildet eine prächtige, immer wieder nachwachsende Laubpracht, in der sich der persönliche Mehrwert wiederfindet, den das Teammitglied für das Team oder den Kunden generiert.
Nach Ablauf der 15 Minuten stellen alle ihren eigenen Kompetenzbaum kurz vor und hängen ihn gut sichtbar im Raum auf.

Dann beginnt mein Lieblingsteil der Übung: Jeder darf nun in einem Gallery-Walk die Kompetenzbäume der anderen vervollständigen. Hierbei ist es immer wieder erstaunlich, welche USPs und bereichernden Fähigkeiten man an sich selbst gerne übersieht. Indem die Kolleginnen und Kollegen diese offenlegen, geht man auf einmal viel bewusster mit ihnen um. Man nimmt sie nicht nur wahr, sondern erkennt auch Situationen, in denen man diese einsetzen kann, oder man entdeckt, wie die eigenen Fähigkeiten die der anderen Teammitglieder ergänzen können.

Kompetenzbaum

Nutzen Sie die Talente der einzelnen Teammitglieder und profitieren Sie als Team davon

Mit dieser recht simplen Übung stelle ich das Bewusstsein über die Unterschiede im Team her und sensibilisiere den Blick für die jeweils starken Seiten und Begabungen eines jeden Einzelnen. Gleichzeitig haben der Gallery-Walk und die Vervollständigung der Kompetenzbäume durch die Kolleginnen und Kollegen einen tollen wertschätzenden Nebeneffekt.

Natürlich ist mir klar, dass sich unsere Schwächen nicht in Luft auflösen, indem wir uns allein auf unsere Stärken fokussieren. Und selbstverständlich werden in bestimmten Berufsfeldern gewisse Grundanforderungen vorausgesetzt. Spiegeln sich diese nicht in den Fähigkeiten eines Bewerbers oder einer Bewerberin wider, wird es in diesem Arbeitsumfeld immer schwer sein. Wir sollten den Fokus unserer Aufmerksamkeit jedoch weg von den Fehlleistungen hin zu den Begabungen eines jeden Einzelnen lenken. Denn nur so können wir die individuellen Eigenschaften und das Genie, das in jedem von uns schlummert, optimal nutzen und in unser Team und die Arbeit einfließen lassen.

Scaling Agile – a different approach – Do Scrum or any other Agile Management Framework

Scaling Agile can be a big challenge for companies as they have to make significant adjustments throughout the organization. However, how to manage this kind of change? One of the basic ideas of Scrum and other Agile Management Frameworks is to create reflexive processes. Why is that necessary? You can only change the direction of a system if you are aware of the environment and every person within the system. For further insight, watch this video.

I cannot see, what I do not know – why agile transitions need guidance.

Have you ever searched for something you did not know what it is, how it looks like or where you could find it? Sure you have. You even may have heard, read about it or maybe even seen it but you never experienced it for real. But, why do I ask this question?

What Agile and the jungle have in common

Last winter I went to the rainforest of Costa Rica to see an impressive nature and to observe numerous animals in the jungle. I have seen many of them in magazines or documentaries and read a lot about them before, but when I was in the jungle, I couldn’t see any animal I was hoping to see. Just with the help of an experienced guide, I was able to see the obvious. Animals were hiding everywhere, even right in front of me. However, without his help, I would not have spotted them.

I wondered why this is the case, but then I remembered a sentence I have once read: “You cannot see what you don’t know or never experienced.” This made so much sense when I was standing there in the middle of the jungle all alone. I didn’t even know what to do to find the unknown. Even when I discovered one kind of a frog, the typical Costa Rican frog with a green body and red hands, it was difficult to spot the same species again. For example, this Costa Rican frog (red-eyed treefrog) may hide in or under leaves, but the other species like the poison dart frog live on the ground in the wetland.

When I realized that in order to discover new things such as animals I need to go to places which I am not acquainted yet, I knew it counts for so much more than the jungle. It counts for almost everything in life, for raising children, for culture in a country or company, for learning and so much more. My conclusion is that everybody needs to accomplish different kinds of tasks. In other words, it takes different capabilities, perspectives and experience to identify a variety of solutions and ideas; this insight can be applied in various aspects of life.

I cannot see when I do not know what to look for. I cannot do what I do not know how it looks like.

You teach what you know

Take your children as an example: Why is it a common belief that you tend to raise your kids similarly as your parents have raised you? Of course, the answer is quite simple: You have never experienced or seen anything else. Why would you do something different without knowing how it works/feels or even without knowing its existence?

It´s the same in the jungle: How should you find the red-eyed treefrog without knowing where it is or how it even looks like? Maybe you will be lucky and spot the frog one time, but it’s not replicable.

Guidance through knowledge

You can apply this view to all our businesses: Managers often expect from their employees that they will change their behavior to a more agile way in their daily work immediately. Without knowing, seeing, experiencing an agile way of working. Without someone who shows them how it could be and how it works, it is almost impossible to change.

Often, the people who tell us to change have not yet experienced the “new way” of working; like a guide in front of the jungle, who tells us that there will be a red-eyed frog in this forest, without knowing how the frog looks like.

I experienced that some people who have the responsibility for a company transition or introducing the agile way in their company, have no idea what it could look like. Often, they have not even seen a flexible, fast-moving and an adaptive company which has integrated the “agile way” in their DNA. If they have never worked in an agile environment, how should they lead the company in the right direction? How should we trust someone if that person doesn’t know the right path? Eventually, they choose the way they already knew, and we all know where that will lead us.

So, what do we need to do? Get in touch with experts, who are running agile organizations. Visit companies that are already agile. See how they work, how they make decisions, which tools they use, how they prototype, communicate and so on. Collaborate with them and feel their way of working and transform it into your company in your way. Get inspired! Each agile company got a list of books they had read before they engaged in a transformation. Make space in your strategic portfolio to reduce multitasking and start finishing the right things. Create an engaging environment and make it as easy as possible for your employees to learn, to visit places and to get in contact with companies that inspire you.

It is like in the jungle, do not wait and search too long. As a manager, you need to show your employees and colleagues the hidden animals and if you cannot do so, go out and find a guide and ask him for support. Let him show you how it is done. What seems so difficult for you, can be so easy for him.

Scaling Agile – a different approach – Design Thinking

We have already discussed the impacts of scaling Agile on architecture, infrastructure and the skill set in the previous videos. In this episode, we focus on an essential aspect of agile product development: user-centricity. First of all, we need to clarify: There is no real user centricity out there in the market. Why? If you are looking for a particular product, you will always be limited to the products on the shelves. However, and that is the difference that counts, with agile methods like Design Thinking we try to understand what the real problem for the user is. How does this work? Watch the video to find out.

Scaling Agile – a different approach – Skills

As we have already seen in the previous episodes of this series, an agile environment is not only characterized by values and faster pays, but also by new kinds of architecture and infrastructure. But, how could you handle this new environment with your existing skill set? The truth is: not at all. In an agile environment, people need to behave differently and therefore require a new skillset. Check out this video to get better insights.

Scaling Agile – a different approach – Infrastructure

In the previous episode of this series about scaling Agile, we talked about the necessity of a decoupled architecture. In this episode, we take a closer look at what qualifications have to be fulfilled at the infrastructural level. In general, you need to make sure that the teams can communicate with each other, that they have a technical infrastructure of integration; and space that enables teams to work in an agile way. So, which measures should you take? Watch this video to find out.

Scaling Agile – a different approach – Scrum Teams and Architecture

Scaling Agile can be a big challenge for organizations. As explained in the last video, six levels should be adapted within the organization to scale successfully. At the architecture level, it is essential to enable teams to work independently from other units. In this video, I give you insights about how to decouple architectures.

“Want To”, “Can Do” or “Allowed To” – Or why you get resistance when implementing change

“We don’t have the right people to implement Agile. They don’t want to change.” This attitude impedes the transformation of many traditional companies, and it might often look as this was true. However, let us dig a little deeper. Why do people not change? Well, maybe they would like to change but they can not. Resistance is not necessarily a sign of refusal, but rather an indicator of people missing the right skillset. I firmly believe that transitions are not about changing oneself, but learning a new skillset. For more insights, watch my new video.

From the Agile Stonehenge to the Agile Next Generation – Why you need to see the broader picture

Since the first successful implementations of Scrum, Agile has run through an evolution. Today, it is more than Scrum. We talk about scaled solutions like LeSS or huge LeSS, about the Spotify model, OKR or Agile Leadership; to name a few. In this video, I give you a solid overview of the history of Agile. Why does that matter? Before you can find the right way for an organization, you’ll want to define where you are at the moment precisely.

Über Dinosaurier, elektrische Zäune und agile Transformation

Im Film Fack ju Göhte erhalten die SchülerInnen eine ungewöhnliche Aufgabe. Sie sollen aus der Ich-Perspektive beschreiben, was ein Dinosaurier fühlt, wenn er merkt, dass der elektrische Zaun ausgeschaltet ist. In den ersten, zaghaften Interpretationen dieser neuen Freiheit zeigen sie, welch schönes Gefühl es sein kann, machen aber gleichzeitig deutlich, wie viel Ehrfurcht sie davor haben. Sie öffnen sich sehr vorsichtig dem Neuen, oft aus einer Position des Misstrauens, ob das Neue tatsächlich das mit sich bringt, was es verspricht.

Mit einer ähnlichen Herausforderung sehe ich mich häufig in Teams konfrontiert, die es gewohnt waren, in hierarchischen Systemen zu arbeiten, und jetzt in Kontakt mit der agilen Welt kommen. Insbesondere, weil Agilität auch die etablierten Werte eines Unternehmens infrage stellen kann. „Office Politics“ und Hierarchien aus der alten Welt gehen kaum Hand in Hand mit agilen Werten wie Offenheit, Transparenz und Commitment. Diese 180-Grad-Wende wird mitunter als sehr bedrohlich in etablierten hierarchischen Systemen interpretiert.

Doch agile Methoden öffnen für viele Menschen in der heutigen Arbeitswelt den oben beschriebenen Elektrozaun – hin zu einer Welt der Selbstorganisation, in der die Entscheidungen dort getroffen werden, wo auch die nötigen Informationen vorhanden sind. Doch ebenso viele fühlen sich mit dieser Freiheit überfordert. Eine solche Überforderung oder auch Bedrohlichkeit kann viele Gründe haben: eine angenommene höhere Arbeitsbelastung, die fehlende Wahlfreiheit, agil arbeiten zu wollen, und der Wandel des eigenen Arbeitsumfelds. Die einstige, klar definierte Person an der Spitze der Pyramide, die als Kämpfer für die MitarbeiterInnen, den Fortbestand der Arbeit und als “Single Point of Truth” galt, verschwindet in diesem neuen Umfeld zusehends. Bereits die Rollentrennung in Product Owner und ScrumMaster und die Aufspaltung von Produkt- und Prozessverantwortung schaffen Neues und werden dementsprechend kritisch betrachtet.

Früchte müssen wachsen, bevor wir sie ernten können

Häufig macht sich bei den Impulsgebern des Wandels Verwunderung breit, wenn Menschen durch die Freiräume und Selbstverantwortung der agilen Arbeitswelt erstmal gehemmt sind und diese neuen Freiheiten gar nicht nutzen wollen. Doch der Mensch beschreibt sich gerne als Gewohnheitstier und verfällt in diesem Moment tendenziell zurück in alte Muster.

Diese Skepsis Neuem gegenüber und der damit verbundene Widerstand sind natürlich und menschlich. Mit der Change-Kurve von Elisabeth Kübler-Ross und in den Arbeiten von John Kotter, allen voran „Leading Change“ wurde dieses Phänomen sogar in wissenschaftlicher Präzision analysiert. Laut diesem Werk von Kotter scheiterte über die Hälfte seiner untersuchten Veränderungsprojekte bereits sehr früh am Widerstand der MitarbeiterInnen, ihre eroberte Komfortzone verlassen zu müssen. Davon sind agile Transformationen nicht ausgenommen. Sie verharren nach meinem eigenen Erleben genau dort, aufgrund des Widerstands der MitarbeiterInnen gegenüber dem Neuen und Unbekannten.

Aber wie schaffen wir es, den Menschen bessere Anreize für diese neue Freiheit zu bieten, sie zu selbstverantwortlichem Handeln anzuregen, damit sie die Früchte der agilen Transformation möglichst schnell ernten können? In der Transformation großer Unternehmen sind es besonders auch die alten Muster, die helfen können, eben jene Transformationen zu beschleunigen.

Gewohntes verwenden, um Neues zu schaffen

Der bewusste Einsatz von traditionellen Elementen des “Command & Control”-Führungsstils mag zwar zunächst kontraintuitiv wirken, kann aber die nötige Brücke zwischen Altem und Neuem schlagen. Als Top-down-Enabling, um ein Bottom-up-System zu etablieren.

Für die Rolle des ScrumMasters kann das bedeuten,

Es ist natürlich eine Gratwanderung, aber der bewusste Einsatz von “Command & Control” kann Menschen helfen, sich an ein Bottom-up-System zu gewöhnen.

Neue Teams, die noch nie mit Scrum gearbeitet haben, schauen in den ersten Momenten auf den ScrumMaster und können seine Rolle nicht richtig einordnen. Gleichwohl schauen sie aus Gewohnheit auf die Elemente seiner Führung und sehen ihn aufgrund ihrer Vergangenheit als Führungskraft – weniger lateral als vielmehr hierarchisch. Diesen Effekt zu nutzen, kann in den ersten Sprints helfen, einem Team die Umstellung einfacher zu gestalten.

Wenn meine Teams also auf die Idee kommen, dass die Meetings nicht sinnvoll wären, dass sie nicht verstünden, warum wir ein Daily abhalten oder Ähnliches – dann kann der bewusste Einsatz von “klaren Ansagen” helfen, um Widerstände zu überwinden und die Methodik als indiskutabel hinzustellen. Die freigewordene Energie kann dann in Dinge und Diskussionen fließen, die das Team wirksam voranbringen. Zum Beispiel in die Klärung der Frage, wie man die einstmals beschriebenen Freiheiten von Scrum denn nun erringen und nutzen kann.

Veränderung geht nicht von heute auf morgen

Mit der Zeit akzeptieren die Teammitglieder den Rahmen der Meetings und Rollen immer mehr und verlieren die Scheu vor dem Neuen. Wenn man im gleichen Atemzug schnell und transparent zu Ergebnissen kommt oder wenn Teammitglieder die Retros mit kommunikativen Inhalten füllen – spätestens dann ist es an der Zeit, sich von Elementen des hierarchischen Führungsstiles komplett zu lösen. Sie wirken dann nicht mehr als „Enabler“ von transformationellen Prozessen, sondern als Hindernis und sind nicht länger notwendig.

Ähnlich wie die SchülerInnen im Eingangsbeispiel brauchen manche Teams einfach einen kleinen Stupser in die Freiheit. Wenn dieser ein letztes Mal mit alten, aber vertrauten Führungsmethoden erfolgt, kann das helfen. Dann fühlt sich der Start vielleicht nicht so ungewohnt und orientierungslos an.

Agile is not about culture – Agile is about delivering value

In the agile community, many people believe that we would have to change the culture first, to be able to implement agile methods successfully. The problem is: changing the culture takes years; quite apart from the fact that one can not change the culture by, well, changing the culture. Agile has always been about delivering value, and it still is.

Agile Values = Scrum Values – Agile comes with a mindset

The fundamental objective of agile methods is to make teams more productive. However, is it the agile processes themselves that enable us to reach this goal? Or is it more the deep understanding of agile values that boosts the performance of the teams? In my experience, Agile comes with a mindset. In this video I will show you the agile values and why they are so essential to implement new processes successfully.

Der Gehaltsprozess bei borisgloger: das Beurteilungssystem in einem agilen Unternehmen

Boris, unser Gründer und Geschäftsführer, hatte keine Lust mehr. Er empfand es als belastend, zeitraubend und nicht wirklich agil, dass er über das Gehalt seiner Mitarbeiterinnen und Mitarbeiter entscheiden sollte. Jedes Jahr aufs Neue kamen sie auf ihn zu und baten um eine Gehaltserhöhung. Während der Kollege oder die Kollegin im Gehaltsgespräch darlegte, weshalb eine Gehaltserhöhung angemessen wäre, mimte Boris den Gegenpart und erörterte, wie er oder sie sich entwickeln müsste, um das verlangte Gehalt zu verdienen. Man traf sich mehr oder weniger in der Mitte und selten waren beide Seiten wirklich zufrieden. Es müsste doch einen anderen Weg geben, um die Gehälter festzulegen. „Ask the team“, dachte sich Boris. Weshalb sollten sich seine Leute nicht selbst Gedanken über dieses komplexe Thema machen und ein Beurteilungssystem entwickeln, durch das sich die Gehälter am Nutzen der jeweiligen Person für das Unternehmen ableiten ließ. Die Gehaltsgilde von borisgloger consulting war geboren.

Gehalt, Bonus, OKR – Warum?

Beurteilungs-, Belohnungs- und Gehaltssysteme stehen in einem engen Zusammenhang. Um die jeweils gewünschten Effekte gezielt steuern zu können, sollten sie jedoch voneinander getrennt betrachtet werden:

In einem agilen Unternehmen strebt man danach, die Mitarbeitenden nicht mehr auf Basis individueller Zielvereinbarungen (Management by Objectives) auf die Unternehmensziele auszurichten. Vielmehr sollen Teams selbstständig – ausgehend von den Unternehmenszielen – die Ziele für ihren jeweiligen Bereich ableiten (OKR – Objectives and Key Results).

Wer beurteilt wie?

In vielen Fällen ist der disziplinarische Vorgesetzte für eine nachvollziehbare und faire Einschätzung nicht nah genug an der Arbeit des/der einzelnen Mitarbeitenden dran. So können Teamarbeit und die Persönlichkeit des zu beurteilenden Mitarbeiters das Bild verzerren, und ein extrovertierter, aber fauler Kollege rühmt sich mit der tollen Arbeit einer schüchternen, fleißigen und klugen Mitarbeiterin. Es liegt daher nahe, diejenigen die Arbeitsleistung beurteilen zu lassen, die am nächsten an der Arbeit dran sind – also die unmittelbaren Kolleginnen und Kollegen.

Bei borisgloger consulting haben wir uns für ein System des kontinuierlichen Kollegen-Feedbacks entschieden (Continuous Development Feedback/CDF). Viermal pro Jahr hole ich mir dieses Feedback ein und dokumentiere es. Ich suche mir selbst aus, welche KollegInnen mir dieses Feedback geben sollen. Dabei berücksichtige ich, inwieweit die jeweiligen KollegInnen mir tatsächlich konstruktives Feedback geben können, da sie in Projekten oder im Team nahe genug mit mir zusammenarbeiten. Zur Unterstützung dieses Prozesses gibt es verschiedene Apps, wie zum Beispiel Reflektive, TinyPulse, Impraise, Small Improvements. Ein kontinuierliches und somit zeitnahes Feedback bewirkt nicht nur, dass sich der jeweilige Kollege/die jeweilige Kollegin kontinuierlich während des Jahres entlang des erhaltenen Feedbacks entwickeln kann, sondern es bewahrt auch vor psychologischen Verzerrungseffekten.

Von der Beurteilung zum Gehalt – der Gehaltsprozess bei borisgloger consulting

Einmal pro Jahr kommt bei borisgloger consulting die Gehaltsgilde zusammen. Sie rekrutiert sich aus den Product Ownern unserer Teams und jeweils einem gelosten Vertreter aus den verschiedenen Levels (Management, Senior sowie Executive Consultant). Ist das Unternehmensergebnis positiv und sieht auch die Prognose für das kommende Jahr positiv aus, wird ein Topf für Gehaltserhöhungen festgelegt, den es nun zu verteilen gilt.

Die Gehaltsgilde würdigt das CDF jedes Kollegen/jeder Kollegin und gleicht die objektiven Kriterien Auslastung, Publishing, Methoden-Know-how, Führung, Prozesskompetenz und Business Development/Sales. Nachdem auf diese Weise ein Überblick über die zu beurteilenden KollegInnen geschaffen wurde, werden alle KollegInnen in Relation zueinander von den Gildenmitgliedern im Stile von Magic Estimation geschätzt.

Dabei gilt: Je höher der Kollege/die Kollegin innerhalb des Gehaltsbands seines Levels eingestuft ist, umso weniger kann sich das Gehalt innerhalb des Gehaltsbandes erhöhen.

Wurden alle MitarbeiterInnen geschätzt, wird der Inhalt des zuvor festgelegten Topfs in Relation zum jeweiligen Gehalt verteilt.

Wie geht es uns mit diesem Prozess?

Die Gehaltsfindung soll gerecht sein. Doch das Streben nach Gerechtigkeit wird oft von Missverständnissen und persönlichen Ansichten beeinflusst. Nie sind alle zufrieden. Jeder strebt nach mehr. Der Schlüssel zum Erfolg kann hier in einem höchst möglichen Maß an Transparenz, Einbeziehung und Kommunikation liegen, um Entscheidungen nachvollziehbar zu machen. Neben der Diskussion über das Gehalt ist es daher auch unerlässlich, den Mitarbeiterinnen und Mitarbeitern alle relevanten Unternehmenszahlen zur Verfügung zu stellen, um ein Bewusstsein für die finanziellen Möglichkeiten zu erzeugen. Denn nicht mehr Gehalt fördert die Zufriedenheit, sondern transparente Rahmenbedingungen und eine sichere Perspektive. Oder wie Boris zu sagen pflegt: Wer wegen des Geldes kommt, geht auch wegen des Geldes.

 

Bild: CCO Creative Commons: Pixabay

Wer das Alte ganz wegwirft, wird das Neue nicht lange haben 

Wer sich mit Agilität als Weg in die Zukunft für das Unternehmen beschäftigt, wird schnell den Eindruck gewinnen, dass alles Bisherige über Bord geworfen werden muss. Aber ist das tatsächlich so?

Eine typische Situation: Ein mittelständisches oder gar großes Unternehmen sucht den Ausweg aus einer Produktentwicklung, die Jahre in Anspruch nimmt – der Markt fordert jedoch kürzere Entwicklungszyklen, häufigere Produktreleases. Das Geschäftsmodell, vor zehn Jahren noch profitabel und innovativ ausgerichtet, scheint eher am Markt vorbei ausgerichtet zu sein und hat unattraktive Renditeziele. 

Eine Veränderung muss her. Es scheint, als steuere das Unternehmen direkt auf sein Ende zu, wenn nicht schnell und umfassend eine Umstrukturierung vorgenommen wird. Hier verspricht Agilität, die als Hype durch deutsche Unternehmen geht, Besserung und Rettung. Also wird ein Projekt aufgesetzt, es soll ja klein begonnen werden. Ein bis zwei Teams werden identifiziert, die für das gesamte Unternehmen die neue Methode ausprobieren. Auserkoren werden solche Teams, die möglichst wenige Schnittstellen zu anderen Bereichen haben, um dieses Experiment möglich zu machen. Es läuft vielversprechend, aber man muss doch vieles für diese Teams anders machen. Durch die Selbstorganisation reichen ein Product Owner und ein Scrum Master als Kommunikatoren ins Unternehmen. Das Team, alles Freiwillige, stürzt sich mit Begeisterung in die Arbeit und kann ungestört „produzieren“.

Nach etwa einem Vierteljahr sind erste Ergebnisse sichtbar und werden im Review vorgestellt. Lange PowerPoint-Präsentationen? Weit gefehlt. Ein MVP wird vorgestellt, ist testbar. Statt eines nichtssagenden Projektstatusberichts kann der Fortschritt „live“ auf dem Board nachvollzogen werden. Product Owner und Scrum Master tun alles, um das richtige Produkt erarbeiten zu lassen und das Team produktiv zu halten. So weit so gut.

Das erfolgreiche Projekt soll mit diesen Erfahrungen nun auf das Unternehmen ausgerollt werden. Bevor ich darauf eingehe, welche Gründe dafür sprechen, das behutsam und mit Blick auf ein gesundes Maß zu tun, hier noch ein paar Punkte zur Agilität.

Wie viel Agilität ist notwendig?

Die Überschrift zu diesem Beitrag ist ein chinesisches Sprichwort. Es gefällt mir deshalb so gut, weil es beschreibt, was passiert, wenn man unreflektiert Agilität verordnet.

Die Prinzipien und Werte des Agilen Manifests sprechen nicht davon, alles Bisherige einfach über Bord zu werfen. Es geht darum, die richtige Mischung zu finden, durch die das Unternehmen transformiert werden kann. Aus meiner Sicht ist es sogar wichtig zu überlegen, wie weit man damit gehen will, denn es wird immer Bereiche geben, die nicht zwangsweise agilisiert werden müssen. So wie man Six Sigma nicht unbedingt im Vorzimmer des Vorstandsvorsitzenden einsetzen wird, ist Scrum nicht sinnvoll, wenn es um klare Prozessabläufe in den Supply Operations geht.
Bei einer Neuausrichtung oder Restrukturierung wird im Unternehmen ja auch geprüft, welche Ressourcen und Fertigkeiten vorhanden sind, welche man aufbauen möchte und welcher finanzieller Spielraum für Investitionen vorhanden ist. Was spricht dagegen, das auch bei der Einführung von agilen Methoden zu tun?

Was vom Alten sollte bleiben?

Auch wenn das Ziel ist, ein „neues“ Unternehmen zu schaffen, so ist es doch nachhaltiger und zielführender, das Vorhandene auf Wiederverwertbarkeit zu prüfen. Die Transition von einem klassischen Unternehmen hin zu einem agilen ist mit enormen Veränderungen verbunden. Nicht nur Material wird dafür benötigt, in erster Linie wirkt es sich auf die Mitarbeiter aus. So verlockend die Idee ist, dass sich Mitarbeiter selbst führen, motivierter und produktiver sind: Es sind Menschen. Sie brauchen dennoch oder gerade in Zeiten der größten Veränderungen, wie zum Beispiel bei der Einführung von selbstorganisierten Teams, viel Führung und Anleitung in der Frage, wie das gehen kann.

Wissen ergänzen

Geprüft sollte auch werden, welches Rüstzeug das Unternehmen mitbringt und dabei sind Investitionen in 3D-Drucker für das Prototyping noch das Konkreteste. Auch hier gelingt die Veränderung am besten, wenn man die Menschen auf diese Reise mitnimmt und sie mit weiterem Können ausstattet. Dabei geht es manchmal einfach darum, das vorhandene Wissen zu ergänzen. Einen Konstrukteur oder Einkäufer wird man selten als Softwareentwickler einsetzen können. Aber in Mob-Programming-Teams können sie dazu beitragen, schneller und qualitativ bessere Produkte zu liefern. Ihre Anforderungen und Expertise gehen direkt in das Produkt ein und umgekehrt nehmen sie Wissen über die Entstehung des Produkts mit.

Säulen der Identität erhalten

Wie in einem Haus, das man renoviert, sollte man die tragenden Elemente suchen und behalten. So lange, bis das Neue trägt und das Alte ersetzt hat. Das können Menschen sein, mit denen sich die Mitarbeiter identifizieren, das können Rituale wie etwa ein Unternehmenstag sein, an dem sich Mitarbeiter mal „privat“ kennenlernen können. Es können altgediente Gebäude sein, die eine Atmosphäre von Vertrautheit verströmen.

Die Transition ins Agile ist emotional. Das liegt daran, dass die Menschen ihr Mindset verändern werden. Der Product Owner kann dem Scrum-Team zum Beispiel keine Anweisungen erteilen. Beim Design Thinking gilt bei der Ideenfindung „kill your darlings“ (töte deine Lieblinge), um wieder zur Pluralität und damit zu den Ideen zu finden, die den Kundenbedarf am besten decken. Die Veränderung betrifft alle unsere Werte, die wir mitbringen und unsere Erfahrungen, die wir bis dahin im Leben gemacht haben.

Unterstützung gezielt einsetzen

Aus diesem Grund kann gezielte Unterstützung durch die Untiefen der Transformation eine wertvolle Hilfe sein. Den Blick von außen und das Wissen um die Möglichkeiten, die agile Methoden bieten, sollten Sie sich an Bord holen. Ein guter Lotse wird ihnen zeigen, worauf Sie gerade Ihre Aufmerksamkeit richten sollten und wo der Hafen liegt. Um es mit Seneca zu sagen: „Wer den Hafen nicht kennt, für den ist kein Wind der richtige.“ Je nachdem, wo Sie auf der Reise gerade sind, kann die praktische, operative Unterstützung zum Beispiel in Methodentrainings oder einem Einsatz als Scrum Master bestehen. Die strategische Beratung durch Agile Coaches in einem Transition Team hilft beim Umsetzen in größeren Maßstäben.

Fazit

Agilität ist für jedes Unternehmen interessant, solange der Wandel mit Augenmaß und wertschätzend geschieht. Es ist keine bloße Formel oder ein Business Case, der sich durchrechnen lässt und zum Zeitpunkt X Rendite abwirft. Aber es ist ein vielversprechender Weg in einer digitalen Welt, die sich immer schneller dreht. Richtig eingesetzt bietet Agilität die Chance, das Beste aus Alt und Neu miteinander zu verbinden.

 

Foto: CCO Creative Commons –Pixabay

“Agile – What?” oder doch besser Why?

Ende August hatte ich die tolle Gelegenheit, bei einem Netzwerktreffen studentischer Unternehmensberater an der Technischen Hochschule Ingolstadt mehrere Workshops zu gestalten. Die Überschrift lautete zwar „Agile – What?“, doch die Jung-BeraterInnen merkten schnell, dass es mehr um das „Why“ als um das „What“ geht.

Denn warum machen wir das, diese Agilität? Wie die meisten nach ihrer ersten agilen Schulung wissen, ist Agilität mehr als ein Rahmenwerk. Zwar ist die Methodik die Basis, doch die funktioniert nur, wenn die formulierten Werte und Prinzipien gelebt werden. Oft fallen dann in Schulungen und Workshops Sätze wie: „Das ist mir ein bisschen zu esoterisch!“ oder „Ich brauche etwas, das einfach funktioniert!“ Um heute und in Zukunft zu überleben, brauchen Unternehmen Ideen, die zügig umgesetzt werden können. Doch es ist kein rationaler Prozess: Ideen können nicht wie am Fließband produziert werden, sondern entstehen oder eben nicht. Intuition ist daher jene Stärke, die mehr denn je benötigt wird. Wir merken, dass das Bauchgefühl eine große Rolle spielt.

Neben dieser menschlichen Komponente gibt es aber eine weit rationalere, systemische Komponente, die uns zeigt, warum man es mit der Agilität versuchen sollte.

Schöner scheitern – fail fast

William Ross Ashby formulierte schon in den 1950er-Jahren das nach ihm benannte Gesetz der erforderlichen Varietät. Dieses Gesetz besagt: Je größer die Varietät eines Systems ist, desto mehr kann es die Varietät seiner Umwelt durch Steuerung vermindern. Oder mit den Worten von Prof. Peter Kruse (siehe dieses Video): „[…] wo immer wir ein hochkomplexes dynamisches Problemsystem haben, brauchen wir im Minimum ein so komplexes dynamisches Lösungssystem. Doch von alleine besitzt ein Unternehmen nicht dieselbe dynamische Komplexität, wie die ihres Umfelds. Was es dazu braucht, ist eine Kultur, in welcher die Menschen die Möglichkeit erhalten, Dinge auch einfach mal auszuprobieren, um damit wirklich kreativ zu sein.“

„Fail fast“ sollte also das Motto sein. Ein Zustand, der gerade in Großunternehmen eher fern zu sein scheint. Fehler werden in einer hierarchischen Organisation direkt sanktioniert und Kreativität hat hier mehr mit dem „Tanz aus der Reihe“ zu tun. Ein möglicher Weg, den viele große Unternehmen wählen, ist die Veränderung der Kultur durch ein Change-Programm.

Das Kulturveränderungsprojekt – kann man Kultur wirklich entwickeln?

Ja, kann man, aber wie Professor Kruse schon sagte: Kultur ist eine indirekte Variable. Kultur ist leider keine Projektarbeit. Es können nur Rahmenbedingungen geschaffen werden, in denen sich die Muster einer Kultur in irgendeine Richtung entwickeln. Welche Richtung die Kultur einschlägt, ist dabei nicht vorhersehbar.

Diese Aussage bietet gerade den agilen Frameworks eine Steilvorlage. Denn Agilität bedeutet nicht mehr als flexibel, proaktiv, antizipativ, aber vor allem initiativ zu agieren, um notwendige Veränderungen anzustoßen. Agile Frameworks wie Scrum bieten die Möglichkeit, in regelmäßigen Abständen komplett neu auf diese Welt zu blicken, um womöglich eine völlig neue Richtung zu gehen.

Ein Beispiel: Die Entwicklung des Space Shuttles

1982: Das Space Shuttle der NASA wird fertiggestellt. Interessant im Kontext agiler Produktentwicklung ist dabei der Umstand, dass die Entwicklung über zwei Jahrzehnte gedauert hat und das Space Shuttle teilweise auf IT-Systemen aus den 1960ern aufbaute. Dieser sicherlich extreme, zeitliche und technologische Abstand zwischen dem Stellen der Anforderung und der Lieferung kann als Beispiel für ein Problem angesehen werden, das in den 1990ern mit Beginn der PC-Ära als sogenannte „application development crisis“ oder „application delivery lag“ bzw. als Software-Krise bekannt wurde. Mit der Verbreitung des PC änderten sich die Geschäftsmodelle immer rascher. Bei Entwicklungszeiten von mehreren Jahren konnte es daher passieren, dass die Lösung bei Fertigstellung veraltet war. Ein Projekt kann so als gescheitert betrachtet werden, selbst wenn die anfänglich festgelegten Anforderungen geliefert und der Budgetrahmen eingehalten werden.

Agilität ist Hinterfragen des Sinns

Neben dem Warum für Agilität soll es sie daran erinnern, ständig die Sinnhaftigkeit der zu leistenden Arbeit zu hinterfragen. Denn Agilität entsteht durch den Blick auf das Wesentliche, durch Achtsamkeit dem eigenen Tun gegenüber. Das Ausrichten des eigenen Handelns auf den größtmöglichen Wert. Das kontinuierliche Liefern eines für sich allein stehen könnenden Teilprodukts. Mit iterativen, reflexiven Abläufen schafft es Agilität, das Erreichte zu hinterfragen und die Wertschöpfung immer wieder auf das Wesentliche auszurichten. Ist das einfach? Nein. Aber dafür ist es ziemlich spannend und man schafft Wert! Vielen Dank an die TeilnehmerInnen, ich hatte sehr viel Spaß daran, mit euch die Themen zu erarbeiten! Ich wünsche euch viel Erfolg bei euren nächsten Projekten.

 

Der Bundesverband Deutscher Studentischer Unternehmensberatungen (BDSU) engagiert sich seit mehr als 25 Jahren als Dachverband und starker Netzwerkpartner für die führenden Junior Enterprises in Deutschland. An der Technischen Hochschule Ingolstadt wurde 2010 consult.IN gegründet, das inzwischen zu den zehn besten studentischen Unternehmensberatungen in Deutschland gehört. Über 70 hochmotivierte Studenten und Studentinnen sammeln hier während des Studiums Projekterfahrung für den Einstieg in die Berufswelt.

Foto: CC0 Creative Commons – pixabay, NASA-Imagery

Agile Transformation: Mit dem Transition Team Canvas durch die Veränderung navigieren

Wer sich inmitten einer agilen Transformation befindet, kennt gegebenenfalls folgendes Szenario:

Einige Produktentwicklungsteams im Unternehmen arbeiten bereits agil mit Kanban, Scrum, Design Thinking oder anderen Methoden. Die anfängliche Euphorie über die Taskboards, die Rollen von ScrumMaster und Product Owner sowie über die sogenannte „Selbstorganisation“ hat sich gelegt. Die Realität hat die Organisation eingeholt. Selbst bei vermeintlich einfachen Aufgaben, wie dem Bereitstellen eines Teamraums oder dem Anpassen der Stellenbeschreibungen geht es keinen Schritt voran. Es fühlt sich an wie in einer Sackgasse und die Organisation scheint trotz bester Absichten paralysiert.

Um so einem Szenario vorzubeugen, empfehlen wir, vor dem Start der agilen Transformation ein Transition Team zu bilden, das die Transition wie ein Schiff nach vorne navigiert, Stürme meistert und an Klippen und Eisbergen vorbei manövriert. Die Mitglieder des Transition Teams agieren als Change Agents und sorgen dafür, dass Stakeholder rechtzeitig abgeholt werden, unternehmensweite Impediments gelöst werden und der Rahmen für die Produktentwicklungsteams optimiert wird.

Doch wer sollte Teil des Transition Teams sein? Diese Frage habe ich mir auch in meinem ersten Transformationsprojekt gestellt. Die richtige Antwort darauf ist: Jeder, der ins Transition Team gehört. Allerdings half mir diese Antwort damals nicht weiter, also habe ich die Frage in ihre Bestandteile zerlegt. Das Ergebnis ist ein Transition Team Canvas, das als Orientierung dabei unterstützt, die potentiellen Mitglieder des Transition Teams zu ermitteln.

(c) Sabina Lammert

Wer sind die Treiber der Agilität im Unternehmen?

Ich habe sie bisher in jedem Unternehmen erlebt: Jene Mitarbeiter, die lange bevor sie das Wort „agil“ gehört haben bereits nach agilen Werten und Prinzipien gearbeitet und gelebt haben. Nach Everett M. Rogers‘ Diffusionstheorie würde man sie als die agilen „Innovators“ und „Early Adopters“ bezeichnen. Sie sind der neuen Führungsphilosophie und den neuen methodischen Ansätzen gegenüber sehr aufgeschlossen. Sie agieren lösungsorientiert und halten nicht verbissen an alten Strukturen fest. Unabhängig davon, wer von ihnen letztendlich im Transition Team sein wird, ist es gut, sich ihrer Existenz bewusst zu sein.

Wer ist der Visionär der Transition?

Mit dieser Frage starten wir die Suche nach dem Product Owner des Transition Teams, der als Visionär das Ziel der Transformation stets vor Augen hat. Er begeistert und motiviert das Transition Team und darüber hinaus die restlichen Mitarbeiter und Führungskräfte des Unternehmens. Er ist dafür verantwortlich, dass die Transition auf Kurs bleibt und überlegt sich die nächsten richtigen Schritte in Absprache mit den Stakeholdern. Zu diesem Zweck pflegt er sein Transition Team Backlog auf den Ebenen der Architektur, der Infrastruktur, der Skills, der Produktentwicklung, der Methode und der fraktal skalierten Organisation (siehe Pyramide „Bausteine der agilen Skalierung“ in „Scrum Think big“ von Boris Gloger).

Wer sind die Treiber im Top-Management?

Die Unterstützung der Geschäftsführung ist für eine erfolgreiche agile Transformation essentiell. Entscheidungen werden schneller getroffen und man sichert sich die Unterstützung bei kritischen Konfrontationen, wenn man das Top-Management einbezieht. Zum Beispiel kommt es vor, dass es zwischen der IT und den Produktentwicklungsteams Formen des passiven Widerstands gibt: Absprachen zur Optimierung der Releasezyklen werden nicht eingehalten und die benötigte Software wird nur langsam beschafft. „Ansagen von oben“ können in solchen Fällen Berge versetzen.

Welche Abteilungen sind am stärksten von der Transition betroffen?

Das eben genannte Beispiel der IT möchte ich an dieser Stelle noch einmal aufgreifen. Wenn man früh in der Transformation feststellt, dass in einer Abteilung an vielen Stellschrauben gedreht werden muss, ist es durchaus sinnvoll, einen entscheidungsbefugten Vertreter genau dieser Abteilung in das Transition Team zu integrieren. Idealerweise findet man jemanden, der das richtige Mindset hat und lösungsorientiert Impediments bearbeitet. Sind zum Beispiel viele Umzüge notwendig, hat es sich als sinnvoll erwiesen, jemanden aus dem Facility Management im Transition Team zu haben.

Welche Stakeholder möchte man im Transition Team wissen?

Stakeholder, die den Change-Prozess ohnehin unterstützen, kann man hier direkt auflisten. Auf jeden Fall sollte man sich über jene Stakeholder Gedanken machen, die dem Transition Team Steine in den Weg legen könnten. Manchmal lohnt es sich, genau diese Stakeholder ins Transition Team holen, damit sie in die Verantwortung genommen werden und den Weg zur erfolgreichen Transformation ebnen.

Wer sind geeignete Vertreter für ScrumMaster und/oder Product Owner?

Die Produktentwicklungsteams gehören zu den „Usern“ der Transformation. Zu Beginn einer Transformation gibt es in der Regel Pilotprojekte, bei denen erste Erfahrungen mit der agilen Methode gesammelt und dem Transition Team jene Impediments gemeldet werden, die die Scrum Teams nicht selbst lösen können. Damit sich die Organisation am Anwender orientiert entwickeln kann, ist hier ein regelmäßiger Austausch notwendig.

Wen sonst möchte man im Team nicht missen?

Natürlich kann es vorkommen, dass manche Personen(-gruppen) für das Transition Team in Frage kommen würden, aber zu keiner der genannten Fragen als Antwort passen. Jedes Unternehmen ist anders und aus diesem Grund lohnt es sich, immer kurz zu überlegen, wer noch fehlen könnte.

Wer ist in der Lage, den gewählten Kreis lateral zu führen?

Nachdem man die potentiellen Mitglieder aufgelistet hat, muss man noch folgende Kriterien prüfen: Freiwilligkeit, Kapazität und agiles Mindset. Die Teammitglieder werden im Vergleich zu einem Scrum Team nicht zu 100 Prozent für das Transition Team arbeiten und hauptsächlich strategisch tätig sein. Operative Tätigkeiten werden an sogenannte Fokusgruppen übergeben (siehe hierzu „Scrum Think Big“ von Boris Gloger). So wie ein Scrum Team sollte auch ein Transition Team nicht mehr als neun feste Mitglieder haben. Eines dieser Mitglieder ist ein Agile Coach, der die laterale Führung übernimmt. Er sollte sowohl mit dem Top-Management als auch mit den Vertretern der Scrum Teams auf Augenhöhe reden können und eine Hands-on-Mentalität haben, da er die Meetings organisiert, strukturiert und Konflikte im Team frühzeitig adressieren muss. Daher sollte die Wahl auf jemanden fallen, der auch dann durchsetzungsstark und standhaft ist, wenn das Top-Management mit unbequemen Wahrheiten konfrontiert werden muss.

Meine bisherigen Erfahrungen mit dem Transition Team Canvas in Zusammenarbeit mit Kunden waren sehr positiv. Durch die klare Fragestellung in den verschiedenen Feldern kann man sich beim Bilden des Transition Teams systematisch und strukturiert vorarbeiten und man erreicht verhältnismäßig mühelos das ursprüngliche Ziel: Jene Leute ins Transition Team zu holen, die ins Transition Team gehören.

 

Meine Präsentation anlässlich der Agile Tour Vienna 2018 zu diesem Thema gibt es hier als Download

7 Erfolgsfaktoren der Digitalisierung – Gesamttransformation

Das Schwierigste an einer Digitalisierungsinitiative ist in vielen Fällen, die neue und die alte Welt zu vereinen. Zum Beispiel treffen die kurzen Releasezyklen agiler Teams auf die Begrenzungen der Infrastruktur, die sich noch nicht mitverändert hat. Auch Einheiten, die nicht direkt in die Produktentwicklung involviert sind, bleiben bei solchen Initiativen oft erst einmal außen vor. Um das agile Arbeiten langsam in die ganze Organisation zu tragen, arbeiten wir mit Transition Teams. In diesem Video erkläre ich, wie das funktioniert.

7 Erfolgsfaktoren der Digitalisierung – Zusammenarbeit mit Start-ups

Viele Start-ups werden “agil” geboren – das macht ihren Vorteil gegenüber klassisch strukturierten, alteingesessenen Unternehmen aus. Dass diese Unternehmen nicht über Nacht genauso agil werden können, ist klar. Aber sie können das neue Mindset und die neuen Arbeitsweisen auch allmählich wachsen lassen, indem sie mit Start-ups kooperieren. Über drei Möglichkeiten des Austauschs spreche ich in diesem Video.

Social Impact Lab 2.0 – Lean im Startup

Das Social Impact Lab in Stuttgart ermöglicht sozialen Startups im Gründungsprozess, über mehrere Monate hinweg aus ihren Ideen ein tragfähiges Geschäftsmodell zu entwickeln. Ganz unter dem Motto “have a social impact” konnten wir – Michael Friedmann und Marcel Rößner – den Gründerinnen und Gründern im Rahmen eines Workshops einen Einblick in agile Arbeitstechniken geben. Im Speziellen zum Thema “Lean Startup”. Die teilnehmenden Startups des Social Impact Labs durchlaufen das achtmonatige Stipendium #Wirkungsschaffer, das Workshops und Coachings in den verschiedensten Bereichen beinhaltet. Als Berater für agile Produktentwicklung hatten wir daher die Zielsetzung, den Teilnehmerinnen und Teilnehmern in einem eintägigen Workshop einen guten Überblick über agile Methoden zu geben und ihnen möglichst leicht anwendbare Konzepte mitzugeben, die sie einfach umsetzen können. Denn auch soziale Startups brauchen ein hieb- und stichfestes Geschäftsmodell, um langfristig nicht von Spenden und Fördergeldern abhängig zu sein. Da sich die Startups im Social Impact Lab teilweise in einer frühen Gründungsphase befinden, konnten wir ihnen vor allem mit dem Thema Lean Startup einen neuen Denkrahmen mit auf den Weg geben.

Was ist (ein) Lean Startup?

Lean Startup ist eine Methode, bei der schnell und mit möglichst wenig Aufwand geprüft wird, ob für eine Idee ein Markt existiert oder nicht. Um eine Idee testen zu können, muss erst ein Produkt gebaut werden, das diese Idee verkörpert. Mit herkömmlichen Methoden und Vorgehensweisen kann dieser Prozess auch ein paar Jahre dauern. Der Trick bei Lean Startup: Es kommt nicht darauf an, dass das Produkt in allen Einzelheiten funktionsfähig auf dem Markt erscheint. Wichtig ist zunächst die Funktionalität, von der vermutet wird, dass sie dem Kunden Nutzen bringen wird und damit sein Problem löst. Dabei sprechen wir vom Minimum Viable Product (MVP). Es ist das Mindeste, was benötigt wird, um prüfen zu können, ob das Produkt gekauft wird oder nicht. Welche verschiedenen Strategien und Typen eines MVPs existieren, könnt ihr in diesem Blogbeitrag nachlesen:

Am Anfang steht die Hypothese

Ein Startup beginnt immer mit einer Hypothese, die es zu überprüfen gilt. Der Zyklus, in dem eine solche Hypothese überprüft wird, nennt sich „Build-Measure-Learn-Zyklus“. Zunächst wird auf Basis der Hypothese ein MVP gebaut, mit dem die aufgestellte Hypothese überprüft und gemessen werden kann. Basierend auf diesem Feedback und den gemessenen Daten gilt es nun zu lernen: Das Produkt bzw. die Idee wird anhand der Ergebnisse gepasst und eine neue Iteration des Prozesses wird durchlaufen. Die reale Hypothese eines früheren Startups lautete beispielsweise:

Menschen kaufen Schuhe online = Profit

Mit dieser Hypothese ist der heutige Schuhgigant Zappos, damals noch als kleines Startup, 1999 in den Onlinehandel eingestiegen. Was Zappos anfangs benötigte, war keine ausgefeilte Online-Plattform, sondern eine rudimentäre Website mit Bildern von Schuhen und einer einfachen Kauffunktion. Über diese Website konnten Schuhe ausgewählt und schließlich gekauft werden. Die Fotos der Schuhe hatten die Gründer einfach in einem nahegelegenen Schuhladen aufgenommen. Wurde nun ein Schuh online von einem Kunden bestellt, mussten die Zappos-Gründer wieder in das Schuhgeschäft laufen, die Schuhe dort kaufen, anschließend händisch verpacken und an den Käufer versenden. Ziemlich umständlich, oder? Als langfristiges Geschäftsmodell wäre das sicher nicht tragbar. Aber was Zappos mit dem MVP bewiesen hatte, war, dass Menschen – genauer gesagt potentielle Schuhkäufer*innen – tatsächlich bereit waren, online Schuhe zu kaufen. 
Da die anfängliche Hypothese damit bestätigt worden war, war es erst jetzt sinnvoll, eine echte Onlinehandelsplattform mit einfacheren, digitalen Prozessen nach und nach zu entwickeln. Mit simplen Mitteln wie Google Adwords konnte zusätzlich gemessen werden, wer die wirkliche Käufergruppe war, um das Sortiment von Zappos stetig darauf auszurichten und das richtige Kundensegment anzusprechen. Wurde ein Schuh nie angeklickt, konnte er schnell wieder aus dem Sortiment genommen werden. Produkte, die bei den Kunden Anklang fanden, konnten identifiziert und das Sortiment in diesem Bereich ausgebaut werden.

Und wenn sich die Hypothese nicht bestätigt?

Doch was wäre gewesen, wenn sich die Hypothese nicht bestätigt hätte? Auch für diesen Fall liefert das Lean-Startup-Konzept eine Antwort: den sogenannten Pivot, zu deutsch Richtungswechsel. Wird eine fundamentale Hypothese der Idee oder des Geschäftsmodells widerlegt, so MUSS ein Richtungswechsel erfolgen, da das Startup sonst am Nutzer vorbeientwickelt und keinen Wert liefert. Das Startup ist somit nicht gescheitert, sondern führt rechtzeitig einen Richtungswechsel hin zu einer neuen Hypothese durch. Im Social Impact Lab konnten wir mit den Teilnehmern im Rahmen unseres Workshops einen fundamentalen ersten Schritt im Sinne des Lean Startups gehen. Nachdem wird das theoretische Konzept vorgestellt hatten, baten wir die Teilnehmer, die Hypothese ihrer Geschäftsidee zu formulieren, um sie im Nachhinein im Plenum zu diskutieren. Nach der Vorstellung konnten wir genauer auf die Besonderheiten der Hypothesen eingehen und prüfen, was getan werden könnte, um diese möglichst schnell auf dem Markt zu validieren. Das konstruktive Feedback und gemeinsame Hinterfragen unter den Teilnehmern brachte weitere Ideen hervor. Übrigens: Der Lean-Startup-Ansatz ist nicht nur für Startups geeignet, sondern grundsätzlich für jede Produktentwicklung. Auch in bereits etablierten Unternehmen sollten Ideen bzw. Hypothesen möglichst schnell geprüft werden, um radikal nutzerzentriert zu entwickeln und Wert zu generieren. Probieren wir es doch gemeinsam aus! Foto: Copyright Marcel Rößner

Forum Agile Verwaltung: Austausch und kollegiale Beratung

Agilität und öffentliche Verwaltung – das passt nicht zusammen. Oder doch? Es gibt eine ehrenamtlich getragene Initiative, die beweisen will, dass Agilität und öffentliche Verwaltung sehr gut zusammenpassen und dass diese Kombination sogar dazu beiträgt, die in der öffentlichen Verwaltung zunehmend spürbaren, wachsenden Herausforderungen und Probleme zu meistern: das Forum Agile Verwaltung. Eine – überwiegend ehrenamtlich getragene – Initiative, die wir bei borisgloger consulting für unterstützenswert halten.
Das Forum wurde am 11. Februar 2016 in Karlsruhe von sechs Praktikern aus der Verwaltung (kommunale, kantonale und Bundesverwaltung aus Deutschland und der Schweiz) sowie aus verwaltungsorientierten Dienstleistungsunternehmen aus der Taufe gehoben. Ihr gemeinsames Ziel: Die Kultur der Agilität in die Verwaltung zu tragen. Das Forum Agile Verwaltung soll ein Netzwerk von Praktikern zur gegenseitigen Unterstützung sein. Ein Forum für den offenen Austausch, die kollegiale Beratung und Vernetzung von Verwaltungsmitarbeitern, die für Agilität streiten und damit leider oft noch alleine sind. Aus dem lockeren Grüppchen ist kaum ein Jahr später ein Verein geworden, der interessierten Menschen, Verwaltungsmitarbeitern und Bürgern gleichermaßen offen steht und versucht, durch Vernetzung unterschiedlichster Akteure die agile Geisteshaltung in alle Ebenen und Bereiche der öffentlichen Verwaltung zu tragen.
Bereits kurz nach der Gründung des Forums entstand ein Blog, in dem Autoren des Forums und Gastautoren mindestens einmal wöchentlich mit Beispielen aus der Praxis Anregungen dazu liefern, wie die Ideen des agilen Manifests in den Arbeitsalltag der öffentlichen Verwaltung integriert werden können.
Forum Agile Verwaltung

Konferenz „Agile Verwaltung“

Neben der digitalen Vernetzung war es den Mitstreitern von Beginn an wichtig, die Vernetzung und den Austausch jenseits der Onlinewelt zu ermöglichen – das war die Geburtsstunde der Konferenz „Agile Verwaltung“. Bereits im Februar 2017 fand die Konferenz zum ersten Mal in Stuttgart an der Hochschule für Medien statt, die die Konferenz logistisch seit Beginn unterstützt. Die eintägige Konferenz ist eine Mischform aus klassischer Konferenz und Open Space. Die Organisation der Konferenz, wie auch die komplette Organisation des Forums, ist ehrenamtlich getragen.
Bereits zur ersten Konferenz 2017 waren über 60 Teilnehmerinnen und Teilnehmer aus dem ganzen Bundesgebiet und aus der öffentlichen Verwaltung im engeren und weiteren Sinne zusammengekommen. Damals konnten die Organisatoren den Geschäftsführer von buurtzorg, Art Levering, für die Keynote gewinnen. Im Februar 2018 fand die 2. Auflage mit bereits 110 Teilnehmern statt. Als Gastredner waren unter anderem Kollegen aus dem schwedischen Ängelholm (Europas erste agile Stadtverwaltung) angereist, aber auch Kollegen des Zukunftsbüros des Landes Vorarlberg hatten es sich nicht nehmen lassen, das Forum fachlich zu unterstützen. Der unerwartete Erfolg der beiden Konferenzen, aber auch die wachsende Zahl der Anfragen bei den Mitgliedern des Forums sind Belege dafür, dass der Bedarf an und der Wunsch nach mehr Agilität in der öffentlichen Verwaltung zunimmt.
Damit die Zeit zwischen den jährlichen Konferenzen nicht zu lange wird, gibt es zwischenzeitlich ein Meetup Agile Verwaltung in Berlin, eine Community of Practice für die Hochschulen und eine Untergruppe (Agiles Lernen und Lehren), die das Thema Agilität in der Bildung in Hochschulen und Schulen trägt. In Kürze wird auch ein Buch erscheinen, das in Kooperation zwischen dem Organisationsteam des Forums Agile Verwaltung mit verschiedenen Mitstreitern als Herausgeber entstanden ist.
Die Organisatoren des Forums Agile Verwaltung treffen sich jeden Freitag zu einer gemeinsamen virtuellen Besprechungsrunde, die interessierten Menschen offen steht. Wer einfach nur mal Mäuschen spielen möchte oder sogar aktiv mitwirken möchte, ist herzlich eingeladen. Eine Mail an kontakt@agile-verwaltung.org reicht aus.
Links:
Facebook
Twitter
Facebook-Gruppe

7 Erfolgsfaktoren der Digitalisierung – Governance

Governance braucht es mit Sicherheit auch für ein Digitalisierungsvorhaben. Aber kann man es vielleicht etwas beweglicher gestalten? Für risikobehaftete Vorhaben im Vorhinein ein fixes Bugdet errechnen zu wollen, ist aus meiner Sicht nicht der richtige Weg. Sehen wir uns ein Vorgehen an, das sich an den Prinzipien der Venture Capitalists orientiert.

borisgloger Meetup: Skalierung! Skalierung! Skalierung!

Mitte Juni hatte ich die tolle Gelegenheit, einen Abend unserer Meetup-Reihe in München zu gestalten. Mein Kollege Matthias Wolf-Dietrich hatte als Veranstalter die letzten Meetups bereits genutzt, um nicht nur nach Feedback, sondern auch nach Themenwünschen der Teilnehmer zu fragen. Platz 1 konnte dabei einem Thema niemand streitig machen: Skalierung! Diesen eindeutigen Wunsch konnten wir nicht ignorieren, daher habe ich mir die Zeit genommen, einen neuen Vortrag zu konzipieren, der auf unseren aktuellen Erfahrungen, der Arbeit in der Community mit anderen Agile Coaches und natürlich den Ideen von Boris aufbaut. Herausgekommen sind ein 50-minütiger Lightning Talk und eine spannende Diskussion mit reger Beteiligung des Publikums. Den Vortrag und das entsprechende Slide-Deck wollen wir euch natürlich nicht vorenthalten!
Wenn ihr auch zu einem der nächsten Meetups kommen wollt, meldet euch gerne über die borisgloger Agile Experience Camp Seite auf Meetup.com an. Dort seht ihr auch eine Übersicht aller Standorte und Termine.

7 Erfolgsfaktoren der Digitalisierung – Customer Centricity

Dieses Mal will ich euch ein paar Instrumente zeigen, mit denen ihr eure Produkte und Services spezifischer auf eure Kunden ausrichten könnt. Was diese Instrumente verbindet: der ständige Abgleich zwischen Hypothesen und der Sicht des Users. Mehr dazu in diesem Video.

7 Erfolgsfaktoren der Digitalisierung – Know-How

Welche Kompetenzen sollten sich in crossfunktionalen Teams widerspiegeln, die in Digitalisierungsinitiativen eingebunden sind? Aus meiner Sicht sollten folgende Kompetenzbereiche abgedeckt sein: Wirtschaftlichkeit, Qualität und Realisierbarkeit, User Experience und Produktivität. Was ich darunter verstehe, erfahrt ihr in diesem Video.

7 Erfolgsfaktoren der Digitalisierung – Leadership

Etwas Neues und Zukunftsweisendes zu entwickeln und voranzutreiben, ist keine Aufgabe für Verwalter. Innovation braucht Führungspersönlichkeiten auf mehreren Ebenen, die mit Visionen emotionalisieren können, die Selbstorganisation fördern und den Mut zur Freiwilligkeit haben. Mehr dazu in diesem Video.

7 Erfolgsfaktoren der Digitalisierung- Rahmenbedingungen

Ob eine Digitalisierungsinitiative erfolgreich verläuft oder nicht, hängt zunächst von den Rahmenbedingungen ab: von den organisatorischen und und von jenen der Infrastruktur. Dabei geht es gar nicht darum, am Arbeitsplatz eine Fun-Park-Atmosphäre zu schaffen. In erster Linie ist es wichtig, dass sich Mitarbeiter auf ihre Arbeit fokussieren können und alle Mittel zur für die Zusammenarbeit zur Verfügung haben. Mehr dazu in diesem Video.

7 Erfolgsfaktoren der Digitalisierung – Herausforderungen

Was sind eigentlich die typischen Herausforderungen, wenn Digitalisierungsinitiativen gestartet werden? Uns begegnen im Wesentlichen vier Problemfelder: fehlender Fokus, mangelnde Kundenorientierung, eine verloren gegangene Leidenschaft für das Produkt und eine zu strikte Governance. Mehr darüber in diesem Video.

Interview mit Boris Gloger: „Die großen agilen Transitionen haben immer nur dann funktioniert, wenn das Management verzweifelt war.“

Vor Kurzem hat mich die Wirtschaftspsychologiestudentin Laura Hitti zum Thema Change-Prozesse in klassischen Organisationen interviewt. Das Gespräch möchte ich euch nicht vorenthalten. Hier die gekürzte Fassung.
Laura Hitti: Herr Gloger, welche Aspekte aus Ihrer Praxis erachten Sie als besonders wichtig für Skalierungsvorhaben?
Boris Gloger: Das läuft immer auf dasselbe hinaus. Die Grundaussage ist: Man muss anfangen, Agilität einzuführen und dafür sorgen, dass der Change auch erfolgreich ist. Dadurch entsteht oft ein großer Druck bei uns – im Unternehmen entsteht dieser aber schon früher. Eigentlich ist dieser Druck fundamental. Es ist Fakt: Die großen agilen Transitionen haben nur dann funktioniert, wenn das Management verzweifelt war und gesagt hat: „Wir machen alles, was notwendig ist, damit es irgendwie funktioniert!“ Im Sinne von Kotter: Es gab einen „Sense of Urgency“.
Laura Hitti: Agilität soll also einerseits als Methode eingeführt werden und sich andererseits sofort als erfolgreich und richtig beweisen. Dabei muss das Management vorher den Druck erkennen, der aus der Umwelt resultiert. Richtig?
Boris Gloger: Genau! Das ist das Problem bei großen agilen Projekten in nicht-agilen Organisationen. Wenn Sie heute mit 300 Leuten etwas machen, ist das überhaupt kein Problem. Da ist das schon Standard! Die haben diesen Need häufig nicht. In einer klassischen Organisation gibt es verschiedenste Baustellen. Und die heftigste Baustelle ist, dass Sie genau jene Manager brauchen, die sich erst absichern müssen, damit sie etwas ändern dürfen.
Laura Hitti: Stichwort „Empowerment“?
Boris Gloger: Nein, Empowerment ist etwas anderes. Hier geht es darum, dass die Organisation zulässt, dass Sie Prozesse einreißen, die es schon immer gab. Dass Sie die klassischen Prozesse nicht einhalten müssen. Dass Sie die Erlaubnis bekommen, zum Einkauf zu gehen und zu sagen: „Ich brauch das Zeug jetzt trotzdem! Und nicht erst in sechs Wochen!“
Laura Hitti: Gibt es konkrete Indikatoren, die zeigen, dass das Management verstanden hat und das nötige Rückgrat besitzt, um den Change durchzusetzen?
Boris Gloger: Indikatoren im Vorfeld gibt es meiner Meinung nach nicht. Es gibt nur Manager, die im Laufe der Transition erkennen, worauf es ankommt. Nämlich dass sie aus ihrer Linienfunktion heraus die Probleme wegarbeiten müssen. In jeder agilen Transition – oder in jedem großen agilen Projekt – stoßen Sie immer auf Schwierigkeiten in der Organisation. Das ist normal. Wenn das nicht so wäre, würde die Organisation ja tadellos funktionieren. Sie brauchen deshalb Menschen in der Organisation, die entscheiden können und sagen: „Okay, dann tun wir jetzt etwas!“
Laura Hitti: Hat das aus Ihrer Sicht auch mit einer Veränderung der Managementrolle zu tun?
Boris Gloger: Ja und nein. Theoretisch könnten die Manager in ihrer klassischen Linienfunktion den Change einleiten. Sie haben die Rechte! Jetzt ist es aber in der Regel so, dass das Management die Entscheidung nach oben abgibt. Also der Teamleiter gibt an den Gruppenleiter ab, der Gruppenleiter wiederum gibt an den Abteilungsleiter ab, und dieser gibt an ein Steering-Committee oder Gremium ab. Weil der Manager – also derjenige auf dem Level, der entscheiden müsste – denkt, nicht entscheiden zu können, oder er darf es tatsächlich nicht. Eventuell hat er nicht die Budgetkompetenz oder muss nochmal jemanden fragen. So oder so: Verantwortung wird in klassisch geführten Unternehmen häufig nach oben delegiert – vor allem wenn es um Anforderungen geht, die sich so noch nie gestellt haben. Die letztendliche Konsequenz hat Laloux in „Reinventing Organizations“ beschrieben. Er schreibt, dass die ganze Agilität immer dann zusammenbrechen wird, wenn es der CEO nicht will. Und wenn es der CEO will, aber das Board nicht, dann wird es auch zusammenbrechen. Bei großen Geschichten brauchen Sie ein Management, das ein Backup gibt und die Probleme wirklich aus dem Weg schafft.
Und der zweite Faktor ist: Erfahrung erzeugen. Was meine ich damit? Sie führen irgendein Framework ein, zum Beispiel Scrum, und dann sagt das Management in der Regel: „Ja, macht halt Scrum!“ So, na gut! Aber die Manager selbst arbeiten nicht mit Scrum und sind viel zu weit weg vom Geschehen.
Laura Hitti: Das gemeinsame Sitzen an einem Ort, auf einem Stockwerk. Ist das also ein weiterer Erfolgsfaktor?
Boris Gloger: Das ist einer der Beschleuniger, ja. Der wirkliche Erfolgsfaktor ist, dass sich die Manager tatsächlich selbst der Agilität aussetzen. Am besten machen sie es selbst. Das Zweitbeste ist, dass sie mitkriegen, wie die anderen arbeiten – also wirklich mitkriegen. Das heißt hinfahren, sich die Meetings anschauen – einfach dabei sein. Sie müssen dann zulassen, dass die Menschen es anders machen.
Der dritte Erfolgsfaktor, und das ist meiner Meinung nach der wichtigste: Sie brauchen ScrumMaster, die das durchsetzen. Ohne Führung funktioniert es nicht! Wenn der ScrumMaster oder der Agile Coach nicht als Führungskraft gesehen wird, wenn er sich nicht als Change Agent etablieren kann oder nicht den Mut hat, Dinge zu verändern, dann funktioniert es gar nicht. Dann haben Sie zwar wunderschöne, herrlich gemachte Task Boards und Scrum Boards und Meetings, aber das Team liefert trotzdem nicht.
Der vierte Erfolgsfaktor heißt aus meiner Sicht: tatsächlich liefern! Sie können LeSS oder auch SAFe benutzen und das Framework da reinschrauben. Wenn Sie nicht alle zwei Wochen oder alle vier Wochen fix und fertiges Zeug liefern, dann haben Sie die schönsten Frameworks der Welt benutzt und es funktioniert trotzdem nicht.
Laura Hitti: Das heißt: So weit liefern, dass der Kunde sich hinsetzen kann und seine Begeisterung ihm aus allen Poren strahlt?
Boris Gloger: Das ist zwar nett, aber das braucht es gar nicht. Am Anfang würde es reichen, dass die Manager, also die, die es letztendlich ja bezahlen, sehen: Die Teams kommen voran. Das erzeugt einen positiven Schneeballeffekt: Sie sehen, dass etwas vorangeht, durch das Vorankommen entsteht Vertrauen – die Teams dürfen mehr! Dadurch, dass die Manager es schaffen, den Teams die Probleme aus dem Weg zu räumen, bekommen die Teams und die Mitarbeiter wiederum Vertrauen in das Management. Und das ist ein positiver, sich selbst verstärkender Prozess, bis die gesamte Organisation merkt: Es funktioniert! Umgekehrt kann es genauso negativ verstärkt werden: Wenn die Teams merken, dass das Management sie nicht ernst nimmt.

Holacracy bei borisgloger consulting: Wie wir die Gehälter für Executives bestimmen

Erst vor Kurzem hat unsere interne Gehaltsgilde ein Modell auf den Weg gebracht, wie Gehälter bei uns festgelegt und erhöht werden. Die Prämissen der Aufgabe: Nicht mehr der Geschäftsführer oder HR sollen die Gehälter und Erhöhungen festlegen, sondern ab jetzt soll das im Team erfolgen. Wichtig war auch, die Gehaltsbänder zu harmonisieren sowie Fairness und Ausgeglichenheit sicherzustellen. Für den Prozess haben wir als Unterstützung eine externe Beratung engagiert.
Das Fazit vorab:

Wenn ich „wir“ sage, muss ich etwas einschränken. Bislang hatten wir Executives sowie die Kolleginnen aus der Zentrale (Operations, Marketing, Sales, HR, Finance) in Sachen Gehaltserhöhung weiterhin Einzelvereinbarungen mit dem Geschäftsführer. Damit waren wir wunderbar außen vor, doch das ändert sich nun. Am kommenden Executive Day (unser Leadership Meeting alle zwei Monate, bei dem wir uns mit uns selbst als Team sowie mit strategischen Fragestellungen beschäftigen) werden wir dieses Mal ein Modell entlang von Holacracy entwickeln, in dem wir als Team miteinander die Gehaltsfrage laufend bearbeiten. Für uns selbst.

Transparenz ist zunächst ein zwiespältiges Gefühl

Und jetzt wird es spannend. Bislang gab es nur eingeschränkte Transparenz zwischen den Executives. Wir hatten es vermieden oder einfach auch nicht für relevant gehalten, unsere Gehälter vor (allen) anderen offen zu legen. Und doch ist genau das, was wir unseren Kunden als Vision mit auf den Weg geben. Jetzt ist es unsere eigene Aufgabe geworden, diese Transparenz gemeinsam herzustellen. Das fühlt sich zuerst mal sehr heikel und sensibel an. Wie wird es den KollegInnen gehen? Wie geht es mir selbst damit? Nicht alles von dieser möglichen Zukunft fühlt sich sofort auch „gut“ an. Bei manchem scheint mein Bauch zumindest noch unschlüssig.
Wir werden uns mit uns selbst auseinandersetzen. Wir werden unsere Werte anschauen, unser Verständnis vom Zusammenwirken als Team und unsere Sicht auf Gehalt, Leistung, Vergütung. Mehr noch: Wir werden auf die innere Zufriedenheit jeder/s Einzelnen/r schauen. Woraus speist sich diese? Welchen Anteil hat das Gehalt und welchen Anteil haben andere Komponenten? Dieser Spiegel, der so klar und deutlich wiedergibt, wer wir sind und was uns ausmacht, wird offenbaren, was bis dato vielleicht verborgen geblieben ist. Also geht es nicht um Zahlen, vielmehr geht es um Kontext und Hintergründe. Hintergründe, die verständlich machen, warum wir welche Bedürfnisse verspüren bzw. bestimmte Ziele verfolgen. Und vielleicht liegt in diesem Offenbaren der eigentliche Schmerzpunkt der Transparenz: Zahlen sind nur Zahlen. Aber Hintergründe zu Zahlen sind – wenn es ums Gehalt geht – ein Fenster in unser Privates. Transparenzfähigkeit ist somit eine Teamangelegenheit. Es gilt, einen sicheren Raum zu gestalten, in dem wir uns füreinander öffnen können. (Vgl. Simon Sinek – “Leaders eat last”)
Die Lösung auf der Sachebene ist dann vermutlich einfacher oder zumindest nachvollziehbar.
Jetzt aber mache ich mich auf den Weg zu unserem internen Executive Day, auf den ich mich schon sehr freue. Am Weg dorthin gibt es noch drei Kundentermine. Nächste Woche werde ich mit einem Stück vertieftem Erfahrungswissen in die Beratung zurückkehren.

Das Vieraugengespräch ist der Feind des agilen Arbeitens

Tagein tagaus werden wir Führungskräfte in Vieraugengespräche verwickelt. Wir bekommen E-Mails, werden am Gang angesprochen, haben Meetings und Telefonate – jeweils mit Einzelpersonen. Das ist anstrengend, kostet Zeit und eure Teams und Abteilungen, die ihr führt, haben etwas Besseres verdient als eine Führungskraft, die sich darin aufreibt, das Bottleneck der Kommunikation und damit der Entscheidungen zu sein.

Von der Schattenorganisation zu transparenten Organisation

Agile Organisationen, ob Teams oder ganze Firmen, schreiben sich “radikale Transparenz” auf die Fahnen. Das betrifft alle Informationen eines Unternehmens. Und was ist an dem Austausch unter vier Augen transparent? Richtig, nichts. Da Organisationen nichts anderes sind als Systeme aus Kommunikationen, ist also das Vieraugengespräch im Grunde der Aufbau einer Schattenorganisation. Eigentlich müsste man jedes dieser Gespräche sofort notieren und an das gesamte Team, die gesamte Abteilung zur Kenntnisnahme schicken. (Achtung: Es geht nicht um Infos wie „da hat jemand angerufen, ruf bitte zurück“ oder „wie war das Wochenende?”) Nicht nur auf den ersten Blick sehr unpraktisch. Schlicht undurchführbar.
Doch es gibt eine Lösung: Wieder haben uns Software-Entwickler gezeigt, wie man die Kommunikation im Team radikal transparent hält. Sie haben einen Weg gefunden, der Organisation und damit der Kommunikation – denn eine Organisation ist ein System aus Kommunikationen – eine Gestalt zu geben. Man setzt öffentliche Chatrooms (oder Channels) ein und kommuniziert so gut wie alles über dieses Medium. Jeder kann ständig mitlesen, ist auf diese Weise immer informiert — und die Organisation wird sichtbar. Applikationen wie Slack, MS Teams und andere folgen diesem Prinzip.
Doch ich erlebe viele Führungskräfte, die noch immer fleißig Vieraugengespräche suchen oder E-Mails und Direct Chat Messages verschicken, obwohl ihre Teams die öffentliche Variante nutzen. Das ist kontraproduktiv. Diese exklusive Kommunikation erzeugt Misstrauen, weil exklusive Informationsbeziehungen entstehen. Das verlangsamt den Kommunikationsprozess und damit die Wertschöpfung.

“No One2Ones” bei borisgloger consulting

In meinem eigenen Unternehmen und in unserer Beratungspraxis versuchen wir dem mit dem Merksatz „No One2Ones!“ entgegenzuwirken. Ich achte darauf, dass ich so gut wie keine One2Ones mit meinen Kollegen habe. Es gibt natürlich, wie immer, Ausnahmen. Darunter fällt zum Beispiel das Coaching-Gespräch, also wenn ein Kollege eine tiefe Reflexion über einen Sachverhalt benötigt, oder auch mal ein kurzes Brainstorming dazu, wie es weitergehen könnte. (Das ist allerdings schon grenzwertig, denn die Ergebnisse müssen ja wieder mitgeteilt werden, und hätten alle mitgedacht, oder die, die es interessiert …). Natürlich gibt es die One2One-Abstimmung, ob wir gemeinsam diesen Flieger nehmen oder einen anderen. Doch ansonsten achte ich darauf, dass ich immer mindestens zwei Personen bei einem Gespräch oder bei einer E-Mail anspreche. Diese Kommunikationspraxis wird bei uns noch lange nicht durchgängig gelebt und das muss auch gar nicht sein. Der Anspruch ist nicht, dass es gar keine One2Ones mehr geben soll, sondern nur, dass es in diese Richtung geht. Wir wollen die Kommunikation so transparent wie möglich halten.
Unternehmen, die sich in diese Richtung bewegen, werden mit der Entwicklung einer offenen Kultur belohnt. Wie geht das mit 50 Menschen? Genau so: Es gibt Channels, die alle lesen, es gibt Channels, die nur wenige lesen, diese sind dennoch öffentlich, und es gibt immer weniger One2Ones.
Was habe ich als Führungskraft davon? Es entsteht eine offene Kommunikationskultur und viel weniger Arbeit. Dinge müssen nur einmal geschrieben oder in einem Online Call gesagt werden.
Was braucht es dazu? Ein modernes Chatsystem, wenn das Team verteilt arbeitet. Das Vermeiden direkter Nachrichten, wenn man gemeinsam in einem Raum sitzt, und im persönlichen Kontakt so wenige Vieraugengespräche wie möglich.