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

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.

Die Rolle des ScrumMasters und seine Fähigkeiten – ein Eisbergmodell

Erst kürzlich hatte ich eine Unterhaltung, in der mir mein Gesprächspartner stolz erzählte: „Ich habe jetzt auch endlich eine Ausbildung als ScrumMaster absolviert. Probleme in Teams zu beheben, machte mir schließlich schon immer Spaß. Und für die Moderation von Meetings habe ich eine Weiterbildung gemacht. Das kann ich auch neben meinen eigentlichen Aufgaben erledigen.“

Und so werden Heerscharen von ScrumMaster ausgebildet, die in ihre Teams gehen, um Meetings zu moderieren und Impediments zu lösen. Denn das ist schließlich unsere Aufgabe, oder nicht?

Die Spitze des Eisbergs

Ja, natürlich fallen diese Aufgaben in den Verantwortungsbereich eines ScrumMasters. Aber für mich als passionierte ScrumMasterin ist das nur die Spitze des Eisbergs. Der eigentliche Sinn dieser Rolle geht viel tiefer.

Was tut also ein guter ScrumMaster? Er führt eine Methode ein und stellt die Produktivität des Teams sicher, doch auch das greift meiner Meinung nach noch zu kurz. Denn die Methode Scrum ist ein Impuls für etwas Größeres, für den Kulturwandel im gesamten Unternehmen. Aus der Methode heraus ergeben sich neue Werte und Prinzipien, eine neue Einstellung der MitarbeiterInnen und dadurch das Potential, die Unternehmenskultur nachhaltig zu verändern.

Der ScrumMaster ist also auch ein Change Agent. Er muss sein Team und die Organisation durch den Wandel führen. Diese Führungsrolle lebt er aber nicht als disziplinarischer Vorgesetzter mit entsprechender Weisungsbefugnis aus, sondern bewegt die Teams und das Management durch seine laterale Führung. Er verkörpert eine neue Kultur und das für viele Kollegen und Kolleginnen ganz neue, agile Mindset. Er geht mit gutem Vorbild voran, lebt die Scrum-Werte und -Prinzipien jeden Tag, sodass die Teammitglieder diese nach und nach verinnerlichen.

Der ScrumMaster muss ins kalte Wasser tauchen

Viele Menschen entscheiden sich für eine Ausbildung als ScrumMaster, weil sie mit einzelnen Teilaufgaben dieser Rolle liebäugeln. Sie stürzen sich voller Motivation auf ausgewählte Aspekte und vergessen dabei, dass 85 % der eigentlichen Themenfelder gut verborgen unter der Oberfläche zu suchen sind. Vielleicht ist manchen bewusst, dass sie auf ihrem Weg als ScrumMaster noch weitaus anspruchsvollere Aufgaben vor sich haben, als den zeitlichen Rahmen in Meetings einzuhalten. Meiner Erfahrung nach rechnen sie jedoch oft nicht damit, dass sie ins eiskalte Wasser eintauchen müssen, sobald sie auf eines der etwas tiefer gehenden Themen treffen. ScrumMaster brauchen also die Bereitschaft, immer und immer wieder unbekannte Dinge auszuprobieren, Fehler zu machen, Neues dazuzulernen und an sich selbst zu wachsen.

Betrachtet man insbesondere die Aufgaben als Change Agent, der den Wandel vorantreibt, dann sind Ausdauer und Durchhaltevermögen ebenso wie der Mut gefragt, den Status quo in den Teams immer und immer wieder herauszufordern. Darüber hinaus braucht es Offenheit, um die agilen Werte und Prinzipien in der Organisation und den Teams zu verankern und dadurch den Kulturwandel zu forcieren – ebenso wie Offenheit gegenüber der Geschwindigkeit der Teams. Deshalb ist ein hohes Maß an Anpassungsfähigkeit und Selbstreflexion notwendig. Denn man muss immer wieder hinterfragen, ob man die vorgesehenen Veränderungen einleiten konnte und – falls nicht – was man in der Umsetzung anpassen kann, um den Change anzustoßen.

Welche Eigenschaften solltest du als ScrumMaster mitbringen?

Ein guter ScrumMaster ist jederzeit bereit, über sich selbst hinauszuwachsen. Ich habe im Folgenden ein paar Fähigkeiten gesammelt, auf die es meiner Erfahrung nach im agilen Arbeitsalltag ankommt:

Es ist natürlich noch kein Meister vom Himmel gefallen und ich weiß, dass es viele wirklich begnadete Eis-Schwimmer gibt. Meine Anregung ist jedoch: Bitte seid ehrlich mit euch selbst und hinterfragt kritisch, ob ihr die richtigen Fähigkeiten für die Rolle des ScrumMasters habt und die Offenheit mitbringt, Neues zu lernen und auch in Aufgaben einzutauchen, die euch vielleicht nicht so sehr liegen. Denn ihr werdet den Wandel im Unternehmen kontinuierlich vorantreiben und habt damit eine zentrale Rolle, zu der ihr euch bewusst committen solltet.

“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.

Ü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.

Agilität im Unternehmen: Die Veränderung planen mit Objectives and Key Results (OKR)

Um agil arbeitende Teams auf die langfristigen Unternehmensziele auszurichten, empfiehlt sich ein Planungshorizont von idealerweise drei Monaten. Durch diesen definierten Rahmen entsteht zum einen Handlungssicherheit, zum anderen macht dieser Zeitraum beweglich genug, um auf Veränderungen reagieren zu können. Darum geht es beim Corporate Alignment mittels OKR (Objectives and Key Results).

Wenn sich ein Unternehmen zu einer agilen Organisation entwickelt und teambasiert mit Scrum & Co. arbeitet, stellen sich irgendwann Fragen wie zum Beispiel: Wie planen wir das nächste Jahr? Welche Gelder stehen wofür bereit? Welche mittel- und kurzfristigen Ziele sind wichtig, um die langfristige Vision zu realisieren? Worauf soll der Fokus liegen?

Das Management will für das nächste Jahr klar sehen, wie die Reise zur Erreichung der langfristigen Unternehmensvision gestaltet wird. Wie macht man das, ohne gleich wieder in altes Wasserfalldenken zu verfallen? Denn ist das nicht klassisches Planen: sich zu überlegen, was im nächsten Jahr kommt? Die Antwort ist: Kommt darauf an, wie und wie umfänglich es gemacht wird. Zumindest muss festgelegt werden, auf welchen Routen sich die Flotte in Richtung Vision bewegen soll.

Planen und zugleich offen für Veränderungen sein – wie kann das umgesetzt werden?

Das fängt beim Planungshorizont für Team- und Projektziele an. Während in vielen klassischen Unternehmen immer für ein ganzes Jahr geplant wird, hat sich in der agilen Welt eine quartalsweise Planung bewährt. Was ist der Vorteil? Diese Form der Planung reduziert das Risiko, denn was immer geplant wird, wird zunächst für einen Zeitraum von drei Monaten gemacht. Stellt sich nach diesem Zeitraum heraus, dass falsche Akzente gesetzt wurden, wird der Plan nach drei Monaten geändert. Diese quartalsweise Zielplanung auf Basis eines langfristig konstanten Leitbildes nennt sich Objectives and Key Results (OKR). Das Konzept wurde schon in den 1970ern von Intel-Mitgründer Andy Grove entwickelt, aber erst durch die Anwendung bei Google in der breiten Öffentlichkeit bekannt.

Kern der OKRs ist, den Fokus zu halten. Deshalb sollte sich ein Team – egal, ob Projektteam oder das Team der Geschäftsleitung – nicht mehr als fünf herausfordernde, aber erreichbare Ziele (Objectives) pro Quartal setzen. In welchem Umfang ein Objective erreicht wurde, sollte durch maximal drei bis vier Kenngrößen (Key Results) mess- und verifizierbar sein, die eine gewisse Herausforderung darstellen, aber nicht unerreichbar sind. Jedes Teammitglied sollte wissen, wie er oder sie zum Erreichen der Ziele beitragen kann und im Sinne der Transparenz werden alle OKRs eines Unternehmens auch öffentlich gemacht – sie können jederzeit von den Mitarbeiterinnen und Mitarbeitern eingesehen werden.

Übrigens spielt der Prozess, in dem die Ziele und die Planung für die nächsten drei Monate entstehen, eine entscheidende Rolle. Es ist noch nichts gewonnen, wenn die Unternehmensleitung zwar Quartalsziele ausruft, diese aber nicht in den Teams ankommen. In diesem Fall ist es kaum verwunderlich, wenn die Mitarbeiter den Bezug zwischen Vision, Quartalszielen und ihrem eigenen Handeln nicht herstellen können. Daher brauchen wir in der agilen Welt ein anderes Vorgehen.

Kollaborative Prozesse statt Vorgaben

Also heißt es Abschied nehmen von den fein säuberlich in PowerPoint-Präsentationen abgelegten und nie mehr angeschauten Zielen. Eine Verbindung entsteht dort, wo etwas gemeinschaftlich erarbeitet wird – zum Beispiel so: Das Team steht vor einem Flip-Chart und platziert darauf Überschriften zu den Themen, die im nächsten Quartal im Fokus stehen sollen. Anschließend werden die Objectives (quartalsweise Ziele) und Key Results (Metriken, die den Fortschritt messen) gemeinsam erarbeitet.

Strategie OKR

Wie kann der Prozess des Zielabgleichs ablaufen?

Zunächst erfolgt der Zielabgleich im Team. Damit kann ein Projektteam oder auch das Team der Geschäftsleitung gemeint sein.

Anschließend beginnt ein Abstimmungsprozess, um sicherzustellen, dass das, was erarbeitet wurde, im Einklang mit der langfristigen Unternehmensvision steht. Dementsprechend wandert das Flip-Chart zur Unternehmensleitung, bis die Ziele aufeinander ausgerichtet sind.

Damit auch wirklich an alles gedacht wurde, bevor es an die Umsetzung geht, fehlt ein letzter Schritt: Es wird geklärt, ob es Überschneidungen zu benachbarten Projekten oder Teams gibt. Wieder startet der kollaborative Prozess: Wir holen uns die Nachbarprojekte bzw. -Teams vor das Flip-Chart, gleichen ab und richten aus.

Zustimmung OKR

Am Ende erhalten wir eine in alle Richtungen kollaborativ erarbeitete Zielsetzung für unser Team bzw. Projekt.

Jetzt sind die Unternehmenseinheiten und Projekte aufeinander ausgerichtet, die Umsetzung kann beginnen.

Kommen wir zurück zur quartalsweisen Planung auf Unternehmensebene. In Teams und Projekten passiert beim agilen Vorgehen eine Menge: Durch das Feedback zu Produktinkrementen kann eine neue Ausrichtung für ein Projekt entstehen und das kann wiederum Auswirkungen auf das Projektportfolio oder die Teamstrategie haben. Das kann bedeuten, dass nach drei Monaten nachjustiert werden muss. Dabei wird wieder der oben beschriebene Prozess durchlaufen.

Entscheidend ist, dass ein kollaborativer Abgleich über alle Ebenen erreicht wird und dieser Abgleich regelmäßig wiederholt wird. So erhält man eine solide Grundlage, um in gemeinsamer Ausrichtung die langfristigen Ziele des Unternehmens zu erreichen.

Wie dieser Abgleich für Projektorganisationen genau funktionieren kann, zeige ich in meinem nächsten Blogbeitrag über das Verhältnis von Projektportfoliomanagement zu OKR auf.

 

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 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

Agilität muss man aushalten können – Szenen aus der Praxis

1. Sackgasse Selbstorganisation – wenn keiner pullt

Auch bei borisgloger consulting richten wir den Blick regelmäßig nach innen. Retrospektiven sind für uns ein fester Bestandteil, um gemeinsam herauszufinden, mit welchen konkreten Maßnahmen wir Verbesserungen herbeiführen können. Mit zwei weiteren Kollegen übernahm ich die Planung einer dieser Retrospektiven. Die Wahl fiel auf ein Format, bei dem das Team in zwei Gruppen aufgeteilt wird, die sich am Ende die erarbeiteten Ergebnisse gegenseitig vorstellen. Warum? Weil man bei diesem Format gleich zweimal Feedback bekommt: einmal in der Teilgruppe und danach beim Vorstellen und Challengen der Ergebnisse am Ende.

Alle waren mit dem Ergebnis zufrieden. Zuletzt sollten noch die zuständigen Kollegen gefunden werden, die die erarbeiteten Maßnahmen dann angehen und umsetzen würden. Die Frage „Wer kümmert sich drum?“ stand im Raum. Schweigen. Auch nach einer Weile gab es kein „hier“ zu hören. Selbst in selbstorganisierten Unternehmen ist das nicht unbedingt überraschend. Dennoch, für einige im Team war das höchst unbefriedigend. Die Gründe für die Zurückhaltung sind vielseitig: Die eigene Priorisierung der Aufgaben, wichtige andere Commitments am gleichen Tag etc. Wie schafft man es trotzdem, die Verantwortung zu verteilen? Das Pull-Prinzip, nach dem wir arbeiten, fordert, dass die Arbeit im agilen Kontext freiwillig gezogen und eben nicht angeordnet wird.

Option A: Vielleicht werden die definierten Maßnahmen später gezogen oder auch gar nicht, wenn anderes einfach höher priorisiert ist.
Option B: Der ScrumMaster weist daraufhin, dass die Aufgabe auch gemeinsam übernommen werden kann und motiviert dadurch neuere Teammitglieder, den Sprung ins kalte Wasser zu wagen.
Option C: Der Product Owner priorisiert diese Aufgabe höher und vermittelt damit, dass die Aufgabe wichtig ist und gezogen werden sollte.

Wenn Teams mit Scrum zu arbeiten beginnen, ist das freiwillige Pull-Prinzip oft schwierig zu akzeptieren oder schwer nachvollziehbar. Ist es nicht viel einfacher, Aufgaben direkt zu verteilen anstatt zu warten? Das wäre am Anfang tatsächlich einfacher. Nur, ist es eine nachhaltige Alternative, die Aktivitäten per Ansage zu verteilen? Wie groß ist dann die Wahrscheinlichkeit, dass sie mit der notwendigen Motivation und Konsequenz umgesetzt werden? Was bleibt dafür im Gegenzug liegen? Hier braucht es Mut, unterschiedliche Optionen auszuprobieren und darauf zu vertrauen, dass die Teammitglieder eine Lösung finden werden.

2. Commitment muss gelernt werden

Gleiches Thema, anderes Setting. Ich hatte zu einer teamübergreifenden Retrospektive eingeladen. Es sollten Vertreter von zwei Teams geschickt werden. Ich erhielt die Zusage aller Kollegen und bereitete die Retro vor.

13:59 Uhr am Tag der Retro – Wir warteten auf vier Teilnehmer. Dafür hatte ein Team noch weitere Kollegen mitgebracht. Enttäuscht über das Nichterscheinen der Kollegen schlug jemand vor, die Retro abzusagen oder zumindest dafür zu sorgen, dass aus jedem Team gleich viele Personen am Meeting teilnehmen würden, damit es gerecht blieb. Das kam für mich nicht in Frage.

Ich konnte die anderen überzeugen, die Retro genau mit jenen Personen durchzuführen, die gekommen waren – ein Grundsatz, der auch im Open Space Format Anwendung findet. Mit der Aussage „Diejenigen, die kommen, sind die richtigen“ haben wir unsere Retrospektive durchgeführt und sogar die Timebox eingehalten. Es kamen tolle Ergebnisse dabei heraus und das Meeting war ein voller Erfolg!

Auch hier waren die Beteiligten erst unzufrieden mit der Situation. Und auch in diesem Fall spielt das Prinzip der Freiwilligkeit eine Rolle. Im „Open Space“ kennt man zudem das Gesetz der zwei Füße, das besagt, dass jeder nur dann erscheint, wenn er oder sie etwas lernen oder einen Beitrag leisten kann. Das war in diesem Meeting der Fall.

Agilität braucht viel Geduld und Durchhaltevermögen. Die Beteiligten dürfen die Prinzipien selbst in schwierigen Situationen nicht fallen lassen, auch wenn es Zeit braucht, bis alle an Bord sind und die agilen Werte und Prinzipien leben können.

Bis dahin gilt: In solchen Situationen muss man Agilität einfach mal aushalten können.

Foto: CC0 Creative Commons – pixabay, Pexels

Fostering cultural change by failing to deliver

What do cultural change and improving delivery results have to do with one another? This could very well be a question posed in any business environment that is facing calls for change and embracing new ways of thinking. Often by inertia, many companies, especially if they are doing well, will be quite resistant to change because they are doing well enough.

The fundamental assumption is that cultural change is about improving performance and therefore improving delivery. In that respect cultural change means living values such as openness, commitment, respect and courage. It also means building accountability where people in the company do things not because they have to do them, but because they want to do them. In essence, it is about developing and continuously refining an environment that enables seeing everyone’s role in an organisation not as a passive component, but an active contributor.

But, how is it connected to delivery? That is both simple and very difficult. The simple part is that by living the above-mentioned values individuals at all levels of an organisation are able to play accountable, self-reflecting roles who share a common vision and goal, therefore putting their efforts towards achieving it as a collective and improving performance. The difficult part is convincing people that this is worthwhile, and facilitating a process that will help them share the same vision and the same goal.

Change – everyone’s responsibility

So, who is responsible for bringing about cultural change? The simple answer is, everyone. It is a matter of having the management level committing and living the values and then unequivocally communicate them through the organisation. The more people in the organisation become acquainted with the values, the easier it will be to create a spontaneous communication matrix where the vision and values related to it are communicated and lived by, from meetings to lunch breaks. Clearly and consistently communicating values and visions and living those values will be the best form of feedback to everyone, that this is the way to go. This is what makes a team that does work, into a team that wants to do work and enjoys being a part of what it is doing.

The challenge, however, is that change, all other things remaining constant, is usually difficult. Not only that, but the saying ‘if it isn’t broken, don’t try to fix it’ goes a long way in thwarting innovation.

How to initiate change when everything seems okay

The benefits of change described above may be completely clear to the management, and the people in the company, but until they are in some kind of trouble and need to change something, will they do something about it? It is a bit like a company selling goods online. They have been doing well for years, but the introduction of new companies who are offering the same goods through a more user-friendly webpage, they are beginning to see a drop in their market share. The competitors have, on the other hand, been seeing a steady increase. Looking back, they could have changed, for example improving their 10-year-old webpage, which was clearly out of date and putting some customers off. Instead they relied on their previous performance and reputation thus ignoring the need for change even though the signs were there. Now, that the results are consistently indicating something is not right they are hearing the alarm bells ringing. And what do they do? They develop a new web page, by which time some damage has been done and their competitors have perhaps gained the upper hand. This tells us two things:

The example above can be put into a different context and at a different level. Imagine a team inside a company working on a new software. They have a large user story that they have committed to resolving over a period of time, i.e. a several sprints. They began working on them, but soon realised that they might not be making the release date because testing software is preventing them from carrying out tests as they develop rather relying on the end test. Although they have a development plan, they are not reflecting on the risks and communicating them. In other words, they have not embraced a culture which gives them the freedom to organise their work by continuously reflecting and producing smaller functional releases. With the deadline and the all-important release looming large, what does the team do?

The art of letting them fail

If you are the Product Owner, and your goal is cultural change, which you believe will bring better performance in the future, you will not intervene. Even if that means that the team will probably fail to deliver a functional product? Yes, even if that is what it takes. Of course, you weigh out the risks and benefits, but if you are serious about investing in cultural change, and having a real team, then you may realise that it is better off letting them fail.

The logic behind this is that just like the goods provider with an outdated website, there needs to be a trigger for the team or a company to learn to change and live the agile principles. If you as the Product Owner step in the team has not learnt much. In fact, if they are new to the agile working environment intervention will only end up supporting their view that old ways are best. They will be happy to play with agile methods, but not take the associated responsibility. And as always, the product owner (or the big boss) solves it all. If, on the other hand, you let them fail you have probably done them a favour because they will be able to question what they are doing as a team and realise that the commitment and responsibility were not there from their side. In other words, you as a company will fail on delivering in the short run but will have probably succeeded in massively investing in cultural change that will yield results in the long run.

Support the learning process

This does not mean that you need to let everything burn down in an instant. Culture change is also about patience, trust, and strategic thinking. All are immensely important before embarking on letting teams experience failure in order to stimulate change culture. First of all, there needs to be consensus that cultural change is a strategy that requires commitment, even if it does not (and it probably won’t) work immediately. As a ScrumMaster and a Product Owner you need to have trust that the team will be able to reflect on the results and the reasons for the results. You also need to show patience and provide an enabling environment for the team to reflect and find a solution to the reasons for the failure. Communicating values and visions, while also living by them is crucial in this respect because it will help the team feel that they themselves have a place to reflect and therefore move forward. Ultimately, what you as both a ScrumMaster or a Product Owner want to have is a team that are change agents.

Wie man einen Wal in die Freiheit springen lässt – der Free Willy Ride in Agile Organizations

Mittlerweile sind in Unternehmen die 5 Phasen der Veränderung (bzw. der Trauer) nach Kübler-Ross allseits bekannt. Scheinbar bildet das Modell etwas ab, das Menschen mal mehr, mal weniger wiedererkennen und das ihnen in Veränderungsprozessen Orientierung bietet. Nach nunmehr einiger Zeit in der Rolle als ScrumMaster stelle ich folgende These auf:

Das Hineintragen des agilen Prinzips der Freiwilligkeit in ein klassisch arbeitendes Team verläuft (in den meisten Fällen) ebenfalls nach einem bestimmten Muster.

Ich nenne dieses Muster „Free Willy Ride in Agile Organizations“ nach Vera Ferreira Mafra. Zum einen amüsiert mich das Wortspiel im Englischen und zum anderen erscheint mir die Geschichte des berühmten Film-Wals „Free Willy“ eine gute Analogie zu sein. Ein Wal in Gefangenschaft (Kultur des Command & Control) schafft durch die Freundschaft mit einem Jungen (Agilität & ScrumMaster) den Sprung in die Freiheit (Leben der Freiwilligkeit & neue Haltung zur Arbeit). Die dramatische Komponente des Films, dass der Tierparkbesitzer Free Willy töten möchte, um die Versicherungsprämie zu kassieren, klammere ich für meine Zwecke aus.

Was ist der Free Willy Ride?

Der Free Willy Ride besteht aus acht Stationen: Kennenlernen – Sacken lassen – konfrontiert werden – Widerstand leisten – Verstehen – Transfer starten – Einspruch erheben – selbstverständlich anwenden

Veränderung

1. Kennenlernen
Zu Beginn hat der ScrumMaster einen großen Beitrag als Trainer zu leisten, um die agilen Prinzipien und Werte in einem Team bekannt zu machen. Durch Schulungen, Formate wie Brown Bag Sessions oder Scrum Shots, Literatur und und und erfahren die Teammitglieder, dass Freiwilligkeit ein agiles Prinzip ist. Die Augen werden groß, die Ohren spitz: Freiwilligkeit – das klingt gut!

2. Sacken lassen
Was eingangs zu großen Augen geführt hat, entpuppt sich bald als diffuse Worthülse. Als ScrumMaster lege ich meinen Fokus gerade auf Fokus und Commitment. Das Ziel ist, die Teams in einen Liefermodus zu bringen und Vertrauen zu mir aufzubauen. Wo macht sich denn nun die Freiwilligkeit bemerkbar?

3. Konfrontiert werden
Nachdem mich das Team als ScrumMaster nun schon ein wenig kennt und mit den Basics bereits erste Erfolge gefeiert hat, zaubere ich das Prinzip der Freiwilligkeit aus dem Hut. Ich nutze jede sich mir bietende Meetingsituation, um verschiedene agile Prinzipien gebetsmühlenartig zu platzieren:

Wenn ich merke, dass ein Meeting unzureichend vorbereitet ist und in vielschichtige Diskussionen ausartet, stehe ich auf, berufe mich ebenfalls auf das Prinzip der zwei Füße und verlasse ohne weitere Erklärung den Meetingraum. Ein völlig perplexes Team bleibt zurück. Ich ziehe es durch und das Team erlebt Freiwilligkeit. In den Teammitgliedern bewegt es etwas, gut so.

4. Widerstand leisten
Freiwilligkeit als Gesprächsthema steht jetzt im Raum. Egal wie sich die Teammitglieder drehen und wenden, ich piekse mit der Freiwilligkeit. Und jetzt passiert etwas Spannendes: Die Teammitglieder instrumentalisieren das Prinzip der Freiwilligkeit. Es fallen Sätze wie:

Die Teams führen das Thema ad absurdum, aus den Mündern tönen Ironie und Skepsis – aber: Sie sprechen darüber und nutzen die Begrifflichkeiten. Klammheimlich vollführe ich Freudentänze: Endlich habe ich eine Basis, auf der ich in die konstruktive Auseinandersetzung mit dem Team gehen kann.

5. Verstehen
„Lasst uns doch mal eine kleine Session starten, die wir einzig und allein dem Thema Freiwilligkeit widmen!“ Ich erkläre dem Team, in welchen Rahmen sich diese proklamierte Freiwilligkeit einbettet. Ich erzähle ihnen von ihrer Aufgabe als Dev-Team, die Qualität des Produkts sicherzustellen, und von Team-Commitment. Ich erkläre ihnen, dass die Freiwilligkeit ihre Wahlmöglichkeiten erweitert: Sie dürfen auf einmal „Nein“ sagen und sie dürfen auf einmal sagen, bei welchen Aufgaben sie sich selbst sehen.

6. Transfer starten
Freiwilligkeit ist nach der Session kein Schwarz-Weiß-Thema mehr. An manchen Teammitgliedern ist das Thema ohnehin vorbeigegangen, weil es ihnen nicht wichtig erscheint, andere verweilen weiterhin im Widerstand. Das ist völlig okay, ich konzentriere mich auf diejenigen, die neugierig fragen und sich in ihrem Alltag damit auseinandersetzen. „Also ich sehe gerade ehrlich gesagt keinen Mehrwert für mich in diesem Meeting und einen Beitrag leisten kann ich auch nicht … Gesetz der zwei Füße, oder?“ „Jetzt ist der richtige Zeitpunkt zu pullen, oder?“ Sie sprechen ihre Gedanken aus und hängen gefühlt an jeden Satz ein fragendes „oder?“, oder sie machen Aussagen und gehen am Satzende etwas mit ihrer Stimme hoch – meine detektivischen Sensoren springen an: Eine Frage als Aussage getarnt. Aha! Sie erfragen mein Feedback und tarieren aus, ob sie richtig liegen oder ob noch etwas fehlt.

7. Einspruch erheben
Meist haben die Teammitglieder nun für sich selbst in den verschiedensten Situationen hinterfragt, wann das Prinzip der Freiwilligkeit für sie greift und wie es mit anderen Prinzipien zusammenhängt. Im nächsten Schritt werden sie mutiger. Sie beobachten gezielt Situationen und nehmen für andere die Rolle des Richters ein: „Klaus, als PO ist es nicht deine Aufgabe, Tasks zuzuweisen! Das widerspricht dem Pull-Prinzip!“ Jackpot! Ich bin nicht mehr ein einsames querulantisches Fähnchen im Wind mit der Aufschrift Scrum. Stattdessen habe ich aus dem Team selbst heraus Fürsprecher gewinnen können! Dem Schneeballprinzip folgend, setzen sich zunehmend mehr Teammitglieder damit auseinander und es wird zum Usus im Team.

8. Selbstverständlich anwenden
Und dann springt Free Willy in die Freiheit und lässt los! Die Freiwilligkeit ist dem Team durch die bewusste Auseinandersetzung und durch die Reflexion in spezifischen Situationen in Fleisch und Blut übergegangen. Sie ist zum integralen Bestandteil der Arbeitsweise geworden.

Es hat mit einer Blogidee zum Thema Freiwilligkeit im agilen Arbeitsumfeld und einem Wortspiel begonnen. Ich wollte einen Namen für mein skizziertes Muster finden und das hat für mich persönlich den Wal schließlich zu einem Sinnbild für Freiwilligkeit in Teams werden lassen. Auf dem Weg zur gelebten Freiwilligkeit beobachte ich meine Teams und frage mich: „In welcher Phase schwimmt Free Willy gerade rum?“

Foto: CC0 Creative Commons – pixabay, Free-Photos

Disruptives Potential der Blockchain, Beweis des Eigentums

Kaum ein Thema wird derzeit so heiß diskutiert wie die Blockchain. Kryptowährungen wie Bitcoin und Co. sind dabei aber nur die Spitze des Eisbergs. Viele Experten sind sich schon heute einig, dass die Blockchain-Technologie die unterschiedlichsten Bereiche disruptiv verändern wird. In der Tech-Szene ist eine Aufbruchsstimmung spürbar wie zuletzt Mitte der Neunziger, als das Internet seinen Siegeszug antrat. Aber was ist eigentlich eine Blockchain? Und welches Potential hält sie für die Zukunft bereit? Die Antworten auf diese Fragen finden Sie im Video.

Agile Digital Banking: Praktische Tipps für das Miteinander von klassischen und agilen Teams

Nicht nur die sinkenden Markteintrittsbarrieren für Fintechs, sondern vor allem das sich wandelnde Kundenverhalten zählt zu den Disruptoren in der Bankenwelt und ist der größte Treiber für die agile digitale Transformation. Wie sollen die traditionellen Großbanken die Transformation zum agilen Finanzdienstleiter der Zukunft schaffen? Wie können relevante IT-Systeme und Banking-Kanäle nahtlos in die agile Welt übertragen werden? Und, eine weitere wichtige Frage in diesem Kontext: Wie können agile und klassische Teams dabei gleichermaßen erfolgreich gemanagt werden?
Vor welcher Hürde klassische Banken stehen, wird besonders in der Agile Organization Study 2017 deutlich: 84 Prozent der – vorwiegend aus dem deutschen Finanzsektor stammenden – befragten 119 Unternehmen bezeichnen das Zusammenspiel von agilen und traditionellen Teams in ihrer Organisation als große Herausforderung. Punktuelle Innovation Labs oder vereinzelte agile Teams in einem ansonsten klassischen Projektumfeld stoßen oft auf langjährig gewachsene und unflexible IT-Strukturen. Bei der Einführung von agilen Management Frameworks wie Scrum entstehen daher Spannungen, die aus dem Weg geräumt werden müssen.

Konstruktive Koexistenz statt Krieg der Welten

Wenn agile und klassische Teams gemeinsam an der Realisierung eines Projekts arbeiten, prallen sehr verschiedene Mindsets und Kulturen aufeinander. Zusätzlich wird die Arbeit der Teams, die einem agilen Ansatz folgen, durch streng hierarchische, regulatorische und fragmentierte (IT-)Strukturen schwieriger. Denn die ohnehin schon komplexe agile Banking-Transformationen wird durch nicht-kompatible IT-Plattformen, Systemlandschaften und Programmiersprachen verstärkt. Hinzu kommt: Für eine erfolgreiche digitale Transformation muss die Digitalisierungsinitiative der Banken sowohl attraktive und innovative Frontend-Lösungen für eine bessere Customer Experience als auch entsprechend angepasste Prozesse sowie Kernbanken- und Backendsysteme mit einschließen.

5 Schritte zur Integration von agilen und klassischen Teams

Um von Beginn an die richtigen Weichen für den Change zu stellen, empfehlen wir 5 Schritte zur Integration von agilen und klassischen Teams. Diese Schritte sind aus der Kombination von praktischen Erfahrungen und Change-Management-Ansätze entstanden:

1. Value Your Teams

Für einige Teams kommt die Umstellung auf agile Vorgehensweisen ziemlich abrupt. Kaum ein Unternehmen hat die Zeit, einen „weichen“, jahrelangen Übergang zu planen. Also werden Teams zusammengestellt, die als „Auserwählte“ von jetzt an dem gerade ins Leben gerufenen Innovation Lab angehören und bei der Digitalisierungsinitiative des Finanzinstituts mitwirken. Einige Mitarbeiter haben die Möglichkeit, sich nach dem Prinzip der Freiwilligkeit dort einzufinden, andere werden unfreiwillig in ihre neue Rolle eingeführt. Eine solche Trennung in der Organisation ist selten mit völliger Akzeptanz und Vorfreude verbunden.
Während die neu geschaffenen agilen Abteilungen erst in ihre Rollen hineinwachsen müssen, beobachten klassische Teams, wie die agilen Pioniere an ihnen vorbeiziehen und eine Sonderstellung im Unternehmen einnehmen. Um Neid und interne Konflikte zu vermeiden, müssen alle Teams im Unternehmen vom Management wertgeschätzt werden. Genau das Gleiche gilt für unterschiedliche Produktentwicklungsansätze. Denn es gibt durchaus Projekte, die nach dem ganz klassischen Projektmanagement gelingen. Dafür muss ein stabiles Umfeld gegeben sein, wie zum Beispiel überwiegend bekannte Anforderungen und Technologien sowie ein überschaubarer Projektumfang. Dann können auch klassische Wasserfall-Projekte hervorragend funktionieren. Da die Realität aber oft anders aussieht, greift man bei eher unklaren Anforderungen und Technologien im dynamischen Umfeld auf agile Frameworks wie Scrum zurück. Wenn das allen im Unternehmen klar ist, inklusive dem Management, kann die Transformation starten.
Unser Praxistipp: Schätzen Sie jedes Ihrer Teams wert, das einen Beitrag zum großen Ganzen liefert, auch jene, die es nicht ins Inno Lab geschafft haben. Motivieren Sie klassische Teams, den nächsten Schritt der Digitalisierungsinitiative mitzugestalten. Und holen Sie jene ab, die durch die Wörter Agilität und Scrum bereits ins Tal der Tränen befördert wurden.

2. Communicate continuously

Das bringt uns zum zweiten Punkt: Kontinuierliche und offene Kommunikation zwischen den agilen Teams und jenen, die im selben Unternehmen weiterhin unter dem klassischen Führungsverständnis arbeiten. Das ist einer der wichtigsten Erfolgsfaktoren für eine effektive Zusammenarbeit an einer gemeinsamen Digitalisierungsstrategie. Laden Sie verschiedene Teams aus unterschiedlichen Fachbereichen zu Ihren agilen Teams ein, damit sie Rollen, Artefakte, Meetings und Meeting-Formate der agilen Welt kennenlernen können. An einem Tag der offenen Tür oder in Form von Open Spaces können Themen wie Selbstorganisation allen Mitarbeitern nähergebracht werden. Auch Vorträge von aufstrebenden Fintechs oder anderen Keynote-Speakern zum Thema Agilität können angeboten werden. Es entsteht ein Austausch.
Unser Praxistipp: Kommunikation und Transparenz sind entscheidend für die gute Zusammenarbeit beider Welten. Das Vertrauen aller Mitarbeiter in einen erfolgreichen Change-Prozess kann in erster Linie durch transparente Maßnahmen und eine motivierende Vision gestärkt werden.

3. Change to Vertical Integration

An diesem Change müssen die Teams gemeinsam arbeiten. Ein einzelnes Team oder Inno Lab kann auf lange Sicht nicht alleine eine nachhaltige vertikale Digitalisierungsstrategie umsetzen. Um auf vertikaler Ebene, also silo- oder spartenübergreifend Minimum Viable Products (MVPs) zu entwickeln und zu verbessern, werden viele Teams gebraucht, die zusammenarbeiten. (Mehr zum Thema MVPs im Video von Boris Gloger) Klassische Teams mit agilen Teams in Einklang zu bringen, ist hier eine Herausforderung. Denn die klassischen Teams müssen den Transfer ebenfalls schaffen und verstehen, welche und wie viele Abhängigkeiten es untereinander gibt. Die Monolithen-Technologie der Banken sollte einem stabilen Netzwerk aus Microservices weichen, das Abhängigkeiten reduziert und die Flexibilität erhöht. Dieser Change muss nicht nur tatsächlich, sondern zunächst in den Köpfen der wichtigsten Veränderungskraft im Unternehmen stattfinden: in jenen der Mitarbeiter.
Unser Praxistipp: Auch wenn viele klassische Teams in ihrer bisherigen Form beibehalten werden und nur ein kleiner Teil im Unternehmen agil arbeitet, sollten so viele Teams wie möglich in den vertikalen Produktentwicklungsprozess eingebunden werden. Wenn auch nur, um aufzuzeigen, dass hier klassische Methoden schnell an ihre Grenzen kommen.

4. Create Interfaces

Eine weitere Schwierigkeit liegt auf der IT-Ebene. Wenn starre Altsysteme mit den schnellen Entwicklungen auf dem Markt nicht mehr mithalten können, muss eine Lösung her: Agiler und digitaler sollen die Banken werden. Und das möglichst schnell. Alte und nicht kompatible Programmiersprachen machen das Vorhaben nicht einfacher. Um weder den klassischen noch den agilen Teams den Mut zu nehmen, können Schnittstellen inkrementell und iterativ geliefert werden. Klassische Teams können früh in die Produktentwicklung der Schnittstellen-Lösungen mit eingebunden werden, wenn sie sich Mock-ups ansehen und „ausprobieren“ können.
Unser Praxistipp: Zum Sprint Review, in dem das fertige Produktinkrement präsentiert wird, können auch klassische Teams aus anderen Fachbereichen eingeladen werden, um die Energie und Bedeutung dieses Events mitzuerleben.

5. Embrace (Colliding) Cultures

Mit der Etablierung agiler Teams in einem bisher klassischen Projektumfeld treffen branchenübergreifend unterschiedlich stark ausgeprägte Unternehmenskulturen und Werte aufeinander. Das liegt besonders an den unterschiedlichen Mindsets der Menschen, die eine Organisation erst agil machen. Oder eben auch nicht. Hinter den agilen Mindsets verbergen sich Mitarbeiter, die die agilen Werte „Fokus“, „Commitment“, „Offenheit“, „Mut“ und „Respekt“ nicht nur verinnerlicht haben, sondern auch leben. Sie fordern ein Umfeld mit kurzen Feedback-Schleifen, inkrementeller Produktentwicklung und wollen sich gemeinsam im Team ständig weiterentwickeln. Hinter dem klassischen Mindset verbirgt sich nichts anderes als die Denkmuster, die viele schon seit der Schule perfektioniert haben. Dazu zählt die besondere Wertschätzung in der Vergangenheit bewährter Methoden, Prozesse, Rollenbilder und oft auch Hierarchien. Selbstorganisation gehört oft nicht zu jenen Dingen, die wir in der Schule, an der Uni oder am Arbeitsplatz lernen.
Daher: Einige Teammitglieder werden den Mindset-Change leichter vollziehen, andere werden die Themen Agilität und Scrum von Beginn an strikt ablehnen. Um den Aufprall der unterschiedlichen Kulturen abzufangen, muss die Notwendigkeit für den agilen Wandel allen Mitarbeitern kommuniziert werden. Es müssen Plattformen geschaffen werden, um die agile und die klassische Welt miteinander zu verbinden. Die übergeordnete Vision der Transformation darf daher weiterhin klassisch arbeitenden Teams nicht vorenthalten werden. Denn schließlich bewegt sich die Organisation (im besten Fall) in eine gemeinsame Richtung.
Unser Praxistipp: Eine der wichtigsten Botschaften, um Offenheit für eine neue Kultur zu erzeugen, ist den immensen Kundennutzen in den Fokus zu rücken, der durch iteratives Entwickeln und die frühe Einbindung des Users entsteht. Kaum etwas ist effektiver, als User-Feedback hautnah mitzuerleben. Daher: Laden Sie klassische Teams dazu ein, dabei zu sein, wenn dem Nutzer fertige End-to-End-Lösungen präsentiert werden. Das zeigt deutlich, wie wichtig die Entwicklung nah am User ist.

Fazit

So oft wie möglich sollten andere Teammitglieder die Chance haben, sich zumindest indirekt am agilen digitalen Wandel eines Finanzdienstleisters zu beteiligen. UND: Nutzen Sie den Multiplikator-Effekt. Die crossfunktionale Teamstruktur in agilen Projekten ermöglicht es, das Wissen und die Expertise zum Thema Agilität auch in die Linienorganisation zu tragen. Ganz wird es nicht ausbleiben, dass die Rollen weiterhin ineinandergreifen. Nutzen Sie genau das aus, denn die Teams können sich untereinander von der neuen Dynamik am besten begeistern.

Veränderungen – eine Frage von dürfen, wollen und können

Als ich in den letzten Wochen in Gesprächen von meinem Job erzählte, drehten sich irgendwann alle um das Thema Veränderungen im Allgemeinen und Übernahme von Verantwortung im Speziellen. Es fielen die typischen Sätze wie „Das geht bei uns aber nicht“, „Meine Leute kriegen das nicht hin“, „Das ist echt so anstrengend“ oder auch „Ist es das denn wert? Geht doch auch so“.
Tut es das? Aus dem systemischen Coaching mag ich folgende Frage sehr: „Was passiert, wenn nichts passiert?“ Wenn wir aufhören, uns zu verändern. Geht das überhaupt? Und wie geht das eigentlich genau mit der Veränderung – kann man das lernen? Meine bisherigen Erfahrungen zeigen, dass es dabei nicht um die Methode – zum Beispiel um Scrum oder Kanban – geht. Die Prozesse sind klar, sind erprobt und funktionieren. Ist es also der menschliche Faktor, der Veränderungen ermöglichen oder verhindern kann?
Im agilen Kontext werden drei Faktoren beschrieben, die in meinen Augen nicht nur auf Mitarbeiter, sondern auch wunderbar auf „den Menschen in Gänze“ anwendbar sind: Dürfen. Wollen. Können.

Diese drei Faktoren bedingen sich gegenseitig. Wenn der Mensch nicht will, bringt es nichts, wenn er könnte oder sogar darf. Wenn er nicht darf, bringt es nur Frust, wenn er wollte und könnte. By the way: Natürlich muss man längst nicht alles wollen, was man kann.
In lang gelebten und erlernten Strukturen ist womöglich jedoch die Erlaubnis „von oben“, aus der Chefetage heraus, eine der Voraussetzungen für die Umsetzung von Veränderungen beim einzelnen Mitarbeiter. Denn: das Wollen kann über das Dürfen gefördert werden, davon bin ich überzeugt. Erst langsam und zaghaft, ähnlich einem scheuen Wesen, das noch nicht weiß, welche Gefahren vielleicht in dem Raum lauern, der sich da plötzlich auftut. Ich durfte mehrfach erleben, wie sehr Mitarbeiter aufblühen, wenn sie sich ausprobieren und Verantwortung übernehmen dürfen, ohne Angst vor etwaigen Folgen haben zu müssen, wenn etwas schiefgeht. Das ist für eine Führungskraft ein tolles Erlebnis.
Was bräuchte es dafür also konkret?

Dürfen

Es braucht Führungskräfte, die sich selbst hinterfragen und hinterfragen lassen. Die ihre Mitarbeiter nicht als Erfüllungsgehilfen für den nächsten Bonus sehen, sondern als Mitstreiter an ihrer Seite auf dem Weg zum zufriedenen Kunden, einem erfolgreichen Projekt oder Produkt. Ein Mensch, der anderen Menschen etwas zutraut und ihnen erlaubt, selbst zu denken und zu handeln.
Jemand, der Vertrauen in sich selbst und seine Mitstreiter hat und loslassen kann. Eine Chefetage, die Fehler erlaubt und sie sogar begrüßt, denn durch Fehler generiert man im Mindesten neues Wissen, wenn nicht sogar neue Ideen und Produkte. Eine Führungskraft, die ihre Mitarbeiter und deren Erfolge feiert und wahrnimmt. Die ein positives Menschenbild hat und bereit ist, Wissen zu teilen, Fehler zu verzeihen, Mut zu fördern und Rahmenbedingungen zu schaffen, in denen all dies möglich sein kann.
Aber: Führungskräfte sind tatsächlich auch nur Menschen, die den gleichen inneren und äußeren Herausforderungen gegenüberstehen wie jeder andere auch. Das vergessen wir nur manchmal gern und erwarten, dass sie alles sofort richtig machen. Auch für sie sollte also gelten: Fehlermachen ist erlaubt und gewünscht.

Wollen

Wenn die Führungsebene die ehrlich gemeinte Einladung zur Veränderung ausspricht, dann braucht es den Willen der Mitarbeiter, diese Einladung auch anzunehmen. Auch hier sind Selbstreflexion, Veränderungsbereitschaft und Mut nötig. Es hilft immens, wenn die Mitarbeiter sich selbst, ihre Kompetenzen und Fähigkeiten kennen oder kennenlernen wollen. Sich selbst Fehler zu erlauben, ist manchmal gar nicht so einfach. Aber mit der Zeit kann man das lernen. Mitarbeiter sollten neugierig sein und Lust haben, Dinge auszuprobieren. Auch sie sollten bereit sein, ihr Menschenbild zu überprüfen und den Führungskräften die Chance und Zeit zur Veränderung geben. Das bedeutet also nicht nur Nachsicht mit sich selbst bei Rückschlägen, sondern auch mit den Kolleginnen und Kollegen aus anderen Abteilungen und/oder Hierarchien.

Können

Der Faktor des Könnens ist wohl derjenige, der am ehesten über Trainings, Weiterbildungen und Kompetenzentwicklung veränderbar ist. Hier kann und darf die HR-Abteilung zeigen, was sie draufhat und die Mitarbeiter in ein neues miteinander Arbeiten begleiten. Fachliches Know-how über Veränderungsprozesse und verschiedene Methoden, Coachings durch die Führungskraft oder einen „agile Coach“, das Schaffen von Räumen und Rahmenbedingungen, um die neuen Erkenntnisse zu testen, sind hier nur einige Dinge, die es braucht, um die Kunst der Veränderung zu lernen. Neben der Unterstützung durch HR und andere Formate müssen Mitarbeiter und Führungskräfte sich jedoch auch selbst um ihre Weiterbildung kümmern wollen.
„Eine schlechte Angewohnheit kann man nicht einfach aus dem Fenster schmeißen. Man muss sie Stufe für Stufe aus dem Haus begleiten“, habe ich irgendwo gelesen. Und ich kann aus eigener Erfahrung sagen: Die wehren sich. Die einen mehr, die anderen weniger. Aber alle tun es. Es dauert, macht definitiv nicht nur Spaß, kann und darf zwischendurch wehtun. Vielleicht wie bei einem Training für einen Marathon? Aber: Es darf Spaß machen und manche Angewohnheiten hüpfen die Treppen freiwillig runter, sobald Sie sich die Erlaubnis gegeben haben, die Tür aufzumachen. Und gegen den Schmerz helfen die kleinen Erfolge, die sich recht schnell einstellen.
Klar ist: Es erfordert großen Mut von allen Beteiligten, sich auf dieses Wagnis der Veränderung einzulassen. Einen Vorschuss an Vertrauen und das Verlernen der gemeinsamen Vorgeschichte sowie der Denkweisen, an die man sich so schön gewöhnt hat. Das Unbekannte und Neue macht erstmal Unsicherheit und Angst. Und das geht allen so, egal, ob Sie Chef sind oder nicht.
Ich wünsche Ihnen viel Erfolg, Durchhaltevermögen und auch Spaß daran und ziehe meinen Hut vor allen, die allein schon darüber nachdenken, sich auf diesen Weg zu machen.

Video: Die Organisation 4.0

 
In den letzten Videos haben wir uns intensiv damit auseinandergesetzt, welche Bedingungen notwendig sind, um Scrum in verteilten Teams oder großen Projekten nachhaltig einzusetzen. Dabei habe ich betont, dass ein modernes Architekturkonzept die Grundlage für die erfolgreiche Skalierung ist. Wie sieht das nun mit Scrum als Framework aus? Muss auch der verändert werden?
Ich denke: ja! Nicht indem man noch mehr Meetings erfindet, noch mehr Artefakte oder gar Rollen hinzufügt, sondern indem man das Bild von Scrum neu interpretiert. So, dass es Skalieren leicht macht und mit dem übereinstimmt, was ich in erfolgreich skalierenden Unternehmen beobachtet habe.
Scrum auf diese Weise neu zu denken, erfordert Mut, denn es bricht noch stärker mit den traditionellen Denkmustern des Managements.
 
Viel Spaß beim Anschauen – Boris
 
PS: In “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” könnt ihr die Herleitung dieses neuen Ansatzes nachlesen.
 

 

Video: Change Management – Es ist nicht der Prozess

 
Wodurch wird die Entwicklung einer Organisation, eine Veränderung, möglich? Sind es alleine die sogenannten Change-Management-Prozesse, wie die berühmten acht Schritte von Kotter?
Ich behaupte: Es steckt etwas völlig anderes dahinter. Ich bin sogar der Meinung, dass der Change in einer Organisation fast von selbst entsteht, wenn es gelingt, für die involvierten Menschen einen Grund zur Veränderung zu finden, der einen Mehrwert stiftet. Wenn es also gelingt, die Veränderung mit den Menschen und nicht für die Menschen oder über die Menschen hinweg anzustoßen.
Die Forderung “Macht die Betroffenen zu Beteiligten”, drückt diese Tatsache nicht stark genug aus. Beteiligt zu sein, bedeutet nur: Die Menschen dürfen mitmachen. Es bedeutet aber nicht, dass sie auch etwas von der Veränderung haben.
In diesem Video erzähle ich eine Geschichte, die das illustriert.
Viel Spaß beim Anschauen.
 

Video: Change Management – Virgina Satir

 
Virgina Satir hat bereits in den 1970er-Jahren herausgearbeitet, wie der Change-Prozess in sozialen Systemen funktioniert. Dieser Framework von Satir hilft dabei, als ScrumMaster oder Change Agent zu verstehen, wie Veränderung funktioniert. Man kann dieses Modell auch nutzen, um zu erkennen, an welcher Stelle des Veränderungsprozesses man sich gerade befindet. Das Modell ist also auch ein Analyseinstrument.
Die Beschäftigung damit lohnt sich, weil man damit auch leichter erkennt, wie man in der jeweiligen Situation handeln könnte. Oder: “Der Change ist sowieso da, man befindet sich nur möglicherweise in anderen Phasen.”
Ich wünsche Euch viel Spaß beim Anschauen — Boris
 

Agile Transformation: It is not about your managers’ buy-in

Whenever I get in touch with organizations that set sail for their endeavor of an agile transformation I hear one sentence frequently: „We need the top-management’s buy-in to be successful.“ Unfortunately, this is fundamentally wrong and I am honestly sorry that I dropped this sentence in some consulting projects myself some time ago. However, I was wrong and many others are as well. You don’t need a buy-in: You need absolute personal involvement, contribution, and engagement of your top-managers.

Top-managers are not the audience of change

I’m well aware of good reasons why it is called ‚top-management buy-in‘. Usually, when you want to launch a project – that one great idea – you simply need support, funds and someone who eventually is going to pull some strings if something blocks your great idea from becoming reality. This makes perfect sense whenever you want to sneak one project through a system, whenever you are looking for the red flag you can raise to get things done faster or without the common political games. All you need then is the backing from someone with enough authority to make things run a little smoother. However, this terminology is highly misleading when an organization is on its path of agile transformation.
To say that you need the buy-in from your top-managers, C-level executives, your major shareholders or the company’s owners is wrong because it turns these important people into the audience of the transformation process. However, these people are not sitting at the ranks looking down at the stage where the rest of the company is performing its unique ‘agile transformation’. On the contrary, (top-) managers are on the same stage as well.

Top-managers are part of the show

Agile transformations are organization-wide change movements even if they are started bottom-up. This quite often touches the core of an organization: its culture. Even if your top-manager says: „The agile transformation has my full buy-in, let me see where it goes” – it would in fact be going nowhere.
Unfortunately, I have experienced this more than once. It took me quite some time to understand the reasons to a broader extent. The (top-)management defines the culture of the whole organization. Organizational culture in that sense is everything that employees experience on a day-to-day basis without being able of expressing the details. Behavior of formal and informal authorities determines culture. Managers are without a doubt formal authorities.
So even if they just say: „We want agile!“ (which happens quite often recently), nothing significant is going to happen. To change the culture over the course of time, a visibly different managerial behavior on a day-to-day basis is needed, which is the whole idea of an agile transformation. Without the honest will of changing behavior, all change intentions are very likely going to fail.

To change the organization, change yourself

This leads to one important conclusion: (Top-)managers have to be(-have) agile to support an agile transformation. They must personally contribute to this organizational change. And I really mean ‘personally’. Of course, managers should fund the change. But it’s equally important that they invest in themselves to support the change. They should attend the same trainings as their employees, they should read the books they want employees to read and they need to make the same agile experiences they want their employees to make.
This is tough, because it implies that managers have to change first before the organization can follow. It even gets tougher: Agile behavior of top-managers ultimately limits the degree to which the whole organization can be agile. Bottom-up initiatives will only thrive until they collide with the top-managements behavior. If the top-management doesn’t take this collision as an impulse to inspect, reflect and adapt, the bottom-up initiative is going to deteriorate sooner or later.
The reason is obvious: To be agile it is necessary to learn how to behave differently. Agility is never just a matter of methods, processes or job descriptions. An agile mindset as the foundation of agile behavior is built upon agile experiences made in the past. How does it feel to be agile? Although ‘agile’ has a strong theoretical foundation, the agile mindset cannot be solely built on theory. Insights have to be rooted in personal experiences in order to be able to act differently. Agile experiences need to be personal, even for (top-)managers. Which also means that you cannot delegate change! You want someone to stick to his commitment? Do so yourself.

by SpaceX via unsplash.com

by SpaceX via unsplash.com


 

You cannot delegate change!

Once I had an interesting moment with a group of top-managers who had started an agile journey and began to work together as a top-management Scrum team. During the second sprint, which they performed very publicly for the rest of the organization, one of the top-managers posed an important question which I hear quite often from Scrum development teams. „What happens if we commit to deliver something and then someone gets ill and it cannot be delivered anymore?“ The same manager was asking the teams in the organization to make commitments all the time. But in this special moment he personally felt the pressure and seriousness of a commitment. This changed the way he interacted with the teams regarding commitments. He slowly understood that commitment is based on voluntariness.
This management Scrum team used a physical task board and held daily stand-ups publicly. They started to transparently deliver organizational change in iterations and invited employees to management reviews where employees gave feedback to the latest change-increment. They defined a company backlog and created a visible release plan for the company which displayed the strategic product initiatives of the company for the next months. They used the Magic Matrix Technique to structure their backlogs and got used to Magic Estimation. Some of them attended Scrum and agile leadership trainings and they experienced how much they needed a ScrumMaster in their team. They delivered frequently and user-centric. They had started to inspect, reflect and adapt. Within a short time, they became agile.
These top-managers began to walk around the company, talking about their own experiences in their personal agile transformation. And guess what happened: All over the company task boards emerged. Teams started to experiment with practices and artifacts, they used Scrum meetings to structure their delivery iterations and they started to make their progress visible to the rest of the company. Engaged people started creating guilds, flyers for coding dojos and tech bites circulated, and people from within the teams initiated hackathons.
Before the top-management team recognized these changes in their organization they tended to say: „We are the only ones in this company who are looking for change. It’s only us who want the agile transformation. The employees are so resistant to change. Very likely we are going to fail.“
Funnily enough, employees had desperately been longing for the change. Most of them wanted to work more agile and more collaboratively. But they did not feel well supported or they were afraid to start their own initiative because the management didn’t seem supportive. Some of them even told me that they had tried to be more agile but then had been pushed back by some of the top-managers. So, the foundation for the transformation had been there for a long time, however it needed the visible change of the top-managers’ behavior to make movement possible.

Being agile: Make it safe to fail

It might sound odd but in some consulting assignments I didn’t realize early enough that the managers themselves needed time to understand the basic elements of Scrum and an agile working environment. Honestly, I don’t know why, but somehow I assumed that the managers who “commissioned” an agile transformation already had understood the concept of an agile organization. However, that hardly ever was the case. As managers are only human like any other person in an organization they need the same time to understand and reflect. It became obvious to me that they needed a safe zone for experimenting and thinking without being under pressure or being judged.
Unfortunately, I often experience this not being the case. I experience (top-)managers pressured for success with ultra-tight schedules and stuffed calendars. In such an environment, it is almost impossible to have a positive learning experience. Learning quite often includes failure which – under the given circumstances – will be avoided at all cost.
To deal with such situations, I, as a consultant, usually request blocked time to work on agile experiences and to reflect and learn. If managers hardly ever have time to deeply think one topic through, I block whole days for offsite workshops. Don’t consider this time as wasted! It is crucial for managers to have that time to think, reflect, try and learn. You need some free capacity on your schedule and in your head to do so.

Practical implications for those longing for agile transformation

Are you working in an organization that needs a more agile culture but you don’t want to wait for your top-managers? Look for opportunities to involve them into your ‚agile life‘ so that they can make their own agile experiences. Quite often I experience (top-)managers being frustrated with sitting at the ranks of the theatre. Allow them to join you at the stage. This also means that you should have the courage to treat them as normal human beings or as colleagues. If no one ever invites (top-)managers to participate how are they supposed to make a personal experience of what it means for you to be agile?
The easiest way to involve your manager is by talking to him or her about your agile experiences and what you personally have learned. This might not change the managers’ mind over night, but it may create curiosity. The second easiest way is to invite your manager to some of your agile meetings. Most of the companies have some sort of ‘agile‘ established on team level. Give managers the chance to see for themselves. You might establish shared artifacts which help them to learn interacting with employees differently.
Agile awareness workshops are a more sophisticated way for managers to make agile experiences safely by using simulations and problem solving ‘games‘. This can be a door opener.
What if you cannot get in contact with top-managers? Then it might be a good start to engage the manager within your reach. Maybe he or she can – if personally willing to change – help to develop your working environment for the better. Over the course of time he might engage with managers in his range and so on. Obviously, this takes time and it carries the risk that the chain of engaged managers will never build up. Unfortunately, this might tell you one thing: As long as authorities, preventing the change, stay the same and are not forced into change by outside events, agile transformation very likely will not happen. If this is the case, you might have to consider to move on to a different organization.

Summary

Whenever you talk about agile transformation or an agile change program forget about the ‚top-management’s buy-in‘. You are going to need far more than that. What you want is personal involvement and engagement of your top-managers. Their capability of making a personal change determines the speed of change for the whole organization. To make a personal change, managers need time to try, reflect and learn just like any other employee in the organization.
 

Video: Scrum und Kulturwandel

Heute beantworte ich die Frage eines Zuschauers: “Wie fördert Scrum in festgefahrenen Unternehmen einen Kulturwandel, um die aktive Gestaltung zu reanimieren – mit dem Ziel, konkurrenzfähig zu sein und auch zu bleiben.”
 
Viel Spaß beim Anschauen — Boris
 

Agilität für Gesellschafter – das Video zum Vortrag

Bei der Agile Bodensee 2016 haben mein Kollege Karl Bredemeyer und ich einen Vortrag zum Thema “Agilität für Gesellschafter” gehalten. Inzwischen ist die Aufzeichnung des Vortrags verfügbar.

Und wer noch einmal nachlesen will:
Agilität für Gesellschafter: 7 Schritte, den Unternehmenswert nachhaltig zu steigern (Teil 1)
Agilität für Gesellschafter: 7 Schritte, den Unternehmenswert nachhaltig zu steigern (Teil 2)
 
 

Agilität für Gesellschafter: 7 Schritte, den Unternehmenswert nachhaltig zu steigern (Teil 2)

Dieser Blogbeitrag begleitet den gleichnamigen Vortrag von Stefan Willuda und mir auf der Agile Bodensee 2016. Teil 1 finden Sie hier.
Als Gesellschafter haben Sie Interesse daran, den Wert eines Unternehmens nachhaltig zu steigern. Agile Produktentwicklung wird mittlerweile als ein Faktor der Wertsteigerung betrachtet. Das nimmt Sie als Gesellschafter allerdings auch in die Pflicht: Sie können dazu beitragen, den Wert Ihres Unternehmens mit 7 Schritten nachhaltig zu steigern. Diese 7 Schritte bauen aufeinander auf. Sie sind wie ein Turm, lassen Sie einzelne Elemente aus, ist der Erfolg nicht mehr sichergestellt. Die 7 Schritte zur Steigerung des Unternehmenswertes umfassen die Werte, die Finanzen, die Organisation, die Methode und die Skills, die Produktentwicklung, die Architektur und die Infrastruktur. Im zweiten Teil betrachten wir nun die Schritte 5 bis 7.

5. Produktentwicklung

Um Produkte erfolgreich entwickeln zu können, sind grundsätzliche Änderungen im Mindset notwendig.
Produktorganisation statt Projektorganisation – Projekte haben ein Start- und ein Enddatum. Ein Produkt jedoch ist bis zu seinem endgültigen Lebenszyklusende nie fertig, sondern wird in Iterationen weiterentwickelt. Gleichzeitig erlaubt der Produktgedanke eine Nutzerzentrierung und lässt die Prozessorientierung in den Hintergrund rücken. Es ist in Ihrem Interesse, diese Organisationsveränderung durch das Top-Management herstellen zu lassen. Auf der Basis Ihrer konkreten, unverrückbaren Rahmenbedingungen kann das Topmanagement dann in Schritten die Transformation der Organisation vollziehen.
Agile Portfolioplanung – Immer wieder werden Priorisierungskonflikte unterschiedlicher Stakeholder innerhalb der Entwicklungsteams ausgetragen, da die Stakeholder vor dem Beginn der Produktentwicklung keinen Konsens über die relative Wichtigkeit ihrer Anforderungen herstellen konnten. Agile Portfolioplanung bringt alle beteiligten Parteien an einen Tisch und ermöglicht es, Prioritäten vor dem Hintergrund der Organisationsstrategie regelmäßig herauszufordern, zu bestätigen oder anzupassen. Sie sollten ein Interesse daran haben, jederzeit von Ihrem Topmanagement die gemeinsamen strategischen Initiativen vorgestellt zu bekommen, um die Produktentwicklung hochfokussiert und damit schnell vollziehen zu können.
Minimum Viable Product (z.B. Eric Ries) – Je früher ein Produkt bereits in seiner Minimalkonfiguration vom Nutzer getestet und dessen Feedback eingeholt werden kann, desto größer ist die Chance, dass ein für den Anwender wertvolles, da nutzenbringendes Produkt entwickelt wird. In vielen Organisationen fehlt es an Mut, den Anwender mit einem „unfertigen“ Produkt zu konfrontieren. Dabei ist dies in Zeiten der hohen Unsicherheit in Bezug auf die Kundenbedürfnisse die einzige Chance, früh zu überprüfen, ob das Richtige entwickelt wird. Aufbauend auf dem 2. der 7 Schritte, den Finanzen, ist das frühe Nutzerfeedback ein zentrales Element der Risikominimierung und damit aus der Perspektive der Wertsteigerung der Organisation unerlässlich. Sie sollten von Ihrem Topmanagement frühes und kontinuierliches Nutzerfeedback einfordern.

karl_tortenmvp

Der Gedanke hinter dem Minimum Viable Product (MVP)


 
Cross-funktionale Teams – Selbstorganisation und End-to-End-Verantwortung in den Teams gelingt nur dann, wenn die Teams in hohem Maße autark agieren, liefern und das Produkt betreuen können. Es gilt das Motto: You build it, you ship it, you run it! Dies bedeutet explizit, dass jeder Mitarbeiter je einem Team zu 100% seiner Arbeitszeit zugeordnet ist. Teams, die auf diese Art und Weise Produktverantwortung übernehmen können, zeigen in der Praxis ein außerordentlich hohes Qualitätsbewusstsein und stellen den Nutzer stärker in das Zentrum ihrer Anstrengungen. Um den Wert Ihrer Organisation zu steigern, sind diese beiden Aspekte essentiell. Natürlich ergeben sich daraus auch völlig neue Teamkonstellationen. Ein reines Entwicklungsteam kann dem obenstehenden Motto nicht entsprechen. Sie sollten den Auftrag an Ihr Topmanagement aussprechen, dieses Motto nach und nach in allen Teilen der Organisation umzusetzen. Die Konflikte, die dadurch zwangsläufig auch im Topmanagement entstehen (z.B. durch das Aufbrechen funktionaler Silos) können mit Ihrem Verweis auf das Ziel der Wertsteigerung aufgelöst werden.

Zusammenfassung

6. Die Architektur

Das bereits erwähnte Conway’s Law hat in erheblichem Maße Einfluss auf die Architektur der Produkte. Damit ist jede Form von Architektur gemeint – sowohl in der Software als auch in der Hardware. Wenn Sie in den Schritten 4 und 5 die Grundlagen für weitgehend autonom agierende, cross-funktionale Teams gelegt haben, so wird sich die Architektur als eine Bruchstelle Ihrer Bemühungen herausbilden. Teams, die ein Produkt, ein Teilprodukt oder eine technische Komponente nicht eigenständig entwickeln und ausliefern können, sind nicht in der Lage, die angestrebte Verantwortung zu übernehmen. Auch wird der Durchsatz der Teams durch Integrationsschritte limitiert. Die Bemühungen des 5. Schrittes, der Produktentwicklung, werden konterkariert. Sie können das Bewusstsein für diese Herausforderung in der Gestaltung der Produktarchitektur in die Organisation tragen und das Topmanagement auffordern, die Implikationen daraus in der strategischen Produktentwicklung zu beachten. Stichworte sind hierbei (Micro-)Service-Architekturen oder Plattformkonzepte. Der Grundgedanke dabei ist stets, dass die Kommunikationsbeziehungen in der Produktentwicklung mit der faktischen Produktgestaltung in Einklang gebracht werden.

Zusammenfassung

7. Die Infrastruktur

Automatisierung, Automatisierung, Automatisierung – An dieser Stelle schließt sich der Kreis zur Theory of Constraints: Manuelle Arbeit ist in nahezu jedem Wertschöpfungsprozess der Taktgeber und limitierende Faktor für die Entwicklungsgeschwindigkeit. Ihre Entwicklungs- und Produktionsumgebungen sollten in einem Maße automatisierbar sein, dass die Teams nicht mehr von wiederkehrenden manuellen Tätigkeiten, z.B. von manuellen Deployments oder Testläufen gebremst werden. Infrastruktur, die bisher physisch war, sollte zunehmend selbst als Software betrieben und automatisch bereitgestellt werden (Stichworte: Infrastructure as Code und Infrastructure as a Service). Auch interne Infrastrukturdienstleistungen – z.B. Rechnungsstellung, Onboarding neuer Mitarbeiter oder die Möbelbeschaffung – sollten, soweit sinnvoll, automatisiert werden.
Dieser letzte Transformationsschritt ist nicht trivial, baut auf den im 4. Schritt entwickelten Fähigkeiten und Methoden auf und stellt aus Ihrer Perspektive erneut ein Investment dar. Dieser 7. Schritt schließt konsequent den Kreis zu einem im 1. Schritt erwähnten Prinzip: Verschwendung vermeiden. Jede Minute, die ein qualifizierter Mitarbeiter mit vermeidbarer, manueller Arbeit beschäftigt ist, ist Verschwendung. Zeit, in der wertgenerierende Arbeit geleistet oder einfach einmal entspannt werden kann.

Zusammenfassung

7 Schritte, ein Ziel

Im Ergebnis zahlen alle 7 Schritte auf ein Ziel ein: den Wert des Unternehmens langfristig zu steigern. Wir empfehlen Ihnen, sich allen 7 Schritten mit gebührender Aufmerksamkeit zu widmen, denn nur dann wird Ihr Unternehmen sein volles Potential entfalten. Diese 7 Schritte sind wie ein Produkt: Sie sind nie fertig. Alle 7 Schritte sollten kontinuierlich auf noch nicht gehobenes Potenzial überprüft werden.

Agilität für Gesellschafter: 7 Schritte, den Unternehmenswert nachhaltig zu steigern (Teil 1)

Dieser Blogbeitrag begleitet den gleichnamigen Vortrag von Karl Bredemeyer und mir auf der Agile Bodensee 2016.

Vor einiger Zeit arbeiteten wir in einem großen Beratungsmandat, bei dem es darum ging, die Zusammenarbeit in einem Unternehmen über die gesamte Wertschöpfungskette – von der Idee bis zur Auslieferung des Produkts an den Anwender – zu optimieren. Das übergeordnete Ziel des Auftraggebers war es, die Lieferfähigkeit seiner Organisation deutlich zu steigern und die Produktentwicklung stärker auf die Bedürfnisse der Anwender auszurichten. Wir analysierten die Ausgangssituation und stellten fest, dass es eine große Distanz zwischen der Seite der Anforderung und der Seite der Produktentwicklung gab. Vereinfachend ließ sich der Befund wie ein großer, tiefer Graben zwischen Produktmanagement und Anwendungsentwicklung beschreiben.
Innerhalb dieses Beratungsmandats gelang es uns, die Brücke zum Gesellschafterkreis des Unternehmens zu schlagen. Die Gesellschafter unterstützten die Prinzipien agilen Arbeitens mit dem expliziten Ziel, den Wert des Unternehmens zu steigern und verpflichteten das Topmanagement zur gemeinsamen Verbesserung der Lieferfähigkeit in einem unternehmenseigenen „agile way“, der den Anwender in das Zentrum sämtlicher Aktivitäten stellt. Entlang unserer Empfehlungen begann nun die Optimierung der Lieferkette.

Wann agiles Arbeiten funktioniert

Machen wir es kurz: Agiles Arbeiten funktioniert in der Praxis nur dann, wenn es das explizite Ziel ist, mit der Agilität den Unternehmenswert nachhaltig zu steigern. Sie als Gesellschafter sind es, die agiles Arbeiten zum Wohle der Wertsteigerung im Unternehmen und damit zu Ihrem eigenen Wohl vorleben und einfordern sollten. Dadurch wird Agilität zu einem immateriellen Vermögenswert Ihres Unternehmens, zur DNA der Organisation und zu einem Teil der Unternehmenskultur. Dies macht eines deutlich: Es geht bei der Einführung von Rahmenwerken wie Scrum, Kanban etc. im Kern weder darum, Entwicklungsteams produktiver zu machen oder ein Taskboard in ein Großraumbüro zu stellen und bunte Zettel darauf von links nach recht zu schieben, noch geht es darum, die Mitarbeiter zufriedener zu machen, auch wenn das ziemlich oft ein erfreuliches Ergebnis agiler Unternehmensführung ist.
Eine agile Transformation ist eine große Investition und erfordert Geduld – vor allem Ihre Geduld und Ihr unbedingtes Buy-In als Gesellschafter. In dem Augenblick, in dem für Sie der Zusammenhang zwischen agilen Führungs- und Entwicklungsrahmenwerken und der nachhaltigen Steigerung des Unternehmenswertes klar geworden ist, hat Agilität eine echte Chance, zu einem Teil Ihres Unternehmens zu werden und eine positive Wirkung im Sinne der Wertsteigerung zu entfalten. Ohne den Zusammenhang zwischen Agilität und Unternehmenswertsteigerung bleibt agiles Arbeiten nur Kosmetik.

Liebe Gesellschafter, es geht um Sie!

Niemand weiß es besser als Sie: Die heutigen Zeiten sind geprägt von einem komplexen Markt, diffusen Kundenwünschen und erheblichem Wettbewerbsdruck. Es ist in Ihrem Interesse, Agilität mit ihren Facetten zum Betriebssystem Ihres Unternehmens, Ihres Investments zu machen.
Sie als Gesellschafter können den Wert Ihres Unternehmens mit 7 Schritten nachhaltig steigern. Diese 7 Schritte bauen aufeinander auf. Sie sind wie ein Turm: Lassen Sie einzelne Elemente aus, ist der Erfolg nicht mehr sichergestellt. Die 7 Schritte zur Steigerung des Unternehmenswertes umfassen

  1. die Werte,
  2. die Finanzen,
  3. die Organisation,
  4. die Methode und die Skills,
  5. die Produktentwicklung,
  6. die Architektur und
  7. die Infrastruktur.

Betrachten wir in diesem ersten Teil die Schritte 1 bis 4 näher.

photocase7ocpo6gba68m1

picea/photocase.de

1. Die Werte

Die Kenntlichmachung agiler Werte bildet das Fundament für jede agile Transformation. Hierzu gehören nicht allein die fünf Scrum-Werte Fokus (der wichtigste!), Mut, Commitment, Offenheit und Respekt oder die Verortung auf dem agilen Manifest, sondern auch die Integration von Lean-Prinzipien (eliminate waste, Pull etc.). Als Gesellschafter sorgen Sie in letzter Konsequenz für die Ausrichtung Ihres Unternehmens, selbst dann, wenn das operative Management an ein C-Level-Board übertragen wird. Sie als Gesellschafter sollten persönlich und erkennbar vorleben, dass diese Werte eine Bedeutung für Ihr tägliches Handeln besitzen. Es ändert zum Beispiel die Kultur Ihres Unternehmens, wenn Sie immer wieder klarmachen, dass es wertvoller ist, etwas zu Ende zu bringen, statt etwas Neues zu starten. Für die ledigliche Ankündigung einer Lieferung gibt es von Ihnen keine Anerkennung mehr.
Sie haben darüber hinaus die Verantwortung, das Mindset zur kontinuierlichen Verbesserung in kleinen Schritten in das tägliche Handeln der durch Sie beeinflussten Manager zu übertragen. Von dort aus wird sich dieses im Unternehmen verbreiten. Nutzen Sie beispielsweise regelmäßige Retrospektiven auf allen Ebenen der Organisation als Taktgeber für diese Verbesserung.

Zusammenfassung

2. Die Finanzen

Agile Produktentwicklung wird von Wirtschaftsprüfungsgesellschaften wie KPMG inzwischen als Asset gewertet, falls diese in der Unternehmung verankert ist, da sich daraus eine schnelle Reaktionsfähigkeit sowie eine hohe Produktqualität ableiten lassen. Genau diese Reaktionsfähigkeit und Produktqualität leiden jedoch häufig unter der klassischen Kostenrechnung und der damit verbundenen Überbetonung der Kostenkontrolle und lokalen Effizienzgewinne. Der zweite logische, aber mutige Schritt zur Steigerung des Unternehmenswertes bewegt sich weg von der klassischen Kostenrechnung hin zu einer durchsatzorientierten Betrachtung der Wertschöpfungsprozesse (Stichwort Throughput Accounting). Aus diesem Perspektivenwechsel leiten sich für Sie eine Fülle von Möglichkeiten ab, neue qualitative Managemententscheidungen zu treffen.
Bei diesem Schritt können Sie sich von einem Leitgedanken führen lassen: Finanzdaten und die Prozesse zu deren Erhebung dürfen die Mitarbeiter nicht an ihrer eigentlichen Arbeit hindern, nämlich Nutzen für den Anwender zu generieren. Das führt Sie zu neuen Möglichkeiten der Freigabe von Investitionsbudgets. Verlegen Sie in der Bewertung von Investitionsentscheidungen Ihren Schwerpunkt von den (ohnehin kaum sinnvoll prognostizierbaren) Kalkulationen des Returns on Investment hin zu Risikoszenarien. Statt zu fragen: „Wie viel erhalte ich in den nächsten Jahren zurück?“, stellen Sie die Frage: „Wie viel lasse ich das Investitionsexperiment maximal kosten, bis ich meine Mittel stoppe?“ Oder fragen Sie nach der Cost of Delay: „Wie viel Umsatz steht auf dem Spiel, wenn ich dieses Investment nicht oder später tätige?“
Dieser neue Schwerpunkt bei Investitionsentscheidungen wird die Art des Diskurses in Ihrem Management positiv beeinflussen. Wir haben bereits Manager erlebt, die selbst wie Investoren agierten. Mitarbeiter konnten Investitionsvorhaben (Projekte) pitchen und um Mittel werben. Daraus erwächst im Laufe der Zeit eine Unternehmenskultur, die das Probieren und Lernen der Risikoaversion vorzieht.

Zusammenfassung

3. Die Organisation

Eine Organisation ist nur so schnell wie ihre langsamste Liefereinheit – sowohl in einem Transformationsprozess als auch in der Entwicklung und Herstellung von Produkten. Am besten adressieren Sie daher im 3. Schritt die folgenden Themen auf der Ebene der Organisationsentwicklung:
Jeder Manager der Organisation sollte die Theory of Constraints (ToC, auch Engpasstheorie genannt) verstehen und in sein praktisches Handeln überführen können. Verkürzt beschreibt die Theory of Constraints, dass es in jedem Liefer- oder Wertschöpfungsprozess immer einen Engpass gibt, der die Ausbringungsmenge des Prozesses maximal begrenzt. Wenn die Ausbringungsmenge dieses Prozesses gesteigert werden soll, dann ist jedes Investment außerhalb des Engpasses Geldverschwendung, da es nicht dazu dienen kann, den Durchsatz zu steigern. Wenn Sie Ihren Mitteleinsatz entsprechend fokussieren, sind die finanzwirtschaftlichen Folgen erheblich. Allerdings müssen Sie dafür im 2. der 7 Schritte das Verständnis für durchsatzorientierte Finanzrechnung in Ihre Organisation eingebracht haben.
Slack – Menschen ohne Zeitpuffer produzieren Fehler, die das unerfreuliche Potenzial in sich bergen, ein gesamtes System lahmzulegen. Sie haben außerdem im wahrsten Sinne des Wortes keinen Platz für Innovation. Puffer oder auch freie Zeit bei der Arbeit in einem Wertschöpfungsprozess ist nicht nur sinnvoll, es ist die logische Folge der Theory of Constraints: Jeder Mitarbeiter, der nicht am Engpass arbeitet, muss unweigerlich „Freizeit“ (Slack) haben. Sie sollten Organisationen aufbauen lassen, in denen die maximale Auslastung von Mitarbeitern oder Maschinen nicht das Ziel, sondern verboten ist.
Wie die Theory of Constraints sollte Conway’s Law verstanden und bei der Organisationsgestaltung beachtet werden. Conway’s Law beschreibt, dass die Systementwürfe (oder Produkte) einer Organisation immer die Kommunikationsstrukturen dieser Organisation abbilden. Was sich sehr theoretisch anhören mag, hat erhebliche praktische Implikationen. Falls Sie am Nutzer orientierte Produkte entwickeln wollen, werden Sie auch eine Organisation entwickeln müssen, die sich am Nutzer orientiert.
Da agile Organisationsgestaltung nicht allein mit diesen drei Konzepten bewältigt werden kann, sollten Sie und Ihre Topmanager sich auch mit den folgenden Themen vertraut machen:

Es hat sich bewährt, im Management ein fundiertes, gemeinsames Verständnis dieser Themenfelder zu erzeugen. Der Erfolg der tatsächlichen Umsetzung hängt maßgeblich von Ihrem Engagement und Ihrer gezielten Rahmensetzung ab.

Zusammenfassung

4. Die Methode und das Skillset

Den Fokus des Managementhandelns Ihrer Organisation auf das Erlernen von Fähigkeiten und Methoden agilen Arbeitens zu lenken, ist erst dann sinnvoll, wenn ein hinreichend stabiles Fundament durch die ersten drei Schritte gelegt wurde. Wir beobachten oft, dass die agilen Skills auf der Ebene einzelner Teams schnell Erfolg zeigen, an den bestehenden Organisationsstrukturen und an der Unternehmenskultur drohen die Transformationsbemühungen dann aber zu scheitern.
Sie als Gesellschafter prägen durch Ihr beobachtbares Verhalten das Verhalten der Topmanager und damit die Kultur des Unternehmens. Erst wenn sich eine Kultur agilen Arbeitens erkennbar ausbildet, wird die Vermittlung von Methoden und Fähigkeiten ökonomisch wirksam. Falls in Ihrem Unternehmen bereits Bottom-up-Ansätze agilen Arbeitens erkennbar werden, schaffen Sie am besten die Rahmenbedingungen, die dieses Arbeiten unterstützen.
Agile Skills und Methoden wie

entfalten im Sinne der Wertschöpfung eine größere Wirkung, wenn sie auf einen fruchtbaren Boden fallen, der von der Organisation vorbereitet wurde. Es ist in Ihrem Interesse, das Wissen über diese Fähigkeiten und Methoden durch das Topmanagement in einer Organisation verbreiten zu lassen und es ist sinnvoll, dass Sie sich diese Fähigkeiten zunächst selbst aneignen und die Methoden selbst nutzen.

Zusammenfassung

Hier geht es weiter mit den Schritten 5 bis 7!

Warum Executives den Plastikmüll raustragen sollten

Samstag Morgen — die Küche der Glogers
Ich öffne die Lade unter unserer Spüle, wo die Abfallbehälter stehen. Wir trennen den Müll und der Plastikmüllbehälter ist schon wieder voll.
Boris
(seufzend)
Puh, das ist ja schon wieder voll!
Meine Frau Kathrin
(mit einem wissenden Lächeln)
Du kannst den Plastikmüll ruhig runterbringen.
Boris
Oh Mann, ich will den Müll nicht schon wieder raustragen. 
Das ist echt viel Plastikmüll. Ich frage mich, ob die Vorstände von OMV oder Shell den Plastikmüll selbst runterbringen müssen. Ich wette, die wissen gar nicht, wie viel Plastik in ihrem Haus ständig weggeworfen wird.
Plötzlich macht es bei mir „Klick“. Das ist es! Die Bosse der großen Unternehmen sind wahrscheinlich so weit von der Realität entfernt, dass sie gar nicht spüren, was sie verursachen. Wer den Plastikmüll nicht selbst zur Mülltrennung trägt, bemerkt doch gar nicht, wie viel Müll das ist. Wer verantwortlich ist für all das Plastik, weil er es erzeugt oder die Rohstoffe zur Verfügung stellt, aber selbst womöglich gar nicht mitbekommt, was das anrichten kann, der denkt auch nicht darüber nach, wie er das wieder verändern kann. (Ich gebe zu, das sind wahrscheinlich falsche Annahmen, ich stelle mir halt einen dieser Konzernbosse in der schicken Villa mit Dienstboten vor.) Ich als derjenige, der das viele Plastik selbst runtertragen muss, überlege natürlich sofort, wie ich das viele Plastik vermeiden könnte. Könnte ich vielleicht weniger einkaufen?
Versteht mich nicht falsch: Ich bin weit davon entfernt, Konzern-CXOs zu verurteilen. Ich frage mich nur, was wäre, wenn sie selbst ihren eigenen Plastikmüll raustragen müssten. Würde das etwas ändern?
Für mich ist diese Frage deshalb so wichtig, weil wir in der agilen Welt von Feedback reden … Genau das ist ein Beispiel für das Feedback, das wir brauchen. Wer etwas verursacht, zum Beispiel Plastikmüll, oder einen Defect in einem Softwareprogramm, der muss auch mitbekommen, was diese Handlung ausgelöst hat. Er wird anfangen, seine verursachende Handlung zu ändern, sollten die Konsequenzen unangenehm sein.

Agil im Konzern: Was habt ihr mit den CIOs gemacht?

Es war ein Workshopraum, wie ihn viele agile Teams nutzen: Stehtische, Pinnwände, Flipcharts, locker verteilte Sitzgelegenheiten. Menschen waren in Diskussionen vertieft, sie sprachen miteinander über Lösungen für das, was ihre Arbeit behinderte. Normales agiles Teamwork eben. Und doch war etwas anders.
Bei diesem Workshop des Transition Teams eines Konzerns trafen sich CIOs mit Entwicklern, Sachbearbeitern, HR-Experten und Softwarearchitekten – denn die CIOs sind hier das Transition Team. Ein Jahr zuvor hatte das Top-Management der Konzern-IT das Thema Agilität auf die Liste der strategischen Ziele für die kommenden Jahre gesetzt. Der Unterschied: Statt der Organisation die Veränderung zur Agilität zu verordnen, involvierten sich die CIOs in den Prozess – ohne die üblichen Folienschlachten und Reportingberge, die man in einem Konzern erwarten würde. Einzelne Scrum-Teams hatte es in der Konzern-IT schon gegeben, bevor Agilität zur Strategie erhoben wurde, aber das hatte nicht gereicht, um den agilen Gedanken in der Organisation zu verankern. An den Problemen dieser Vorreiter arbeitete sich das Top-Management aber nun entlang: Die CIOs suchten den Kontakt mit den Menschen der Arbeitsebene und sahen ihre Aufgabe darin, den Rahmen zu schaffen, der agiles Arbeiten leichter machen würde als bisher. „Ich habe unser Top-Management noch nie so erlebt, was habt ihr mit ihnen gemacht?“, fragte uns ein Mitarbeiter ganz offen.

Der Vorschlag

Ein halbes Jahr vor diesem Meeting waren wir als Berater dazu eingeladen, unsere Sicht von Agilität zu präsentieren und ein erstes Konzept für die agile Transition der Konzern-IT zu skizzieren. Noch deutete nichts auf die Dynamik hin, die diese Transition bekommen sollte, denn am meterlangen Konferenztisch im gediegenen Meetingraum schien das nur ein Tagespunkt von vielen zu sein. Drei Fragen standen im Vordergrund:

Unser einfacher Vorschlag: Wir nähern uns den Lösungen anhand der Impediments, auf die wir treffen und wenden die Prozesse und Rollen von Scrum auf den Veränderungsprozess an – so wie man es in der Produktentwicklung auch in einem Team machen würde. Auch wenn nicht sofort Begeisterungsstürme losbrachen, hallte der Vorschlag scheinbar nach. Wir wurden eingeladen, fünf Wochen später einen zweitägigen Workshop abzuhalten.
Aus der formellen Umgebung der Konzern-Meetingräume, die Hierarchien schon durch die Sitzordnung zementieren, holten wir die CIOs in die lockere Atmosphäre eines Design Thinking Space. Zum Workshop waren auch Digital Natives aus dem Konzern eingeladen, die voller Ideen steckten und anders arbeiten wollten. In Teams, besetzt mit Menschen aus allen Hierarchieebenen, lernten die Manager die agile Arbeitsweise kennen, die Werkzeuge und Techniken, und sie arbeiteten sich anhand des Design-Thinking-Prozesses durch den Workshop. Am Ende der zwei Tage stand fest: Wir machen das.

Die Umsetzung

Die CIOs bildeten das Transition Team, das als Product Owner der Transition die strategische Ausrichtung vorgab. Im Gespräch mit den Mitgliedern der Scrum-Teams der Konzern-IT entstand eine Liste von zehn Impediments, die priorisiert wurden. Je nach Impediment entwickelten funktional oder crossfunktional besetzte Realisierungsteams (die teilweise in Sprints arbeiteten) gemeinsam mit den Scrum-Teams die Lösungen – die Realisierungsteams entsprachen in ihrer Rolle also einem Entwicklungsteam, die Scrum-Teams waren die „User“ der Lösung.
Alle drei Wochen traf sich nun das CIO-Transition-Team zu einem eintägigen Workshop. Für die Top-Manager ein großer zeitlicher Aufwand, darauf wiesen sie uns immer wieder hin, aber sie wollten es und sahen, wie wichtig es war. Neben den Realisierungsteams wurden zu diesen Workshops immer auch Vertreter der Scrum-Teams eingeladen, denn es waren Reviews, wie sie in Scrum vorgesehen sind: Welche Lösungen haben wie geklappt, wo können die CIOs noch helfen? Die CIOs wollten die Probleme verstehen, um dann passende Aufträge zu erarbeiten. An den ersten CTT-Meetings nahmen die Kollegen aus der Arbeitsebene nur verhalten teil. Teilweise herrschte die Angst, normale Mitarbeiter seien nicht „managementfähig“ oder man müsse ohnehin tun, was der CIO sagt. Doch als die ersten positiven Erfahrungen die Runde machten und die CTT-Meetings in eine kollaborative Umgebung – den eingangs erwähnten Workshopraum – wechselten, waren plötzlich mehr Mitarbeiter als Manager im Raum. Offen und sachlich wurden Themen aus allen Teilen der Organisation diskutiert; Experten, Betroffene und Management arbeiteten gemeinsam an den Lösungen.

Erfolgspraktiken

Konzerne haben nicht den Ruf, Horte der Agilität zu sein. Schon gar nicht erwartet man dort Top-Manager, die sich selbst in die Transition einbringen. Warum hat es in diesem Fall geklappt?

Wir als Berater erlebten in diesem halben Jahr, wie durch das hierarchieübergreifende Arbeiten das Vertrauen zwischen den Menschen stetig wuchs, auch bei unserer eigenen Arbeit in jenem Team, das die Workshops vorbereitete. Mussten wir zu Beginn alle Abläufe nach den Konzern-Gepflogenheiten in dicken Manuals minutiös planen und in Endlosschleifen abstimmen, zählte in den letzten Meetings der Inhalt mehr als die Form. Nur das wirklich Wichtige wurde dokumentiert, der Vorbereitungsaufwand sank von 64 Tagen auf 10. Allmählich fühlte sich die Bezeichnung „Transition“ für diesen Entwicklungsprozess nicht mehr richtig an. Mittlerweile war es mehr zur Integration von Scrum in die Organisation geworden. Als ScrumMaster dieser Integration mussten wir immer seltener steuernd eingreifen und erkannten ohne viele Worte, was das Transition Team gerade brauchte. Es gab keine Ziele wie „80 Prozent der Projekte müssen agil durchgeführt werden“. Gemeinsam ließen wir durch das Lösen der Impediments agile Ökosysteme entstehen, die sich von selbst weiterentwickeln und in die Organisation wachsen.

Die Scrum-Implementierung – zwischen absoluter Planung und Intuition

„Wir machen jetzt Scrum.” Ansage. Immerhin. Das Management hat gesprochen. Noch nicht ganz SMART formuliert, über die Messbarkeit und die Geschwindigkeit könnte man noch streiten, aber die Richtung  ist eindeutig. Egal, ob Sie in Wahrung alter Gewohnheiten einen Report befüllen müssen, sich den Grundsätzen des klassischen Projektmanagements verpflichtet fühlen oder einfach nur gerne strukturiert arbeiten: Eine Checkliste, Themenübersicht oder irgendein anderes Stück Papier, das die vielen kleinen Zahnrädchen darstellt, die Stück für Stück justiert werden müssen, “wenn wir jetzt Scrum machen”, könnte dabei durchaus hilfreich sein. (siehe dazu Boris’ Blog: Das geheime Leben der Checklisten)
Für ein Beratungsunternehmen wie unseres wäre es legitim, mit der ultimativen Checkliste als Planungs- und Assessment-Tool in ein Projekt zu gehen – Wirtschaftsprüfer gehen ja auch schematisch vor. Gibt es denn eine Copy-Paste-Lösung, die externe Experten im Rahmen eines Beratungsauftrags zur Verfügung stellen können? Oder müssen sich Einsteiger durch einen Berg an Scrum-Literatur kämpfen, um für eine vernünftige Implementierung auch ja nichts zu vergessen?

Checkliste, ein Versuch

Da der Wunsch nach einer Checkliste nachvollziehbar ist, versuchen wir, sie gemeinsam zu erstellen. Für den Anfang schlage ich vor, dass wir uns an der Struktur des Scrum-Flows orientieren. Wir listen also alle Rollen, Meetings und Artefakte auf. In einem weiteren Schritt nehmen wir die einzelnen Bestandteile unserer Liste und versuchen uns vorzustellen, was denn alles (nicht) funktionieren kann oder soll und im Idealfall auch messbar wäre. Hat das Team geliefert, was committet wurde? Wie lange ist das Selected Backlog? Und wie oft haben wir es eigentlich geschafft, User an unserem Sprint teilhaben zu lassen? Der Ordnung halber sollten wir uns gleich auf eine Vorgehensweise einigen, die wir beachten:
Schritt 1: Welches Impediment können wir im Bezug auf den aufgelisteten Bestandteil ableiten? (1)
Schritt 2: Wie lässt sich über unsere Checkliste ein Soll-Ist-Vergleich umsetzen? (2)
Schritt 3: Wie können wir uns dem Soll nähern? Die Lösung eines potenziellen Problems ist ja in Wirklichkeit Ziel der Übung! (3)

Das gehört zu …?

Während wir also eine – relativ lange – Liste kleiner Zahnrädchen erstellen, werden wir zu irgendeinem Zeitpunkt feststellen, dass manches nicht unmittelbar zuordenbar ist. Pünktlichkeit – Bestandteil aller Meetings. Ja, wichtig! Sehr wichtig! Daher potenzielles Impediment. (1) Aber gehört die Pünktlichkeit in die Rollen- oder in die Meetings-Rubrik unserer Liste? Da wir die Checkliste erstellen, um unsere Zahnrädchen Stück für Stück zu bewegen und das Meeting nichts dafür kann, dass ein Kollege „schnell noch etwas fertig machen musste“ und alle anderen warten lässt, ist es meiner Meinung nach den Personen, also den Rollen zuzuschreiben. Nachdem das erklärte Ziel der Übung aber eine Verbesserung des Status quo ist und es nicht um Stigmatisierung oder Zu-Tode-evaluieren geht, bietet es sich an, bei den Rollen eine übergeordnete Position für „das Team“ zu bilden. Das Thema Pünktlichkeit betrifft ja alle.
Es ist für eine Gruppe relativ leicht zu bestimmen, ob alle Teilnehmer pünktlich zu einem Meeting erschienen sind und selbstverständlich können wir über den ermittelten Pünktlichkeitswert des Teams eine beliebige Skala legen, die Ist und Soll visualisiert. (2) Auch die Akzeptanz gemeinsamer Normen erscheint ein durchaus erreichbares Ziel. Jede Gruppe kann für sich feststellen, ob es in Ordnung ist, dass ein oder zwei Mal pro Sprint jemand zu spät kommt oder ob Verspätungen generell nicht geduldet werden. Sobald der Punkt erreicht ist, an dem das Team für sich festlegt, dass das Maß voll ist und die mangelhafte Pünktlichkeit zum Impediment erklärt wird, lässt sich das Impediment auch mit einem einfachen Mittel beseitigen: Selbstdisziplin. Im Zweifelsfall ein deutliches Zeichen der Gruppe, dass Verspätungen nicht weiter toleriert werden. Das muss keine groß angelegte Intervention sein, oft hilft es, das Meeting ohne die zu spät Kommenden zu beginnen oder die Türen des Meetingraums pünktlich zu schließen. In den meisten Fällen zeigt ein kleiner Wink mit dem Zaunpfahl bereits große Wirkung. (3)

Schubladenprobleme

Während wir unsere Liste weiter vervollständigen, werden wir zwangsläufig auf Faktoren treffen, die sich trotz übergreifender Kategorien wie „Team“ nicht eindeutig einer Schublade zuweisen lassen. Oft finden sich auch Dinge wie die Kaffeemaschine auf dem Impediment Backlog. Eindeutig kein Team-Thema, auch in der Rubrik „Infrastruktur“ wäre die Kaffeemaschine in einem IT-Umfeld eher exotisch. Trotzdem nicht zu vernachlässigen! Wenn ich als externer Consultant in ein Unternehmen komme und eines der ersten Leiden, die ich zu hören bekomme, ist der Zustand der Büro-Kaffeemaschine, erlaubt mir das zwei Schlussfolgerungen: Das Thema beschäftigt die Mitarbeiter wirklich und ich habe die Möglichkeit, über einen Quick Win die Motivation des Teams zu erhöhen und schrittweise Vertrauen zu erlangen.Wir nehmen uns Themen wie einer neuen Kaffeemaschine also gerne an.
Nachdem wir den Status der Kaffeemaschine mit 0 oder 1 bewertet haben (Schulnoten finde ich persönlich etwas überzogen), arbeiten wir uns in der Liste weiter vor. Auf der Liste der vergleichsweise kritischeren Erfahrungen, die man als Consultant machen kann, rangiert der Satz „der ScrumMaster ist das Impediment“ schon weiter oben. Ohne auf  Details einzugehen oder zu wiederholen, wieso es in Change-Prozessen so weit kommen kann, kann man hier in kurzen Worten feststellen:

Das Problem erfordert also offensichtlich eine qualitative Betrachtung. Auch qualitative Betrachtungen stoßen jedoch an ihre Grenzen! Verdeutlichen wir uns das anhand einer anderen Frage unserer Checkliste: War das Format der letzten Retrospektive für die Situation des Teams angemessen? Ja, auch dieser Punkt verdient die Aufnahme in unsere Checkliste. (1) Aber spätestens beim Versuch der Feststellung und Bewertung sehen wir uns mit einem anderen Problem konfrontiert: Selbst wenn unsere Retro gut war und das Format in der Situation für alle Teilnehmer als passend erschien: Woher können wir wissen, dass es da draußen nicht irgendwo ein besseres Format gibt?
Eine schwierige Frage, welche die Legitimation von Checklisten und Bulletpoints als absolute Tools zum Assessment endgültig in Frage stellt. So hilfreich ein reflektierender Leitfaden sein kann, so deutlich sind seine Grenzen. Um diese Grenzen zu überschreiten, gibt es für ScrumMaster nur einen Lösungsansatz: Erfahrung sammeln, laufend dazulernen und auch auf die Intuition hören! Das mit der Bewertung unserer Bulletpoints kommt dann von selbst, ganz ohne Papier.

Scrum funktioniert bei uns nicht

Die meisten Unternehmen, die uns derzeit kontaktieren, haben bereits Erfahrungen mit Scrum gemacht. Warum rufen sie uns an, wenn sie doch schon wissen, wie es geht? Nun, nachdem diese Gespräche die „können wir schon … wissen wir schon …“-Phase durchlaufen haben, fällt dann meistens der Satz: „Scrum funktioniert bei uns nicht.“ Warum ist das so? Es gibt doch viele Firmen, die mit Scrum erfolgreich sind – was läuft bei den anderen falsch?
Wie wir in diversen Diskussionen unter Kollegen immer wieder feststellen: Scrum ist ein Rahmenwerk, nicht mehr und nicht weniger. Wenn Scrum funktionieren soll, muss es mit Werten gefüllt werden und das kann das Rahmenwerk nun mal nicht selbst – dazu braucht es die Menschen, die damit arbeiten. Gleichzeitig sollte dieses Rahmenwerk aber auch nicht so verbogen werden, bis es sich an die natürlich gewachsene Struktur des Unternehmens angepasst hat und im Prinzip alles so weiterläuft wie bisher.

Die natürliche Abwehrreaktion des Systems

Das ist jedoch die natürliche Reaktion, sobald Scrum in einem Unternehmen eingeführt wird. Im Rahmen einer schon bisher dysfunktionalen Meetingkultur werden nun neue Meetings abgehalten und es wird versucht, in Iterationen zu arbeiten. So weit, so gut. Vielleicht schickt man noch ein paar Leute in die Ausbildung zum Product Owner oder ScrumMaster und besetzt die Positionen. Aus den Jahreszielen werden noch schnell Gruppenziele gemacht und jetzt will man sich zufrieden zurücklehnen können, von unendlichen Geschwindigkeitszuwächsen träumen und die selbstorganisierten Teams alle Probleme selbstständig lösen lassen (aber bitte nicht gegen den Willen des Teamleiters, sonst fühlt er sich gekränkt). Was passiert ist: Es wurde eine zusätzliche Schicht eingezogen, aber kein konkretes Problem gelöst. Ich kann diesen Wunsch gut nachvollziehen, weil ich den Fehler selbst gemacht habe – aber es funktioniert einfach nicht. Scrum per se löst keine Probleme. Es zeigt nur, wo Änderungen notwendig sind.

Woran erkennen wir, dass sich trotzdem etwas bewegt?

Wenn nach der Einführung von Scrum plötzlich die Teams keine Zeit mehr zum Arbeiten haben, weil sie in noch mehr Meetings als vorher sitzen, dann liegt es nicht daran, dass Scrum so meetingintensiv ist. Es liegt daran, dass Scrum keine zusätzlichen Meetings impliziert. Scrum ist meetingtechnisch vollständig – schmeißen Sie also alle anderen Meetings raus und lassen Sie Ihre Leute arbeiten. Wenn Sie nach der Einführung von Scrum plötzlich Leute aufschreien hören, dass das so nicht geht, Kompetenzen verletzt werden und Unsicherheiten entstehen, dann arbeiten Sie mit den Leuten an Ihren neuen Rollen oder holen Sie externe Unterstützung.
Letztendlich ist das Aufkommen dieser “Probleme” nicht schlecht. Es sind einfach nur Indikatoren dafür, wie weit man auf dem Weg der Veränderung einer Systemkultur vorangekommen ist. Diese Indikatoren anzusehen mag schmerzlich sein, aber der Schmerz geht vorbei, sofern man das Problem sieht und an einer Lösung arbeitet. Scrum bewirkt einen Paradigmenwechsel in einem existierenden System. Und jeder Paradigmenwechsel ist mit einer Form von Schmerz verbunden: mit dem Schmerz, das Alte aufzugeben und etwas Neues anzunehmen. Wenn Ihre Leute aufschreien und unzufrieden mit dem Status Quo sind, freuen Sie sich!
Was Sie gerade sehen, ist wertlos gebundene menschliche Energie, die frei wird. Mit dieser Energie können Sie nun einen Wandel einleiten, der zu einer wirklichen Veränderung des Gesamtsystem beiträgt. Bleiben Sie dran, immerhin wissen Sie jetzt, wo Ihre Ansatzpunkte liegen, wo Sie die nächsten Schritte setzen müssen auf dem Weg zu einer gemeinsamen agilen Kultur.

Status des Agilen Festpreises

Trotz Alerts, Twitter & Co habe ich ab und zu das Bedürfnis, die Google-Search-Engine zum Thema “Verträge für agile Projekte” oder “Agiler Festpreis”, auch “Agile Contracts” genannt, zu durchstöbern. Dabei stolpere ich immer wieder über die üblichen Verdächtigen, beziehungsweise über die gleichen Seiten, die seit Jahren als Mahnmale in den Weiten des Netzes stehen und ihren Ruf in die Ferne klingen lassen: “Ist eh klar!” Gemeint sind Webseiten & Blogs, die Möglichkeiten zeigen, wie man einen Vertrag gestalten kann, um mehr Vorteile des agilen Vorgehens zu nutzen oder das Risiko zwischen Kunden und Lieferanten zu teilen. So rügen Blog-Posts wie einer von Alistair Cockburn aus dem Jahr 2006 den immer noch nicht Bekehrten mit einer Liste von 15 Möglichkeiten, wie er seinen agilen Vertrag konstruieren kann. Wobei die meisten Varianten in knappen 4 bis 8 Zeilen beschrieben sind. Ist das Thema nun so einfach oder in Wirklichkeit sehr komplex? In meinen Gesprächen zu diesem Thema drängt sich mir aber immer mehr der Verdacht auf, dass es nicht um die Komplexität des Themas geht, sondern eher um Erfahrungswerte sowie das Unverständnis, wie dieses neue Konzept in der bestehenden Kultur des eigenen Unternehmens angewendet werden könnte.
Zumindest nach dem Durchlesen des Buchs “Der Agile Festpreis” haben viele die Grundzüge des Themas verstanden. Die meisten attestieren auch, dass dies ein wichtiger nächster Schritt für eine agile Organisation ist. Was meist fehlt, ist der Glaube, dass dies auch wirklich so möglich ist. In der Praxis zeigt sich das sehr oft dadurch, dass der Fokus der meisten Diskussionen auf der Glaubwürdigkeit und Anwendbarkeit liegt. Welche Unternehmen haben das schon gemacht? Wie würden sie das genau in unserer Situation anwenden? Wir arbeiten mit internen Dienstleistern, da ist das sowieso etwas anders, oder? Komplex ist der Agile Festpreis eigentlich nicht. Schwierig ist oft die konkrete Anwendung des neuen Konzepts in einer bestehenden Unternehmenskultur und das Sammeln der Details und der Erfahrung, die für die Einführung dieses neuen Prozesses notwendig ist.
Das mit der Kultur ist eben so eine Sache. Man kann nicht einfach mit einem neuen Begriff um sich werfen, einen schönen Plan für eine Reorganisation entwerfen und dann den Kultur-Schalter umlegen. Nein, es muss vorgelebt werden und wenn der damit errichtete Leuchtturm das Licht gut verteilt, folgen immer mehr Schiffe dem Beispiel. Das ist ja auch wesentlicher Bestandteil des agilen Vorgehens: Wenn man vor einer komplexen oder unübersichtlich großen Aufgabe steht und nicht sicher ist, wie man es angehen soll, startet man am besten mal und kontrolliert den Fortschritt.
So auch der Appell an all jene, die immer noch mit Freelancer-Time&Material-Heerscharen kämpfen, oder im Hoffnungsmodell des Festpreisvertrags ihre Nerven und ihr Geld verschwenden, einfach mal zu beginnen und sich nicht von einem “eh klar” abschrecken zu lassen. Das Konzept ist klar, aber die Umsetzung und das Ausrollen ist in jedem Unternehmen eine eigene Herausforderung. Die agile Organisation beginnt und endet an ihren Schnittstellen nach außen. Das heißt: Jedes Unternehmen, das sich agiler aufstellen will, muss sich über kurz oder lang auch mit den Lieferantenbeziehungen beschäftigen. Wenn man das richtig hinkriegt, kann man einige der Vorteile agiler Methoden erst richtig nutzen. Einkaufs- und Vertragsprozesse anzupassen und die damit verbundene Kultur einer Partnerschaftlichkeit zu leben, ist ein wesentlicher Aspekt des Erfolgs. Viele Unternehmen haben in den letzten Jahren – auch mit unserer Hilfe – den Schritt gewagt. Es gibt also mittlerweile genügend Erfahrung, auf der andere Unternehmen nun mit Bedacht aufbauen können.

Teamgeist beim Münchner Staffelmarathon oder was gute Zielsetzungen bewirken können

Für mich begann alles im Mai, als ich eingeladen wurde, an der Winquadrat Zukunftskonferenz des Uni Management Clubs in Österreich teilzunehmen. Ich saß in der 5. Reihe im wunderschönen Haydnsaal des Schlosses Esterházy und hörte dem Extremsportler Gerhard Gulewicz bei seinem Visionärstalk „Erfolgsstrategien im Sport und der Wirtschaft“ zu, wie er von der Wichtigkeit von Zielsetzungen erzählte. Wie so oft im Leben, hat bei ihm alles mit einer Wette angefangen. Doch wie eher selten im Leben, hat er sich mithilfe seiner unwahrscheinlich starken persönlichen Motivation und sehr klaren Zielsetzungen bis auf das Podium beim Race Across America hochtrainiert.
Seine Präsentation hieß nicht umsonst Visionärstalk. Noch während er auf der Bühne stand, war ich motiviert, meinen Körper mal wieder richtig zu fordern und auf ein hoch gestecktes, aber doch erreichbares Ziel hinzuarbeiten. Diese Gedanken schwirrten noch in meinem Kopf als ich ein paar Wochen später beschloss, mich gemeinsam mit einigen Kollegen des bor!sgloger Teams für eine unserer zwei Staffeln beim Marathon in München anzumelden.
Heute frage ich mich zurecht, wie wir es eigentlich geschafft haben, an diesem traumhaft schönen Herbstsonntag nach 04:03 Stunden tatsächlich gemeinsam ins Ziel einzulaufen?! Es ist kein Geheimnis, wenn ich sage, dass wir verdammt hart und viel arbeiten. Wir reisen quer durch Europa, verbringen eine Menge unserer Abende bzw. Morgen im Taxi, Flugzeug, Bus, Zug oder Auto und richtig gesundes Essen sehen wir auch nur am Wochenende, wenn wir uns dazu aufrappeln können, aus den Inhalten unserer leeren Kühlschränke ein halbwegs vernünftiges Gericht zu kochen.
Ich denke jedoch, dass ich meine Frage selbst beantworten kann. Einerseits durch die klare Zielsetzung à la Gerhard Gulewicz, denn die war wirklich SMART:

Ja, unsere Zielsetzungen waren klar. Doch andererseits hat auch die gegenseitige Motivation, die man nur als Team fördern kann, dazu beigetragen, diese Zielsetzung zu erreichen. An dieser Stelle möchte ich mich retrospektiv bei meinem Team bedanken! Ohne die monatelange Motivation (gemeinsames Joggen in den Abendstunden, gegenseitiger Ansporn zum frühen Aufstehen) bis hin zur letzten Sekunde (danke an meinen Kollegen Karl für die lustigen Anekdoten aus deinem Leben, die du mir erzählt hast, um mich während der letzten Kilometer bei Laune zu halten), hätte ich meinen Körper wohl kaum dazu mobilisieren können, diese Leistung zu erbringen. Mein schönster Moment war, als ich ca. 500 Meter vor dem Ziel mit heraushängender Zunge meine restlichen Teammitglieder vom Straßenrand auf mich zulaufen sah. Das hat einerseits dazu geführt, dass wir alle noch einmal einen Zahn zugelegt haben, andererseits, dass wir geschlossen als Team über die Ziellinie gelaufen sind. Danke dafür 🙂
Der Staffelmarathon hat mich gelehrt, noch mehr an die Kraft der SMARTen Zielsetzung und des Teamgeistes zu glauben. Sowohl beruflich als auch privat. Nur so kann man sich wirklich kontinuierlich verbessern. Was heißt das jetzt für alle Scrummler da draußen? Ich denke schon, dass man das ganz einfach in die Agile Welt übertragen kann. Z.B. lieber ScrumMaster: Wie genau lautet dein Ziel, das du mit der Lösung eines Impediments erreichen möchtest? Lieber Product Owner, bitte achte darauf, dass du ganz klar definierte Sprintziele kommunizierst und SMARTe User Stories schreibst. Liebes Dev.Team, achtet darauf, dass ihr gemeinsam die User Stories abarbeitet. Nur mit einem gemeinsamen Ziel könnt ihr auch wirklich aus der vollen Motivationsquelle schöpfen!

Nachsatz: Da wir in unserer Profession täglich von der kontinuierlichen Verbesserung sprechen, konnten wir uns jetzt natürlich nicht einfach auf die Schultern klopfen und wieder getrennte Wege gehen. Nein. Nachdem wir ersteres getan hatten, haben wir uns mittlerweile zum größten Staffelmarathon der Welt in Wien für Frühjahr 2014 angemeldet. Und dieses Mal werden wir definitiv unter der 4-Stunden-Grenze liegen!

IMG_3540

First, let's fire all agile coaches

Eine spannende Debatte ist ausgebrochen: Was bringen agile Coaches? Auf Think Different argumentiert Bob Marshall gegen den Einsatz agiler Berater: Zum einen, schreibt er, versprechen sie das Blaue vom Himmel und machen damit Unternehmen falsche Hoffnungen. Zum anderen führen sie zu lokalen Optimierungen innerhalb des Unternehmens, indem bestimmte Gruppen (meist Scrum-Teams) erhöhte Ressourcen und Aufmerksamkeit bekommen.
Bob Marshall wirft damit die Frage nach dem Selbstvertändnis von agilen Coaches und ScrumMastern auf. Sind wir dazu da, agile Luftschlösser zu bauen und die Rosinen für unsere Scrum-Teams herauszupicken? Dass diese Wahrnehmung entstehen kann – und auch häufig ensteht – sei geschenkt. Das ist ja auch einer der Gründe, warum Scrum-Implementationen scheitern: Die Differenz zwischen Anspruch und Wirklichkeit wird zu groß: Unternehmen fangen an zu glauben, Scrum sei für andere genau das Richtige, nicht aber für sie selbst.
Ich durfte als ScrumMaster und Coach einige Projekte über längere Zeit begleiten. Die Erwartungen, die dabei an meine Rolle herangetragen wurden, waren nie gleich. In manchen Projekten wurde vom ersten Tag an erwartet, dass ich Verantwortung für den Projekterfolg übernehme. In anderen sollte ich bereits bestehende Rollen und Verantwortungen in ihrer Arbeit unterstützen oder bestehende Prozesse optimieren.
Mein Selbstverständnis als Berater kann ich bei der ersten Art von Projekten (volle Verantwortung vom ersten Tag an) leichter ausüben. Denn ich kann mit Scrum von innen heraus arbeiten. Es geht dann in erster Linie um das Meistern von alltäglichen Herausforderungen und nur in zweiter Linie um Scrum. Anders gesagt: Ich kann dann einen bestehenden Prozess mitgestalten und im Zuge dessen an seiner Agilisierung arbeiten.
Und da ist er auch schon, der springende Punkt: Wenn der Beraterjob sich darauf begrenzen soll, Ratschläge, Empfehlungen und Anstöße zu erteilen, dann sind agile Coaches meist schlecht investiertes Geld. Lernen geschieht nur durch Vormachen. Ein guter Berater ist dazu da, vorzutanzen – und das heißt, die Arbeit so lange selber zu machen, wie es eben nötig ist. Ein einfaches Beispiel: Das Scrum-Team soll User Stories schreiben, weil das in Scrum eben so ist. Nun kann man dem Product Owner von Mike Cohn und den drei Fragen der User Story erzählen. Ein fleißiger Product Owner wird dann etwas daraus basteln und im nächsten Sprint Planning mit einem Stapel lustiger Sätze aufwarten.
Wir können aber auch ganz anders vorgehen: Warum nicht im Sprint Planning die klassischen Anforderungen durchgehen und dort, im Gespräch mit dem Team, eben diese drei Fragen stellen? Dann werden User Stories aus der Arbeit heraus, im Kontext ihrer Verwendung, entstehen. Die Puristen unter uns werden einwenden, dass Stories im Planning ja gar nicht geschrieben werden dürfen (Story Readiness!). Aber wie soll ein Scrum-Team darauf kommen, wenn es noch nie ein Backlog Grooming hatte? Auch hier ist es wichtig, die Besserwisserei im Schrank zu lassen und stattdessen dem Team ganz konkret aufzuzeigen, welches seiner Probleme ein solches Meeting lösen kann.
Dieser Umgang mit Scrum ist deflationär, denn er hält sich nicht mit großen Einführungen und Glaubenssätzen auf, sondern orientiert sich strikt am Bedarf der Personen und Gruppen im Unternehmen (und das nicht nur für die Scrum-Teams).
Wir Berater erzählen gerne von Scrum, weil wir uns damit am besten auskennen. Stattdessen sollten wir uns viel mehr mit dem auseinandersetzen, was nicht im Lehrbuch steht. Wir müssen besser verstehen, wie Unternehmen ticken, was ihre Produkte ausmacht, wo ihre Probleme sind, und was sie jetzt gerade brauchen. Nur dann haben wir eine Chance, Scrum als Rahmenwerk aufzuspannen, das im Unternehmen verankert ist. Ansonsten wird unsere Arbeit als Berater und/oder SMs sich auf das Verteilen von agilen Sahnehäubchen beschränken.

Der kleine Feigling oder wie sprachliche Musterunterbrechungen Veränderungen möglich machen

Wieso tun wir uns nur so schwer damit, eine für die Veränderung bereits getroffene Entscheidung auch tatsächlich umzusetzen? Eigentlich ist uns vollkommen klar, dass es uns danach besser gehen würde und trotzdem gehen wir den letzten, alles entscheidenden Schritt nicht. ScrumMaster sind Change Agents und gehen somit auf die ständige Suche nach kontinuierlicher Veränderung bzw. Verbesserung. Allerdings werden sie häufig mit einer schier unüberwindbaren Kraft konfrontiert, die alles tut, um Veränderung zu vermeiden: dem kleinen Feigling.
Mit der anstehenden Entscheidung in Richtung “Veränderung” (z.B. mehr Sport treiben, andere ausreden lassen, mehr delegieren statt alles selber machen, etc.) macht er sich eindrucksvoll bemerkbar und tritt in einen inneren Dialog mit uns. In diesem führt er einen bunten Blumenstrauß an Gründen auf, warum eine Veränderung nicht unbedingt sein muss, keinesfalls klappen kann oder zumindest der jetzige Zeitpunkt dafür vollkommen falsch ist. Als Meister der Aufschieberitis ist der kleine Feigling von Haus aus Pessimist mit wenig Bereitschaft zum Risiko. Meine Hypothese: der kleine Feigling – eine Mission Impossible für ScrumMaster?

Mit Musterunterbrechungen gegen den kleinen Feigling

Was tun, um den kleinen Feigling zu überlisten? Was tun gegen den inneren Schweinehund, gegen Stillstand, gegen die Angst, etwas Falsches zu tun? Sprachliche Musterunterbrechungen können Abhilfe leisten. Sie unterbrechen Routinen mittels Sprache und verwirren das Handlungskonzept des Empfängers, indem sie ihn mit neuen, unüblichen Perspektiven konfrontieren. Auf diese Weise werden mentale Freiräume geschaffen, die die Tür für andere Denkwege öffnen und so ungeahnte Ressourcen freisetzen. Ein wichtiger Hinweis: Sprachliche Musterunterbrechungen sind für seinen Konsumenten unkonventionell und provokativ, z.B. wenn unterstellt wird, man wäre ein hoffnungsloser Fall und unfähig für eine Veränderung. Ziel einer solchen Intervention ist, eine energiegeladene Haltung des Widerstands zu erzeugen, die zu einem radikalen Umdenken beiträgt. Provokationen verlangen jedoch vom Anwender (ScrumMaster) Fingerspitzengefühl (Wie weit kann ich gehen?). Ich möchte euch meine drei wirksamsten sprachlichen Musterunterbrechungen anbieten und einladen, sie auszuprobieren.

Das Muster meines Gesprächspartners ins Leere laufen lassen

Eine effektive Methode, um ein Handlungsmuster zu unterbrechen, ist das Schweigen. Euer Gegenüber trifft eine Aussage, die ihn in seinem aktuellen Problemmuster bestätigt. Zum Beispiel: “Ich bin jetzt 52 Jahre alt. In diesem Alter ändert man sich nicht mehr.” (Vermeidungsstrategie) Folgende Musterunterbrechungen sind in einem solchen Fall angemessen:

Jede dieser Musterunterbrechungen löst eine Reaktion aus und tut ihre Wirkung. Garantiert. Alleine die Tatsache, dass die Verunsicherung über euer Schweigen ihn dazu bewegt, seine Aussage zu rechtfertigen, unterstützt den Veränderungsprozess nachhaltig. Dann heißt es: dranbleiben!

Mit Beharrlichkeit dem Muster meines Gegenübers zustimmen

Zeigt eurem Gegenüber, dass ihr seine Sicht absolut verstehen könnt und bleibt dabei. Angenommen euer Gesprächspartner konfrontiert euch mit den Worten: “Bei anderen mag das mit dem Priorisieren funktionieren, aber in meinem Fall ist das einfach nicht möglich.” Was tun? Probiert es mit beharrlicher Zustimmung, zum Beispiel: “Ja, das sehe ich ganz genauso. Alle anderen bekommen es hin, nur bei dir ist es aussichtslos. Das hab ich schon gesehen, als du zur Tür rein gekommen bist”, ODER “Wäre ich an deiner Stelle, ich würde das Gleiche sagen.”

Verschlimmerungstaktik

Wenn ihr wirklich sicher gehen wollt, dass euer Gegenüber sein Muster (zumindest kurzfristig) unterbricht und den Negativstrudel verlässt, dann versucht euch an Verschlimmerungsfragen. Verschlimmerungsfragen suchen nach Antworten, was euer Gegenüber tun kann, um die für ihn bereits prekäre Situation noch weiter zu verschlimmern. Ein Teammitglied kommt zu euch und beschwert sich zum wiederholten Mal darüber, dass einer der Kollegen zu langsam ist. Mögliche Verschlimmerungsfragen wären: “Was kannst du tun, damit er/sie noch langsamer wird?”, ODER “Angenommen, wir würden einen Kurs über Langsamkeit bei ihm/ihr besuchen, was könnten wir dort lernen?”
Sprachliche Musterunterbrechungen stehen nie für sich alleine und sind ebenso wenig Patentrezepte, die eine Veränderung auf Knopfdruck erzielen. Sie dienen als unterstützendes Hilfsmittel, um routinierte, verkrustete oder eingespielte Denkrhythmen zu verlassen und ein anders Denken überhaupt zu mobilisieren und als Alternative anzunehmen. Es ist zu empfehlen, sie nicht inflationär einzusetzen, sondern mit Bedacht. Wenn ihr sie aber zum Einsatz bringt, dann tut es konsequent und mit Nachdruck, also glaubhaft. Nur dann könnt ihr damit rechnen, dass sie wirken.

Wir machen Scrum und wann werden wir agil?

Immer wieder gibt es neue Ideen und Ansätze, wie man Agilität erreichen kann. Die haben alle etwas für sich, ergänzen sich ideal und würden im Großen und Ganzen ein supergeiles agiles Unternehmen ergeben. Aber zu Beginn hinterlässt diese Themenbreite auch oft Verwirrung. Müssen wir alles davon machen, sollen wir keines davon machen, sind wir denn richtig agil, wenn wir was weglassen?
Eine Art Kampf der Methoden oder anders gesagt, “der Practices”, fängt damit an. “Tja, Scrum allein ist nicht genug, Kanban ist doch besser!”, ” Was ist mit Design Thinking?”, ” Lean IT Management?”, “Lean Product Development?”, ” Wasserfall hat doch seine guten Seiten?”, “Sollen wir wirklich Test Driven Development oder Pair Programmimg einführen?”, “Wir brauchen doch traditionelles Projektmanagement?”, “Und die Rolle des Managers?”, ” Es gibt doch keine einzelne Lösung, die Lösungsmethode ist doch hybrid, oder?”
Was mache ich mit diesem Blumenstrauß?
Aber was bedeutet Agilität eigentlich, was bedeutet “Scrum machen”?  Eigentlich ganz einfach: Ein einfacher Rahmen, kombiniert mit einer Sammlung von ausgewählten Best Practices, die zusammen die Art zu denken und zu arbeiten vollkommen verändert. Agil sein passiert erst dann, wenn ihr die Grundprinzipien und Werte von Scrum verinnerlicht habt.
Der Einfluss und die Auswirkung dieses Umdenkens ist schwer auf einen Teil der Organisation zu begrenzen, da unter anderen mit Scrum die Kommunikation insgesamt und vor allem die interdisziplinäre Kommunikation und Zusammenarbeit schnell alle Bereich der Organisation betreffen. Alle Individuen sind damit konfrontiert, ihre alten Denkmuster und Arbeitsweisen auf den Prüfstand zu stellen und sie werden die neuen Ansätze kritisch oder zumindest hinterfragend betrachten.

Wie werde ich wirklich agil im Kopf?

Der erste Schritt dazu, agil zu werden, ist agil zu handeln und herauszufinden, was heute zu einer Organisation passt. Genauso müsst ihr aber herausfinden, was erst morgen oder übermorgen passen wird.

So, wie wollen wir das rausfinden? Wie schon gesagt: tun! Es ist an dieser Stelle wichtig, folgende Punkte zu betrachten:
Scrum ist kein Selbstzweck
Wisst ihr überhaupt, warum und wofür das Ganze? Was bedeutet für euch Erfolg? Ist eure Organisation mehr mit den Kunden oder mit sich selbst beschäftigt (prozessgetrieben)? Sucht euch einen Teil eurer Organisation aus, in dem ihr mit agilen Vorgehensweisen anfangen wollen. Sucht euch einen Bereich, der übersichtlich ist, wo ihr grundlegende Rahmenbedingungen anbieten könnt – vor allem Ressourcen und die Unterstützung des Managements.
Leute befähigen
Um sich zu ändern, soll ein Mensch etwas Neues lernen. Ja, das Scrum-Rahmenwerk ist einfach, bedeutet aber trotzdem für viele Menschen eine große Veränderung. Zeigt eurer Mannschaft, dass ihr es ernst nehmt, schätzt diese Veränderung nicht gering und bietet jedem einzelnen Betroffenen (und damit AUCH dem involvierten Management!!) Trainings und Schulungen an.
Schutz und Rahmen schaffen
Lasst ein Team und einen ScrumMaster nie dabei allein, sich mit Scrum in der Organisation zurechtzufinden. Stellt Manager an ihre Seite, um die ersten Impediments aufzuräumen, den Rahmen klarzustellen und sie vor allem durch Kommunikation mit dem Rest des Unternehmens zu unterstützen. Informiert und involviert von Anfang an Personen in anderen Teams oder Abteilungen, die mit eurem Pilot-Team zu tun haben werden.
Zeit lassen
Sobald ihr klar gemacht habt, warum ihr euch für ein agiles Vorgehen entschieden habt (kürzere Releasezyklen, Kundenausrichtung, Time to Market, etc.): Lasst die Leute arbeiten! Lasst eure alten Berichtsformate links liegen und wagt euch an die neuen Artefakte wie Release Plan, Burndownchart oder Review Meeting.
Neue Wege, Änderung der Organisation und der Prozesse fordern
Jetzt kommen wir zurück zu unserem Blumenstrauß. Einmal gestartet, werden sowohl das Team als auch das Management identifizieren, welche Praktiken sie gerne versuchen würden bzw. werden sich basierend auf den priorisierten Problemen oder Herausforderungen ein paar agile Ansätze sofort als Lösungsansatz anbieten. So wie ein Team nicht über Nacht alle Best Practices anwenden kann und muss, wird auch die Organisation nicht alle Veränderungen durchführen können und müssen, um über Nacht agil zu sein. Der notwendige Lernprozess und Assessmentprozess kann nur inkrementell durchgeführt werden. Ein Schritt nach dem anderen. Das Motto: Versuchen und … lernen. Gemeinsam lernen, kontinuerlich lernen! Neu versuchen, anders versuchen, etc. Seid mutig und seid offen, neue Dinge zu probieren. Geht respektvoll miteinander um und setzt euch den gemeinsamen Anspruch, in kürzerer Zeit Qualität und Ergebnisse zu liefern und vor allem: euch aufeinander verlassen zu können.
Tja, dann fangen wir mal an, agil zu sein!

"Was ich weiß, macht mich heiß" oder worauf Change Manager schauen, hören, achten sollten

Im Umgang mit sozialen Systemen, wie z.B. Teams, ist das Geschehen komplex, oft unübersichtlich und schwer durchschaubar, gerade in Veränderungsprozessen. Herauszufinden, wo bei Problemen der Hase im Pfeffer liegt, was die Ursache und was das Symptom ist, erfordert von Change Managern Fingerspitzengefühl und die „richtige Brille“. Na ja, „richtig“ ist natürlich relativ, aber die „systemische Brille“ kann am ehesten Komplexität, Vernetzung und Wechselwirkungen in solchen Dynamiken gerecht werden. Im Sinne von Mehrperspektivität kann man im systemischen Ansatz auch von verschiedenen „Brillen“ sprechen, mit denen man soziale Systeme betrachten kann. Einfachstes Beispiel wären die „Detailbrille“ oder die “Überschaubrille“. Mit der ersteren schaue ich genau hin und suche Einzelheiten. Mit der zweiten trete ich zurück und schaue auf das Ganze. Es gibt noch einige weiterer dieser „Brillen“, die ich euch gerne vorstellen möchte und die in eurem Alltag der Teamarbeit hilfreich sein können.
Ressourcen
Gibt es zum Beispiel im Team Probleme, liegt es nahe, intensiv auf diese Probleme zu schauen, die Defizitbrille aufzusetzen und sich immer tiefer in die Problematik hineinzubegeben. Die „Depression“ der Betroffenen wird intensiver und die Probleme können sich noch verstärken.
Die systemische Prämisse, dass jedes soziale System grundsätzlich die Ressourcen hat, um sich weiterzuentwickeln und Schwierigkeiten aus eigener Kraft zu bewältigen, hilft positiv und lösungsfokussiert zu denken und zu handeln. Diese Ressourcenbrille macht Problemanalysen oft komplett überflüssig und spart externe „Expertenratschläge“, unnötige Verwerfungen und Zeit.
Ein Beispiel: Die Mitarbeiter eines Teams von lateralen Führungskräften (Teamkoordinatoren, ähnlich dem ScrumMaster) sahen sich in ihrer Wirksamkeit und Akzeptanz im Umgang mit den zugeordneten Mitarbeitern stark eingeschränkt, bis hin zur totalen Handlungsunfähigkeit. Die Stimmung war geprägt von Frust und Hilflosigkeit und man suchte die Ursachen im Kontext, bei der disziplinarischen Führung usw. Mit der banalen Frage: „Was haben wir konkret an Ressourcen, um uns als Team selbst zu helfen?“ und den daraus abgeleiteten, konkreten Maßnahmen, konnte – vor allem für die Beteiligten – überraschend schnell etwas in die richtige Richtung bewegt werden. Die „Ressourcenbrille“ hatte bisher noch niemand konsequent aufgesetzt.
Prozesse
Ein schönes Konzept oder ein detaillierter, langfristiger Plan ist doch immer wieder etwas Wunderbares. Nur dass in der Praxis überraschenderweise beides häufig nicht optimal funktioniert. Im Kleinen wie im Großen lassen Flughäfen und Philharmonien grüßen. Das Klagen ist groß, Schuldzuweisungen machen die Runde und die Ergebnisse sind in Frage gestellt. So hilfreich und notwendig Pläne und Konzepte auch sind, ergeben sie eben in der Regel noch keine Ergebnisse. Eher im Gegenteil: Meist geschieht zum Erstaunen der Beteiligten während des Umsetzungsprozesses noch ganz Wesentliches und Unerwartetes.
Die Prozessbrille registriert aufmerksam Informationen während der Umsetzung, hilft diese einzuordnen und ermöglicht so situative und konstruktive Modifikationen.
Wieder ein Beispiel: Nach einem 360-Grad-Feedbackprozess wurde mit externer Unterstützung ein Konzept für die Entwicklung von Führungsleitlinien und eine umfassende Schulung aller Führungskräfte der mittleren und unteren Ebenen entwickelt. Während der Schulungsmaßnahmen gab es von den Führungskräften immer wieder starke Widerstände und Signale, dass „etwas nicht in Ordnung“ sei. Ein gewünschter positiver Effekt für die Praxis war massiv in Frage gestellt. Mit der „Prozessbrille“ wurde erkannt, dass die mittlere und untere Führungsmannschaft einen eklatanten Mangel in der Realisierung der bereits seit Jahren bestehenden Unternehmensleitlinien wahrnahm. Diese Leitlinien wurden anscheinend von der Geschäftsführung und dem oberen Management nicht wirklich gelebt. Es fehlte also jeder Glaube an den Sinn von Leitlinien im Allgemeinen und Führungsleitsätzen im Besonderen. Das Konzept und der Prozess wurden daraufhin modifiziert. Die oberen Hierarchien ließen sich auf einen intensiven Kommunikationsprozess mit allen Führungsebenen ein, um einen konstruktiven Konsens zu finden.
Individuum
In der Praxis werden Schwierigkeiten oft individualisiert und dem Verhalten einzelner Mitarbeiter zugeordnet. Da wird jemandem schnell mal mit der Individualisierungsbrille mangelndes Sozialverhalten oder gar Teamunfähigkeit zugeschrieben. Im besten Fall wird noch versucht, über Individualmaßnahmen wie Coaching oder Training Abhilfe zu schaffen. Im schlimmsten Fall werden frustriert die Kooperation, der Teamgeist und Synergien aufgegeben. Hier bitte mal die Systembrille aufsetzen. Sie weitet den Blick für Zusammenhänge, Kontextvariablen und Wechselwirkungen.
In einer großen Abteilung mit drei Teams fiel besonders ein älterer Mitarbeiter immer wieder auf: Er kritisierte häufig die anderen, war bei Besprechungen ungeduldig und gab abwertend-aggressive Feedbacks. Alle waren mit ihrer Geduld mit ihm am Ende, er hatte es zum personifizierten Buhmann gebracht. Die Führung überlegte eine Versetzung, aber niemand im Umfeld wollte ihn haben. Die „Systembrille“ brachte ein Muster ans Tageslicht, das da hieß: „Immer wenn der Abteilungsleiter die Zügel schleifen lässt, keine Entscheidungen fällt, das Einhalten von Vereinbarungen nicht einfordert oder das Team blockiert ist, rastet der ältere Mitarbeiter aus.“ Er glaubt, stellvertretend die Führung übernehmen und für „Ordnung“ sorgen zu müssen. Dem Abteilungsleiter wird bewusst, dass er in diesem Kontext die entscheidenden Karten in der Hand hatte und dass eine Lösung eher bei ihm, als beim Mitarbeiter liegt. Die restlichen Kollegen haben eher mit Lethargie und Rückzug reagiert und somit auch ihren Anteil am Thema. Mit neuen Commitments und klarer Führung konnte sich der „Problembär“ mehr zurücknehmen und die Kommunikation im System entspannte sich sichtlich.
An diesem Beispiel lässt sich noch ein anderes wichtiges Thema festmachen. Vielleicht haben Menschen in Veränderungs- oder Problemsituationen die Stigmatisierungsbrille auf. Dem oder den anderen wird nur böse Absicht unterstellt, es wird davon ausgegangen, dass er nur seine Interessen vertritt oder andere bewusst beschädigen und/oder verletzten will. Sinnvoll ist es gerade bei stark individualisierten Zuschreibungen, mal die Brille der positiven Absichten aufzusetzen. Der systemische Change Manager geht von dem Glaubenssatz aus, dass jedes menschliche Verhalten (auch ein Problemverhalten) für den, der es zeigt, eine positive Absicht hat. Natürlich kann ein Verhalten auch bewusst negativ für andere adressiert sein. Aber die Frage nach der positiven Absicht führt tatsächlich oft zu neuen Wahrnehmungen, Perspektiven und Lösungsansätzen. Im obigen Beispiel wird deutlich, dass das Wahrnehmen der positiven Absicht des „Störers“ für sich ein geregeltes, stabiles Umfeld haben zu wollen, lösungsfokussierte Impulse sowohl für die Führung, als auch für die Kollegen und Kolleginnen auslöste. Selbsterkenntnis und Systemerkenntnis gingen sozusagen Hand in Hand zu neuen Ufern.
TIPP: Wer zur Brillenträgerin oder zum Brillenträger werden will, bekommt mit den Scrum Supplements den richtigen Durchblick!

Erste! Ein Interview mit Scrum ChangeManagerin Franzi Manko

Wer schon länger mit Scrum arbeitet, weiß: Für wirkliche Veränderungsarbeit reicht eine Zertifzierung zum ScrumMaster oder Product Owner nicht aus. Deshalb bietet bor!sgloger mit dem “Scrum ChangeManager” eine weiterführende Ausbildung an, in der gezielt an den persönlichen Fähigkeiten als Change Agent gearbeitet wird.
Franziska “Franzi” Manko hat als Erste diese Ausbildung abgeschlossen. Sie verantwortet bei der Software AG Tochter itCampus den Bereich Agile Software Development. In den vergangenen Jahren begleitete sie diverse Teams bei der Einführung agiler Methoden. Ihr Fokus liegt dabei auf der Arbeit mit national und international verteilten Teams sowie der kontinuierlichen Verbesserung.
Franzi, du bist die erste von bor!sgloger zertifizierte Scrum ChangeManagerin. Als dein Trainer bei Franzi Mankoden Scrum Supplements freut es mich sehr, dass du dir die Zeit für ein Interview genommen hast. Wie war das für dich denn so, als das Zertifikat in Leipzig angekommen ist?
Angekommen ist es ausgerechnet während meines Urlaubs, aber ich hatte ja schon die Ankündigung von dir per Mail. Natürlich war die Freude groß, als ich es nach der Rückkehr ins Büro endlich in Händen halten konnte. Was mich besonders gefreut hat: Auf dem Zertifikat ist aufgelistet, welche Kurse ich gemacht habe und was ich dabei gelernt habe. So kann jeder den Wert meines erworbenen Wissens nachvollziehen.
Was hat dich denn gereizt, diese Ausbildung zu machen?
Zum einen habe ich euer Angebot genutzt, weil das doch ein Stück mehr ist, als „nur“ ScrumMaster oder Product Owner zu sein. Wenn man in einer dieser Funktionen eine Zeitlang gearbeitet hat, denkt man sich doch irgendwann: „Jetzt möchte ich eigentlich noch mehr erfahren, ein paar weiterführende Kurse machen und mich über bestimmte Themen auch mit anderen austauschen.“ Man stößt ja immer wieder auf die Aussage, dass Scrum das Unternehmen verändert und gerade als ScrumMaster muss man das begleiten. Daher fand ich es schön, dass es diese Ausbildung am Markt gibt und dass man sich dazu auch trauen muss, jemanden um eine Referenz zu bitten. Das Feedback, wie ein anderer die von mir geleistete Arbeit sieht, war mir wichtig.
Der von bor!sgloger zertifizierte Scrum ChangeManager ist ja als Angebot neu am Markt. Wo siehst du denn für dich persönlich den besonderen Wert der Ausbildung?
Die Kurse waren für mich sehr gut, weil ich mal über den Tellerrand blicken und die Inhalte gleich in der Praxis anwenden konnte. Dann auch noch einmal mit der Zertifizierung bestätigt zu bekommen, dass ich mich mit dem Thema auseinandergesetzt habe, war für mich wichtig. Es ist wie gesagt auch ein wichtiges Signal für ein Unternehmen, dass es sich bei der Einführung von Scrum um einen Veränderungsprozess handelt, der begleitet werden muss – und zwar nicht von jemandem X-Beliebigen, sondern von jemandem, der das passende Wissen hat.
Da höre ich schon raus, dass du in zweierlei Hinsicht davon profitiert hast: Zum einen für deine persönliche Weiterentwicklung, aber du siehst auch Karrierechancen durch mehr Know-how, das du nun anbieten und einsetzen kannst.
Genau, Karrierechancen für mich selbst, aber auch ein Unternehmen hat damit einen gewissen Grad an Sicherheit.
Es gibt mittlerweile sechs Bausteine, die Scrum Supplements, aus denen man auswählen kann. Welche hast du gewählt?
Ich habe zuerst den Impediment Blaster gewählt, der hervorragend die Herausforderungen des Changes behandelt. Dann habe ich noch zwei gewählt, die für den ScrumMaster als persönliche Werkzeuge sehr wichtig sind: Das Training zur Diskussionsführung (Discussion plus), bei dem man das Verhandeln und sich Durchsetzen in der Kommunikation lernt. Und dann habe ich mich noch für „Ich-Power“ entschieden. Dabei habe ich gelernt, wie ich mit schwierigen Situationen umgehen kann und das war für mich persönlich wirklich sehr wertvoll.
Konntest du das in deiner Praxis schnell nutzen? Haben auch andere in deinem Umfeld wahrgenommen, dass du an dir arbeitest?
Gerade die letzten beiden Kurse haben eine große Veränderung bewirkt. Wir haben in den Trainings wirklich auf die einzelne Person zugeschnittene Lösungen erarbeitet und das konnte ich tatsächlich am nächsten Tag sofort umsetzen. Auch für meine Kollegen und mein Team war das durchaus wahrnehmbar. Selbst heute, wo die Kurse schon etwas her sind, blicke ich immer wieder zurück um mir wieder neue Impulse aus meinen Mitschriften oder den Materialien zum Training zu holen.
Welche Tipps und Argumente kannst du Menschen geben, die sich für diese Ausbildung interessieren und sie ihren Chefs schmackhaft machen wollen?
Da muss ich mal überlegen, welche Argumente ich angebracht habe! Aber ich würde sagen, alle Themen wirken sich nicht nur auf die eigene persönliche Weiterentwicklung aus, sondern schlagen sich umgehend in der Arbeit eines ScrumMasters oder Product Owners nieder. Gerade wenn ich mir den Product Owner ansehe, der oft viele unterschiedliche und miteinander konkurrierende Meinungen managen muss – da ist es wichtig zu wissen, wie kann ich gut verhandeln, wie kann ich mich durchsetzen, wann muss ich mich durchsetzen? Ich denke, dass jedes Unternehmen nur profitieren kann, wenn es Mitarbeiter hat, die genau wissen, wie man zur einer Lösung kommt.
Kannst du zum Abschluss in einigen Schlagworten zusammenfassen, wie du die Scrum Supplements erlebt hast?
Sie waren allesamt sehr praxisbezogen. Ich konnte meine Themen einbringen und mit Lösungen für den Alltag nachhause gehen. Jeder Kurs war sehr persönlich. Sowohl vom Trainer als auch von der Gruppe habe ich mich jedes Mal sehr gut aufgehoben gefühlt, sodass ich mich wirklich darauf einlassen konnte. Das ist auch ein Tipp, den ich jedem Interessenten mitgeben möchte: Sich wirklich darauf einlassen und sich für das öffnen, was da kommt. Dann nimmt man noch viel mehr mit!
Danke, Franzi!
TIPP: Jede Teilnehmerin und jeder Teilnehmer der Scrum Supplements geht mit Lösungen für persönliche Fragen der Selbstführung und Führung von Teams nachhause. Daher ist die Gruppengröße beschränkt – so bekommen alle die angemessene Zeit für ihre individuellen Themen.
Einen Überblick über alle Inhalte und Termine findest du unter diesem Link.

Whatever people say I am – that's what I'm not

Menschen positiv zu ent-täuschen – gibt es ein schöneres Gefühl? Unzählige Studien wollen uns weismachen, dass wir unser Urteil über andere Menschen in wenigen Sekunden bilden. Hier der Schöngeist, dort der Kämpfer, drüben der Diplomat. Über die Monate und Jahre schleifen sich diese Bilder ein – und am Ende glauben wir selber daran. Das Ergebnis: Unser Selbstbild setzt sich zunehmend aus Negativität zusammen. Wir sind das, was wir nicht sind.
Ich habe einen Bekannten, der im Umgang mit Gruppen eine Energie an den Tag legt, die ich gerne hätte. Er wittert jede Spannungslage und macht sie sofort zum Chefthema. Er bleibt so lange dran, bohrt mit Fragen und Argumenten so lange nach, bis alle der Sache auf den Grund gekommen sind und der Weg für eine Lösung freigeschaufelt ist.  Für ihn ist diese Stärke aber zugleich seine Schwäche: Er klagt über geringe Schriftbegabung und reagiert auf die dokumentarischen Anforderungen, die sein Job mit sich bringt, mit Überforderungssymptomen. Mir ist es bisweilen genau umgekehrt gegangen: Ich habe keine Schwierigkeiten beim treffsicheren Formulieren und das Schreiben hat mir schon immer Spaß gemacht. Zum Teil ist das simple Konditionierung gewesen: An der Hochschule waren eben genau diese Fähigkeiten Faktoren, die mich erfolgreich gemacht haben.
Als ich vor zweieinhalb Jahren bei bor!sgloger anfing, hing mein Erfolg von einem Tag auf den anderen von Fähigkeiten ab, die ich mir selber vorher gar nicht zugetraut hätte. Die Veränderungen, die ich in dieser Zeit durchgemacht habe, sind weder selbstverständlich gewesen oder irgendwie von selber passiert. Es war ein langsames Herantasten und Rückversichern, geprägt von vielen, teils widersprüchlichen Gefühlslagen.
Umso großartiger war das nach einiger Zeit einsetzende Gefühl, dass ich die für diesen knallharten Job erforderlichen Ressourcen tatsächlich besitze. Mit dieser Erkenntnis in der Tasche kann ich mein Selbstbild um Facetten ergänzen, die jedes Schubladendenken in Grund und Boden widerlegen.
Eine Übung zum Schluss: Erica Ariel Fox von der Harvard Law School nutzt das Bild des inneren Teams, um vier große Rollen zu beschreiben, die in jedem von uns wirksam sind:

Anstatt zwischen dieser vier Rollen auszuwählen, geht es vielmehr darum, ihre Phänomenologie in uns zu durchleuchten. Dazu schlägt die Autorin folgende Fragen vor:

Literatur
Erica Ariel Fox. The Most Important Negotiation in Your Life. HBR Blog Network:
Friedemann Schulz von Thun 1998: Miteinander reden 3 – Das ‘innere Team’ und situationsgerechte Kommunikation. Rowohlt, Reinbek.

Komfort-, Stress- und Panikzone im Change Prozess

Auch der liebe Voltaire hat es bereits im 18. Jahrhundert geahnt … oder sogar gewusst? Veränderungen rufen Stressreaktionen in Menschen hervor – und das sowohl im positiven als auch im negativen Sinne!
Warum das?
Stellt euch vor, wir würden jeden Tag eine neue Wohnung beziehen, einen neuen Job beginnen, ein neues Team führen, neue Rollen im Scrum bekleiden, einen neuen Partner bzw. eine neue Partnerin an unserer Seite haben … Wäre das nicht grausam? Für mich allerdings! Denn ich bin ein Mensch, der sich auch gerne mal für eine Zeit lang (wenn auch für kurze Zeit) in der eigenen Komfortzone bewegt.
Komfortzone? Ufff, wieder ein Fremdwort … oder doch nicht?
Komfortzone ist derjenige Bereich, in dem wir uns wohlfühlen, in dem es keine neuen Herausforderungen gibt bzw. in dem unsere täglichen Abläufe genau bekannt sind. In dieser Zone gibt es keine persönliche Weiterentwicklung, hier findet kein Lernen statt – da wir uns in einem Umfeld befinden, das uns schlicht und ergreifend bekannt ist. Und das gilt für uns alle!
Wenn wir neue Herausforderungen angehen, und in einem Change Prozess gibt es davon eine ganze Menge, treten wir automatisch aus unserer Komfortzone in die sog. Stresszone (auch Lernzone genannt) hinein. Erst dort beginnt das im Change Prozess notwendige Lernen. D. h. Lernen geschieht außerhalb der Komfortzone – und das in unterschiedlichen Phasen und unterschiedlichen Geschwindigkeiten: von der unbewussten Inkompetenz bis zur unbewussten Kompetenz.
So macht Change Spaß!

Inseln der Agilität

Weh mir, wo nehm’ ich, wenn
Es Winter ist, die Blumen, und wo
Den Sonnenschein,
Und Schatten der Erde?
Die Mauern stehn
Sprachlos und kalt, im Winde
Klirren die Fahnen.
Friedrich Hölderlin (Hälfte des Lebens)
„Es gibt kein richtiges Leben im falschen.” Theodor W. Adorno hat damit die moralphilosophische Frage aufgeworfen, ob ein gutes Leben in einer Welt voller Ungerechtigkeit möglich ist.
Im Berufsleben lässt sich die Frage ebenso stellen: Ist ein guter, erfüllender Job in einem schwierigen, frustrierenden Unternehmensumfeld möglich? Menschen reagieren unterschiedlich, wenn sie spüren, dass sie sich in ihrem Job nicht entfalten können. Manche überfallen Selbstzweifel und Angst, andere gehen in den Widerstand bis hin zur Kündigung. Wiederum andere versuchen, sich mit den Verhältnissen zu arrangieren und eine halbwegs komfortable Nische zu finden, in der sie möglichst unbehelligt weitermachen können. Das ist dann so, wie wenn man im Regen unter einem Vorsprung Schutz sucht: Man wird nicht nass, aber wirklich schön ist es dort auch nicht.
In agilen Implementationen gibt es einen anderen Weg. Er läuft auf die Schaffung eines Mikrosystems mit eigener Anatomie hinaus. Dieses Mikrosystem nennen wir Scrum-Team. Indem wir ein Scrum-Team aufsetzen, schaffen wir für seine Mitglieder eine Heimat mit eigenen Werten und Regeln. Indem wir dem Team nach und nach die Verantwortung zur Produktgestaltung übertragen, schaffen wir darüber hinaus eine Arbeitsumgebung mit eigener Taktung.
Beides – Wertesystem und Taktung – sind zunächst nichts anderes als ferne Versprechen. Mitarbeiter, die es gewohnt sind, ihre Verantwortung entlang der Wertschöpfungskette nur punktuell oder diffus wahrzunehmen, stehen dem Versprechen häufig skeptisch gegenüber. Sie sehen im Großsystem Unternehmen alle Ursachen für ihre Unzufriedenheit – und müssen deshalb erst gar nicht anfangen, über ihre eigenen Handlungsfreiheiten zu reflektieren.
Bei der Errichtung eines solchen Mikrosystems hilft eine Führungskraft, die sich einerseits schützend vor das Team stellt, es andererseits aus der Komfortzone locken kann. Wir nennen sie ScrumMaster. Dann passiert etwas Spannnendes: Das Team fängt an, sich aus dem Schneckenhaus heraus zu tasten. Es beginnt zu spüren, dass nicht alles Übel fremdverschuldet ist. Und es bemerkt, dass es mit etwas Kreativität und Elan viel mehr leisten kann, als es sich bisher zugetraut hat.
Die ersten Früchte des Erfolges zeigen sich, wenn das Team anfängt, seine Frustration und Resignation in eine gewisse Unbekümmertheit und Leichtigkeit zu verwandeln. Frei nach dem Motto: Wenn keiner die entscheidenden Fragen stellen kann, dann tun wir das halt selber. Von dort an ist es nicht mehr weit, bis das Team damit beginnt, Entscheidungen selber zu treffen. Und eh‘ man sich versehen hat, ist sie da: Die Insel der Agilität. Zart und zerbrechlich, aber da.
Es gibt es also doch, das „richtige“ Leben im „falschen“. Das Sprint Review ist übrigens das Meeting par excellence, in dem das Großsystem Unternehmen den Gesinnungswandel innerhalb des Scrum-Teams registriert und auch zu schätzen versteht. Was dann folgt, ist ein Geben und Nehmen: Das Scrum-Team fordert heraus – und das Unternehmen lernt, damit umzugehen.
Tipp zum Abschluss: Lass dein Team auf einer Skala von 0-10 positionieren. Die Null bedeutet: Ich habe in meinem Unternehmen gar keine Freiheiten, selber zu entscheiden. Die zehn: Ich habe alle Freiheiten der Welt, selber zu entscheiden. Lass jeden kurz erzählen, warum er dort steht, wo er steht. Und bitte jeden dann, sich eine Maßnahmen zu überlegen, die er sofort umsetzen könnte, um auf der Skala um eine Zahl aufzurücken. Bilde dabei Gesprächspartner, die möglichst unterschiedlich auf der Skala stehen (also z.B. ein „Dreier“ mit einer „Siebener“). Lass die Maßnahmen aufschreiben und jedes Paar innerhalb von 72 Stunden berichten, wie es die Maßnahme umgesetzt hat und was es dabei beobachtet hat.
Theodor W. Adorno (1969): Minima Moralia. Suhrkamp Verlag, Frankfurt am Main.

Scrum Logbuch-Eintrag: Wenn sich Scrum und Change die Hand reichen

Mein lieber Freund, die letzen zwei Wochen hatten es in sich! Zunächst eine sehr lange Reise vom sonnigen Graz ins regnerische Oldenburg, dann eine etwas kürzere Reise nach Baden-Baden, gefolgt von einer viel kürzeren Reise zurück nach Wien. Aber dann! Dann wieder eine gefühlte Weltreise ans Ziel: back to Graz.
Da sitze ich nun hier und mache eine kurze Retro über meine Erlebnisse als Coach, ScrumMaster und Kollegin. Ich sage dir, liebes Logbuch, ich habe viel gesehen und noch mehr erlebt.

Aber: heute werde ich „nur“ einen Eintrag über ein Thema schreiben, das mich in den letzen zwei Wochen wiederholt begleitet hat: Change!
Geschafft! Die Entscheidung ist getroffen: Scrum wird weiter und breiter eingeführt, erste Teams sind gebildet, Product Owner und Development Team wissen was zu tun ist, erste Sprints sind bereits im Laufen begriffen. Alles prima also! Zumindest fast.
Denn nun erfährt das Team, dass alles anders wird: alles wird transparenter (auch ihre eigene Tätigkeit), viele Veränderungen stehen an und noch das Wichtigste: die Entscheidungen liegen direkt bei ihnen. “Juhuuuu!”, würde sich manch einer denken. Aber falsch – ich wurde eines Besseren belehrt. Angst, Widerstände, Aggressionen und Konflikte begegneten mir auf dem Weg.
Veränderungsprozesse versetzen Menschen in Ausnahmezustand. Warum? Weil unsere menschliche Natur nun mal so ist: entwicklungsgeschichtlich und evolutionsbedingt reagieren Menschen auf Veränderungen erst einmal defensiv und abwehrend. Jede noch so geringe Veränderung verursacht „archaische“ Notfallprogramme in uns: Kampf, Erstarrung oder Flucht. Dies bedeutet, dass die Situation zunächst auf ihre Bedrohlichkeit überprüft wird. Für unsere Vorfahren (die in Höhlen lebten) hatte diese Überprüfung die höchste Priorität, da dadurch ihr eigenes Überleben gesichert werden konnte. War es damals der Säbelzahntiger, von dem sich unsere Vorfahren schützen mussten, sind es heute weniger die wilden Tiere als die Veränderungen im sozialen und beruflichen Umfeld, von denen wir uns zu schützen versuchen.
Globalisierung, permanente Veränderungen in Unternehmen und auf Märkten, erhöhter Stresslevel, Rollenambiguitäten, Druck o.ä. sind die wilden Tiere des 21. Jahrhunderts. Die Folge: emotionale Spannungszustände! Experten sind sich mittlerweile einig, dass es neben den organisationalen Veränderungsprozessen noch einen weiteren Prozess geben muss, der die Emotionen der am Change Prozess beteiligten Personen berücksichtigt und den Umgang mit ihnen trainiert.
Wie das?!
Nun ja, nach Streich (1997) durchlaufen wir, bewusst oder unbewusst, verschiedene Reaktionsphasen im Change Prozess.
Phase 1: Schock
Hier trifft die Erwartung auf die Realität, d. h. Scrum macht alles anders! Neeeein, nicht möglich! Angst breitet sich aus und man ist sich der eigenen persönlichen Kompetenz nicht mehr sicher. Dieser Schock muss zunächst emotional und kognitiv verarbeitet werden. In dieser Phase erfahren wir große Unsicherheit und Dauerblockade.
Phase 2: Verneinung/Abwehr/Widerstand
Die Folgen der Veränderung sind für Teams und Unternehmen nicht abschätzbar, nicht greifbar. Die Kontrolle entzieht sich jedem Beteiligten, was noch mehr Angst, Widerstand und Reaktionen zum Selbstschutz auslöst. Dieser Prozess wird auch „Trauer- und Ablöseprozess“ genannt.
Phase 3: Einsicht/Neugier
Wir Menschen sind „Gewohnheitstiere“, d. h. nach einer bestimmten Zeit gewöhnen wir uns an Veränderungen und erkennen den SINN dahinter. Alte Gewohnheiten weichen plötzlich den Neuen.
Phase 4: Akzeptanz
Wenn der SINN verstanden und die Notwendigkeit der Veränderung erkannt wurde, lassen wir alte Verhaltens- und Verfahrensmuster los und akzeptieren den neuen Zustand.
Phase 5: Ausprobieren
Erste konkrete Maßnahmen werden ausprobiert, Fehler und Erfolge reihen sich aneinander. Hier sind wir nun mitten im Scrum angelangt. Denn Scrum ist der „Weg des Versuchens, des Scheiterns, des Wiederaufstehens und des Erfolgreichseins“, schreibt Boris Gloger in seinem Buch über Scrum. Und Recht hat er – so recht!
Phase 6: Erkenntnis
Aus Erfolgen und Misserfolgen wird gelernt. Je mehr positive Erfahrungen gemacht werden, desto größer ist das Verständnis gegenüber Veränderungen. Hier erreicht das Sprichwort „Nichts ist in Stein gemeißelt“ eine neue Dimension: Lass dich vom Scrum-Regelwerk inspirieren, kreiere aber mittels gesundem Menschenverstand deinen eigenen Arbeitsprozess.
Phase 7: Integration/Akzeptanz
Scrum ist akzeptiert, eingeführt, wird gelebt und ist somit im Handlungsrepertoire integriert.
Zu bedenken ist aber, dass es nicht nur Change-Verweigerer gibt, sondern auch Menschen, die der Veränderung sehr positiv gegenüberstehen. Emotionale Spannungszustände haben u. a. auch etwas mit Stressreaktionen im Körper zu tun. Da es aber nicht nur den negativen Stress, Disstress, sondern auch den positiven Stress, Eu-Stress, gibt, der uns zu Höchstleistungen antreibt, erleben diese Menschen andere körperliche Reaktionen auf der kognitiven, emotionalen und vegetativ-hormonellen Ebene als diejenigen, die eher in die Disstress-Zone geraten. Somit kann ein Change Prozess auch sehr anregend und motivierend sein!
So, jetzt wissen wir es!
Und ich habe es auch erfahren. In Teams und Unternehmen, mit denen ich in den letzten zwei Wochen zu tun hatte; bei Product Ownern, Managern und Kollegen, denen ich auf meinem Weg begegnete. Und stell dir vor: Jeder von ihnen hat sich dabei in einer anderen Phase befunden.
Die Erkenntnis ist heftig, nicht wahr!!?
Eine gute Nachricht gibt es dabei: Wenn wir nun um die Phasen und unsere Überlebensreaktionen wissen und verstehen, was der Mix daraus in uns anstellt, dann sind wir auf dem besten Weg, die Menschen im Change Prozess (so wie Scrum einer ist) konstruktiv, effektiv und effizient zu begleiten.
P.s.
Liebes Logbuch und alle, die es lesen werden: Glaubt mir, die Erkenntnis war wirklich heftig, aber auch sehr hilfreich im Umgang mit meinem eigenen Change Prozess – als ScrumMaster, als „nicht-disziplinarische Führung“ sowie bei der Erkenntnis, warum wir einen zweiten Prozess brauchen: den der emotionalen Steuerung.

ScrumMaster aufgepasst! Wie Veränderung mit Popcorn funktionieren kann

Scrum bringt Veränderung. Das steht fest. Um Veränderung allerdings wirksam zu machen, muss man sich als ScrumMaster der Herausforderung stellen, wie man Menschen dazu bringen kann, sich zukünftig anders als bisher zu verhalten.
Dabei wird ein solches Unterfangen nicht leichter, wenn man bedenkt, dass es sich fast immer um die Änderung von Verhaltenskonzepten dreht, die automatisiert sind: Sie haben sich in der Vergangenheit bewährt, waren bis zu diesem Zeitpunkt – zumindest subjektiv für den Betroffenen – erfolgreich und sind damit im Handlungskonzept fest verankert. Man muss also mit Widerstand rechnen, weil Widerstand eine normale menschliche Reaktion auf Veränderungen ist. Dabei ist zweitrangig, ob die Mitarbeiter Widerstand gegen die Veränderung an sich leisten oder gegen die Art und Weise, wie der Veränderungsprozess gestaltet wird.
Wie kann es also einem ScrumMaster gelingen, dass die Menschen, auf die er in der Erfüllung seiner Verantwortung (z.B. in seinem Team, in der Organisation) Einfluss nehmen möchte, Veränderungen akzeptieren, diese für sinnvoll erachten und ihr Handeln danach (neu) ausrichten? Vielleicht ist die nachfolgende Antwort auf diese Frage nicht allgemein gültig oder auf jedes Veränderungsszenario übertragbar. Sie ist aber zumindest ein mögliches Lösungskonzept und somit eine versuchsreife Option, eine Probierpackung ohne doppelten Boden. Ich möchte sie euch gerne unter Anführung einer in den Staaten durchgeführten Studie nahe bringen.

Popcorn für alle

Vor ein paar Jahren kam der Actionfilm Zahltag mit Mel Gibson in die amerikanischen Kinos. In einem Vorstadtkino in Chicago spendierte man den Besuchern dieser Vorstellung ein alkoholfreies Getränk ihrer Wahl und einen Eimer Popcorn, wenn sie als Gegenleistung nach dem Film Fragen zur Qualität des Süßwarenstands beantworteten. Die Sache hatte allerdings einen (bewusst gewählten) Haken: Das Gratis-Popcorn war bereits vor fünf Tage gemacht worden und schmeckte entsprechend. Ein Zuschauer verglich das Popcorn mit Styropor, zwei andere hatten sogar vergessen, dass das Knabberzeug gratis war und wollten ihr Geld zurück. Und trotzdem aßen die meisten während des Films, “schoben die Packung weg, nahmen sie einige Minuten später erneut in die Hand, um sich Nachschub zu holen, stellten sie noch einmal weg, griffen nach einer Weile wieder hinein und so weiter und so fort.” (Wansink, 2008, S. 22) Noch wichtig zu erwähnen ist, dass die Kinofans nicht wussten, dass sie Teil einer Studie über irrationales Essverhalten waren. Eine Hälfte der 158 Probanden erhielt das Popcorn in einem mittelgroßen Eimer, die andere bekam einen richtig großen Eimer. Die Frage, die die Studie zu beantworten suchte, lautete:

Essen die Leute mit den größeren Eimern mehr Popcorn?

 
Die Studie sah vor, die Popcorneimer vor und nach dem Film zu wiegen, um auf diesem Wege eine valide Aussage darüber treffen zu können, wie viel Popcorn jede Person gegessen hatte. (Anmerkung: Bevor du weiterliest, schreib bitte auf einen Zettel auf, was deines Erachtens das Ergebnis dieser Studie war und finde Argumente für deine Entscheidung).

Popcorn-Vielfraße 

Das Ergebnis war tatsächlich erstaunlich und wirft ein vollkommen anderes Licht auf die Bewertung von Problemursachen und damit auf die Optionen, wo man nach Lösungen suchen sollte:
Die Probanden mit den größeren Eimern aßen 53 Prozent mehr Popcorn, als die mit den mittelgroßen Eimern. Sie nahmen folglich 173 Kalorien mehr zu sich und griffen rund 21-mal öfter in den Eimer” (Heath & Heath, 2010, S. 10).
Decken sich deine Ergebnisse mit den Ergebnissen der Studie? Angenommen, ich hätte euch zwar die Ergebnisse der Studie gezeigt, also wie viel die einzelnen Personen gegessen haben, hätte die Größen der Eimer und die damit einhergehende Wirkung auf das Essverhalten aber unerwähnt gelassen. Ihr könntet aus der Studie so lediglich ableiten, dass es einige Menschen gibt, die weniger Popcorn konsumiert haben, andere, die mehr gegessen und wiederum andere, die ziemlich viel Popcorn zu sich genommen haben. Darüber hinaus hättet ihr voreilig den Schluss gezogen, dass die letztgenannten echte Popcorn-Vielfraße sind. Hätte ich euch nun um die Sammlung von Ideen gebeten, wie man das Essverhalten (vor allem) der Vielfraße ändern kann, hättet ihr euch in der Lösungssuche wahrscheinlich auf Veränderungswege konzentriert, die der Frage auf den Grund gehen, welche Gesundheitsrisiken es mit sich bringt, so viel Popcorn zu essen.
Mit dem Wissen der unterschiedlichen Eimergrößen klingt die Lösung für das zu verändernde Problem „Essverhalten“ fast schon zu einfach: Nimm kleinere Eimer! In puncto Veränderungschance ist diese Lösung für mich die eigentliche Erkenntnis der Studie: „Was wie ein Problem aussieht, das den oder die Menschen betrifft, ist oft ein Situationsproblem“ (Heath & Heath, 2010, S. 27).
Und jetzt liegt es an euch, liebe ScrumMaster: Was sind die kleineren Eimer in eurem Scrum-Team? Erzählt mir davon.
 
Literatur
Heath, C. & Heath, D. (2010). Switch. Veränderungen wagen und dadurch gewinnen. Fischer
Wansink, B. (2008). Essen ohne Sinn und Verstand. Wie die Lebensmittelindustrie uns manipuliert.

Agile Take-off

Sehr geehrte Damen und Herren! Wir begrüßen Sie auf dem Flug von Graz nach Düsseldorf. Bitte schnallen Sie sich an, stellen Sie Ihre Sitzlehne aufrecht und klappen Sie Ihre…
Da saß ich nun im Flugzeug und hörte mit einem Ohr die Durchsage der Flugbeleiterin. Neben mir ein Herr, Mitte 60, graumelierte Haare, perfekt sitzender Anzug. Seine Augen auf mein Buch gerichtet. Auf das kleine Agile-Buch von Sander Hoogendoorn. Da wurde es mir ein wenig bunt und ich erwiderte seinen Blick. Plötzlich sagte mein Sitznachbar zu mir: „Entschuldigen Sie, aber ich „missbrauche“ Sie, um in Ihrem interessanten Buch zu lesen. Was bedeutet agile oder besser gesagt, wie können Projekte agil werden?“
So starteten wir agil in Richtung Düsseldorf … und in ein Gespräch über Scrum und Wasserfall, über Iterationen und Releases, über Change Management und Komfortzonen. „Alles schön und gut in der Theorie“, meinte er. „Wären da nicht die Menschen mit all ihren Befindlichkeiten.“ Da horchte ich plötzlich auf und es machte „klick“ in meinem Kopf. Natürlich! Recht hat er! So recht!
Denn: was ist Scrum? Ein Steuerungsinstrument? Ein Change-Management-Ansatz? Eine Einstellung? Die innere Haltung? Agil?
Ja, alles.
Wenn das alles auf Scrum zutrifft, was tut diese geballte Ladung an Veränderung dann mit uns?
Können wir davon ausgehen, dass unsere Teams, ScrumMaster, Product Owner, Manager oder sonstige Stakeholder einfach schwupsdiwups anfangen agil zu denken, Veränderungen ohne Hindernisse  akzeptieren und zur agilen Tagesordnung übergehen?
Nein! Meine ich.
Seit geraumer Zeit wird zu Projektbeginn das bestmögliche Team von Entwicklern, Fachexperten und Testern zusammengestellt. Nach Abschluss des Projektes werden die Teammitglieder wieder getrennt und in neuen Projekten (oft mit neuen Teammitgliedern) eingesetzt. Das Prinzip geht von den besten verfügbaren Einzelpersonen aus, aber nicht von den besten verfügbaren Teams. In vielen Projekten dauert es leider sehr lange, bis diese Einzelpersonen zu einem effizienten und produktiven Team werden. Da muss ich Sander Hoogendoorn Recht geben. Aber warum ist das so?
Weil es in Projekten eben menschelt. Erst recht, wenn wir von Wasserfall auf agil wechseln. Weil Veränderungsprozesse Menschen in Ausnahmezustand versetzen. Weil die Veränderung einer Einstellung oder die Weiterentwicklung der inneren Haltung Zeit brauchen. Zeit, um Ängste zu überwinden und Zeit, um den Nutzen zu erkennen. Vor allem den Nutzen für sich selbst.
Sozialpsychologisch betrachtet sind Menschen „bilanzierende Wesen, die Veränderung als kognitive und emotionale Unsicherheiten erleben. Emotionen wirken dabei wie Vergrößerungsgläser. Change Prozesse sind hochemotional und verursachen somit emotionale Spannungszustände. Und was machen die emotionalen Spannungszustände mit uns? Sie hindern uns daran, den gesunden Menschenverstand einzuschalten, effizient zu arbeiten, gewaltfrei und lösungsorientiert zu kommunizieren, Konflikte zu vermeiden oder schicke Codes zu schreiben.
Wenn wir also davon ausgehen, dass Change Prozesse emotionale Spannungszustände in uns verursachen, können wir dann gleich zu Beginn des Projektes von erfolgreichen Sprints ausgehen bzw. dürfen wir uns dann wundern, wenn diese eben nicht erfolgreich werden? Was wäre dann die logische Konsequenz daraus? Denken wir mal bewusst darüber nach…
So diskutierte ich mit meinem interessanten Sitznachbarn, als wir die Durchsage unserer Flugbegleiterin mit einem Ohr wahrnahmen: “Wir befinden uns im Landeanflug auf Düsseldorf. Legen Sie bitte Ihre Sicherheitsgurte an, stellen Sie Ihre Sitzlehnen aufrecht und schalten Sie Ihre elektronischen Geräte aus.”
Und mein agiles Landing war perfekt!

ScrumMaster, Product Owner, Scrum ChangeManager – neue Rollen brauchen Profil und Kompetenz

Eines der faszinierendsten Elemente von Scrum als Modell ist die Tatsache, dass hier neue, innovative Rollen im beruflichen Kontext kreiert werden und klassischen Rollen prägnantere Funktionen (z.B. dem Manager) zugeordnet sind. Die Funktionen von ScrumMaster und Product Owner sind in der Projektwelt ohne Beispiel. Daher ist das  Verständnis über ihre Aufgaben und Instrumente mitunter noch diffus und schwer einzuordnen. Was genau sind ihre Wirkungsfelder, was sind die dazugehörigen Kompetenzen, welche Methoden und Techniken stehen zur Verfügung, was sind die Einflussbereiche, was genau ihre Aufgaben und Funktionen, etc.? Und wie grenzen sie sich zu anderen Rollen wie Team- oder Projektleiter ab?

Rollen müssen sich legitimieren

In sozialen Systemen sind Rollen zentrale Elemente, denen spezifische Aufgaben und Verantwortungsbereiche zugeordnet sind. Mit ihrem Handeln sollen sie zum Erfolg des Systems beitragen, sie haben eine definierte Legitimation, eine von außen vorgegebene Struktur und sind mit spezifischen Erwartungen an den Rollenträger in punkto Verhalten, Einstellungen, Werte, Know-how usw. verbunden. Es gibt aber immer auch einen eigenen Gestaltungsraum, in dem der Rollenträger seine Aufgaben individuell interpretieren und ausüben kann. in der Arbeitswelt gibt es relativ einfache, unkomplizierte Rollen, aber immer mehr solche, die hoch komplex und herausfordernd sind. Zu den letzteren gehören ganz sicher Rollen wie jene des ScrumMasters und des Product Owners. Neue Rollen brauchen in der Regel Zeit, um sich etablieren zu können und akzeptiert zu werden. Ihr Sinn und Nutzen für das System zeigt sich erst im Laufe der Zeit. Der Rollenträger hat darauf großen Einfluss: Schließlich trägt er mit seinem kompetenten Handeln dazu bei, wie seine Rolle im beruflichen Umfeld wahrgenommen und eingeordnet wird. Dafür braucht man bestimmte Fähigkeiten und Fertigkeiten, aber auch ein entsprechendes Handwerkszeug. Genauso muss die neue Rolle in ihrem Umfeld, besonders an den Schnittstellen, auf Offenheit und Verständnis stoßen, damit der Nutzen tatsächlich wahrgenommen werden kann. Was dabei auf jeden Fall notwendig ist, ist die eindeutige Legitimation durch das Management.
In der Scrum Praxis machen viele die Erfahrung, dass eine Grundausbildung zum ScrumMaster oder Product Owner für die ganze Komplexität dieser Aufgaben nicht ausreicht. Im Alltag wird schnell deutlich, wie zentral der sorgsame Umgang mit Menschen ist. Es müssen vielfältige Kommunikationsprozesse gesteuert werden, in der Veränderungsdynamik muss die laterale Führungskraft die Ruhe bewahren, manchmal auf Konfrontationskurs mit dem Management gehen usw. usw. Kurzgesagt lautet das, was diese Rollen so besonders macht: Change, Change und nochmal Change!

Neue Rollen sind Stützen der Veränderung

Wer an Change denkt, denkt meist zuerst an das Neugestalten von Strukturen und Prozessen im Unternehmen. Als prozesshafte Struktur tut das Scrum natürlich. Ein ScrumMaster denkt aber weit darüber hinaus: Er denkt an die betroffenen Menschen und an die tradierte Unternehmenskultur. Ihm ist bewusst, dass er die Menschen einbinden muss, wenn die Kultur des Systems neu gestaltet werden soll, denn die Menschen sind die Kultur. Sowohl ScrumMaster als auch Product Owner (ggf. auch Team- oder Projektleiter) werden zu wertvollen Stützen eines agilen Unternehmens, wenn sie in ihrem Change-Repertoire sattelfest sind und es zum richtigen Zeitpunkt einsetzen. Damit helfen sie auch dem Management, Veränderungsprozesse über Scrum hinaus anzustoßen. Natürlich gibt es Schattenseiten, wenn diese Rollen schlecht ausgefüllt werden: Frustration, Demotivation, Resignation bei den betroffenen Mitarbeitern. So werden nicht selten die wertvollsten Mitarbeiter „verbrannt“.

Der Scrum ChangeManager als multifunktionale Rolle


 

Was sind die Lernfelder für diese multifunktionalen Rollen? Laterales Führungswissen, die Kompetenz der professionellen Kommunikation, Umgang mit Konflikten, Moderation und Workshopgestaltung, die Kunst des Coachings, systemisches Know-how zum Change Management und zur Teamentwicklung haben zentrale Bedeutung. Ebenso muss die eigene Persönlichkeit durch gezieltes Selbstmanagement weiterentwickelt werden. Für einen solchen „Knochenjob“, bei dem manchmal der Widerstand um die Ohren pfeift,  braucht man Selbstsicherheit und Standing, Klarheit über die eigenen Ziele und Ressourcen, Mut zu Innovation und Kreativität und den bewussten Umgang mit Herausforderungen und Stress. Gerade neue, noch nicht umfassend etablierte Rollen brauchen Zeit um zu lernen, Erfahrungen zu sammeln und Feedback zu bekommen, um sich ihren Status zu erarbeiten.

Zukünftige Rollenträger, Management und Personalentwicklung tun also gut daran, sich schon zu Beginn einer Scrum-Implementierung um die Ausstattung mit den nötigen Fertigkeiten zu kümmern. Der zertifizierte Scrum ChangeManger als Vertiefungs- und Erweiterungskonzept ist ein sinnvoller Weg dazu. Er bleibt nicht beim Verändern vom Vorgehensweisen stehen, sondern sieht das Ganze, die Menschen in einer neuen Situation. Und daher verändert und entwickelt er zu allererst: sich selbst.


Tipp

Wie fülle ich meine Rolle erfolgreich aus? Mit unseren Scrum Supplements stärken Sie Ihr souveränes Auftreten als Change Agent: Konflikte regeln, Impediments lösen, Teams entwickeln, Workshops gestalten, Gespräche zielorientiert führen – all das mit der richtigen Dosis Selbstbewusstsein.

Warum wir Ziele brauchen

Was macht jemand, der sich verändern möchte? Er setzt sich ein Ziel. Der Raucher will in einem Monat von einer Packung auf drei Zigaretten runtergehen. Ich will bis zum Sommer hundert Meter in 11 Sekunden laufen können.
Auch in der Produktentwicklung werden gerne Ziele gesetzt. Bis Ende des Jahres soll der Gewinn um dreißig Prozent steigen, der Wartungsaufwand halbiert werden und die Anzahl zufriedener Kunden signifikant wachsen. Alles schön und gut.
Aber: Was passiert mit uns, wenn wir uns solche Ziele setzen? Wir bauen Brücken, um sie zu erreichen. Mary und Tom Poppendieck zählen drei Möglichkeiten auf, ein Ziel zu erreichen:

Gibt es eine Abkürzung zur Veränderung?

Ziele können also auch über Abkürzungen erreicht werden. Wir biegen dann die Verhältnisse so lange zurecht, bis sie auf das Ziel passen. Eine wirkliche Veränderung erreichen wir damit nicht – sondern bewirken mitunter etwas ganz anderes. Deshalb dürfen wir Ziele nicht mit Zwecken verwechseln: Mein Ziel ist, 100 Meter in 11 Sekunden zu laufen. Dabei verfolge ich den Zweck, etwas für meine Gesundheit und mein Selbstbewusstsein zu tun. Wenn ich dazu eine Abkürzung nehme und zu leistungssteigernde Drogen greife, mag ich mein Ziel zwar erreichen – den Zweck verfehle ich aber oder handle sogar konträr dazu.
Mary und Tom Poppendieck raten aus solchen Gründen davon ab, Ziele zu setzen. Und sie liefern ein weiteres Argument: Wer anderen Ziele setzt, bringt ein Defizit zum Ausdruck. Du bist noch nicht schnell genug. Das Unternehmen generiert noch zu wenig Gewinn. Das kann zu einer negativen Stimmung führen.
Sollen wir also besser gar keine Ziele setzen? Ich sehe das anders. Ziele haben einen großen Vorteil: Sie sind prinzipiell erreichbar. Das macht uns stark. Denn wir können auf sie hinarbeiten, uns ihnen Schritt für Schritt nähern. Und am Ende stolz sagen: Ich habs geschafft.
Sie zeigen, wo man gerade steht und was noch zu erreichen ist. Sie dürfen nicht utopisch sein, sondern müssen den Möglichkeiten des Systems entsprechen. Ich kann 100 Meter in 11 Sekunden laufen – 10 Sekunden sind für mich außer Reichweite. Unter dem Stichwort SMART verbergen sich fünf Eigenschaften guter Ziele: Spezifisch, messbar, erreichbar, relevant, zeitlich terminiert.
Und: Ziele dürfen nie isoliert formuliert werden. Sie ergeben nur dann Sinn, wenn sie mit einem Wozu, mit dem Zweck verbunden sind. Wer seinen Gewinn steigern möchte, um seine Quartalsziele nicht zu verfehlen, der mag mit Bilanzkosmetik genau das Richtige tun. Wer es aber tut, um die Produktivität zu erhöhen, der wird um Veränderungen in der Organisation nicht umhinkommen. Dabei sind Ziele nur Wegmarken, wie die Leuchtfeuer am Boden vor der Landepiste. Umso wichtiger ist es, ein scharfes Bild vom dem zu haben, was man erreichen möchte. Wir nennen das Vision. Erst eine gute Vision macht Ziele attraktiv, gibt ihnen Anziehungskraft. So kann aus dem mühsamen Abrackern eine spannende Herausforderung werden. John F. Kennedy hat es mit seiner Vision zur Mondlandung geschafft, die ganze Welt bei der Zielerreichung mitfiebern zu lassen.
Wie sieht es in deiner Organisation, in deinem Leben aus? Hast du Ziele, für deren Erreichung du arbeitest? Machen sie Sinn, steckt dahinter ein Zweck? Und welches Bild, welche Vision verbindest du damit?
Mary und Tom Poppendieck: Leading Lean Software Development: Results Are Not the Point. Addison-Wesley.

Das Haar in der Suppe oder was ScrumMaster gegen negative Denkmuster tun können

Scrum bedeutet Veränderung und Veränderungen, ob kleine oder große, sind schmerzhaft – zumindest solange, bis die Veränderung vollzogen ist. Ein routiniertes Verhalten abzulegen und gegen ein anderes einzutauschen, wird von uns Menschen überwiegend als Risiko wahrgenommen und löst Gefühle wie Unsicherheit oder sogar Angst aus. David Rock, Autor von “Brain at work”, drückt das mit den treffenden Worten aus: “Uncertainty is poison to thought. We want to know what will happen next.“

Die Folge dieser Unvorhersehbarkeit des Unbekannten ist, dass wir in eine Position der Ablehnung gehen und jeden Sinn für Neutralität und Offenheit verlieren. Alles, was darauf hindeutet, dass etwas anders werden wird, wird nicht nur einfach in Frage gestellt, sondern zumeist wie eine Bedrohung erlebt. Und damit nicht genug. Wir finden in anderen Menschen oftmals Gleichgesinnte und ziehen uns gegenseitig runter, weil wir im Pessimismus eine Gemeinsamkeit gefunden haben: „Das kann nicht funktionieren!“ Die Argumente, die für eine Veränderung sprechen, reichen einfach nicht aus. Sie sind immer zu schwach, weil wir gemeinsam (relatedness) an dem festhalten, was uns in dieser Unsicherheit gewiss (certainty) zu sein scheint: eine Veränderung kann nur schief gehen und bringt nichts Gutes. Der Fokus geht ausschließlich in Richtung des Problems: Was wird alles nicht funktionieren? Was könnte alles schief laufen? Was würden wir verlieren, wenn wir uns für die Veränderung entscheiden?
In meinen Trainings erlebe ich bei einer simplen Übung eine ähnliche Denkart. Ich schreibe vier einfache Rechenaufgaben auf:
18 + 4 = 22     //     23 – 8 = 15     //     6 x 4 = 20     //     25 : 5 = 5
Was fällt euch auf? Stimmt. Eine (die dritte) Rechnung ist falsch (6 x 4 = 24). Das Gleiche stellen die Trainingsteilnehmer auch fest. Immer. Es war noch nie anders. Kein einziges Mal habe ich erlebt, dass die erste Reaktion lautete: Drei Rechnungen sind richtig, nur eine ist falsch. Stattdessen wird das Haar in der Suppe gesucht und gefunden. Das Schlechte oder in diesem Fall Falsche fällt uns schneller ins Auge, nicht zuletzt, weil ein Misserfolg immer emotional stärker erlebt wird, als ein Erfolg. Daraus entsteht eine Art Schutzhaltung, die ihre Kraft darauf ausrichtet, sich durch eine pessimistische Grundhaltung gegen ein Negativerlebnis zu wappnen: klappt etwas gut, dann bin ich überrascht und erleichtert, klappt etwas nicht, dann fühle ich mich bestätigt, weil ich es ja schon vorher gesagt hatte. Die Folge sind negative Denkmuster, die unsere Denkkanäle einseitig prägen und wie eine Abwärtsspirale wirken. Sogenannte negative Denkmuster gehen von einer Unveränderbarkeit der aktuellen (Problem-)Situation aus und versperren damit jeden Weg auf eine andere, neue, optimistische, lösungsorientierte Perspektive. Die Dominanz von Verallgemeinerungen (z.B. Scrum passt nicht zur Branche X), blockierenden Annahmen (z.B. So kann das doch nichts werden) oder selbsterfüllenden Prophezeihungen (z.B. Ich konnte noch nie gut mit anderen kommunizieren) überdecken auf diese Weise jede Möglichkeit des anders Denken.
Eine der drei integralen Verantwortungen des ScrumMasters ist, dass dieser sein Team schützen soll. Natürlich ist hiermit in erster Linie gemeint, dass keine Anforderungen außerhalb eines Commitments zur Verpflichtung werden, damit das Team störungsfrei arbeiten kann. Ein ScrumMaster schützt aber ebenso gegen die Verbreitung negativer Denkmuster. Als Change Agent gehört es zu seiner Aufgabe, das agile Mindset zu schärfen, indem der Fokus auf die Lösung (weg vom Problem) gerichtet wird. Steve de Shazer, Begründer der lösungsfokussierten Kurzzeittherapie, wirbt für eine solche Form der  Umdeutung (Reframing), indem er sagt: Wenn etwas nicht funktioniert, dann probier etwas anderes.

Worte, die unser Denken verändern können

Ihr fragt euch nun sicher, was ihr jetzt tun könnt? Natürlich ist das Ablegen von Handlungsroutinen nichts, was per Knopfdruck geschieht. Es ist aber möglich. Wenn mir Menschen von Problemsituationen erzählen, dann konzentrieren sich die Schilderungen auf zwei Aspekte: Wie schlimm und aussichtslos die Situation ist und was alles nicht funktioniert bzw. was derjenige alles nicht tut. Würdigt und lobt, was ihr bereits unternommen habt, sorgt ab diesem Moment für einen Kurswechsel und fragt:

Was machst du stattdessen?

Es ist nur ein Wort. Ich kann euch aber empfehlen, euer Gegenüber zu beobachten, wenn ihr eure Frage mit der Lösungsformel „stattdessen“ stellt. Es passiert nichts. Stimmt. Euer Gegenüber schweigt. Und er oder sie schweigt, weil er oder sie nachdenkt. Und das ist ein gutes Zeichen. Ihr habt ins Schwarze getroffen. Ich empfehle euch, nicht locker zu lassen. Immer wieder wird euer Gegenüber versuchen, gedanklich und mit seinen Argumenten dorthin zu „flüchten“, wo er oder sie sich auskennt – ins Problem. Das ist leicht zu erkennen an einem Aber, Negationen oder dem Konjunktiv. Bleibt am Ball und lasst den Problemwälzer auf die Suche nach positiven Ausnahmen (= ein klitzekleines Anzeichen, wann/wo das Problem weniger war) gehen oder konfrontiert ihn mit Fragen, mit denen er nicht rechnet:

Übrigens: Solltet ihr feststellen, dass euer Gegenüber plötzlich mitmacht und Gefallen daran findet, an seinem Lösungsbild zu arbeiten, dann verweise ich gern ein zweites Mal auf de Shazer: „Wenn etwas gut funktioniert, dann mach mehr davon!

Can't get there from here: Stolpersteine in Transition Teams

Wer glaubt, Scrum zu machen, steht gerade erst am Anfang. Früher sind Scrum-Implementierungen mit dem erfolgreichen Aufsetzen von Teams zu Ende gegangen. Dieser Ansatz griff allerdings zu kurz. Denn Scrum erzeugt Transparenz. Und die Probleme, die einer besseren Produktentwicklung im Wege stehen, sind selten den Scrum-Teams alleine geschuldet.
Wer nur an der lokalen Optimierungen arbeitet und versucht, Scrum-Teams zu hochmotorisierten Produktionsstätten zu machen, wird eines Tages frustriert das Handtuch werfen. Denn ein Team kann nur so gut sein wie die Organisation, in der es funktioniert.
Deshalb setzen wir mittlerweile in jedem Scrum-Implementierungsprojekt ein Transition Team auf. Es besteht meist neben Product Ownern und ScrumMastern aus dem mittleren und höheren Management. Es soll eine Koalition darstellen, die Veränderungen in der Organisation anstoßen und durchsetzen kann. Wir nennen es Transition, um zu zeigen, dass wir noch nicht dort sind, wo wir sein möchten, uns aber auf dem Weg dorthin befinden.
Transition Teams können aus vielen Gründen scheitern. John P. Kotter benennt in seinem Buch Leading Change einige Ursachen, die sich auch mit unserer Erfahrung decken.

Schwaches Problembewusstsein

Ein Transition Team ist immer eine Zumutung, denn es erfordert von seinen Mitgliedern eine Menge Zeit. In meinem Transition Team gehen pro Person mindestens sieben Stunde pro Woche drauf – häufig deutlich mehr. Der Terminkalender meiner Teammitglieder ist natürlich immer überfüllt. Zusammenarbeit wäre nicht möglich, wenn nicht allen klar wäre, dass die Arbeit im Transition Team Priorität über andere Termine hat. Dazu muss allen Teammitgliedern klar sein, dass Veränderungen dringend und wichtig sind, und dass das Transition Team das Mittel der Wahl zum Erreichen dieser Veränderungen ist.
Tipp: Stellt Eurem Transition Team folgende Frage: Woran werden wir scheitern? Wer in den Abgrund blicken kann, der entwickelt ungeheure Energien.

Falsche Besetzung

Ein Transition Team muss Mitglieder mit genügend Entscheidungskompetenzen haben, um die Veränderungen auch durchsetzen zu können. Es gibt nichts Frustrierenderes als ein hoch engagiertes Transition Team, das stundenlang die schönsten Konzepte und Szenarien ausarbeitet, um dann an irgendeinem Entscheidungsgremium zu scheitern. Manche Transition Teams sind so groß, dass keine gute Diskussion mehr möglich ist. Anderen fehlt es schlichtweg an einem ScrumMaster, der sich um ihre Produktivität kümmert.
Tipp: Orientiert Euch bei der Größe an Scrum-Teams! Diese sollten nicht mehr als neun Mitglieder haben, darunter ein Product Owner und ein ScrumMaster als dedizierte Rollen.

Unangemessene Zielvorstellung

Was wollen wir mit dem Transition Team eigentlich erreichen? Ich erlebe häufig zwei Extreme. Das eine Extrem besteht aus Transition Teams, die hauptsächlich an Verwaltungsaufgaben arbeiten. Ein Beispiel hierfür ist der Einsatz neuer Tools oder die Beschreibung bzw. Ausgestaltung von Abläufen. Das sind Aufgaben, die keiner großen Veränderung bedürfen und entsprechend bescheidene Ziele nach sich ziehen. Das andere Extrem besteht aus Transition Teams, die an Zielen arbeiten, die so monumental sind, dass sie sie aus eigener Kraft gar nicht erreichen können. In meinem derzeitigen Transition Team wollten wir ganz zu Beginn die agile Organisation konzipieren – bis wir dann merkten, dass das Aufsetzen von Scrum-Teams zu jenem Zeitpunkt unsere eigentliche Aufgabe war.
Tipp: Gebt Euch zuerst eine Vision, die das Zielbild darstellt. Gebt Euch dann eine Mission, die den Weg dorthin beschreibt.

Keine Führung

Welche Menschen sitzen in deinem Transition Team? Sind es Verwalter und Optimierer? Oder gibt es auch Menschen, die den Status Quo in Frage und die Organisation vor echte Herausforderungen stellen können? Manchmal reicht auch schon eine Person mit Führungsanspruch in einem Transition Team – solange sie als Visionär alle anderen Mitglieder für den Change begeistern kann.
Tipp: Prüft bei jeder Story, inwiefern sie dem Geiste der Vision entspricht. Vieles wird sich dann als nebensächlich entpuppen.
Wenn man so viel falsch machen kann, warum machen wir uns dann überhaupt die Mühe, Transition Teams aufzusetzen? Weil wir Scrum als Vehikel zu einer Veränderung nutzen möchten, die zwar in den Scrum-Teams ihren Dreh- und Angelpunkt hat (wir machen Produkt-, nicht Organisationsentwicklung), aber ohne gescheite Rahmenbedingungen früher oder später verkümmert.
Woran merken wir, ob ein Transition Team seine Arbeit gut verrichtet? Indem es sich nach und nach überflüssig macht. Denn eine Organisation mit hinreichend starken ScrumMaster- und Product Owner-Teams kann mehr und mehr Veränderungen von selbst anstoßen und durchsetzen. Aber dahin zu kommen, das ist der eigentliche Weg einer jeden Transition. Es lohnt sich.
John P. Kotter (1996): Leading Change. Harvard Business Review Press. (http://astore.amazon.de/borisgloger-21/detail/0875847471)
Siehe auch: Bitte geben Sie Ihr Ziel ein! Tipps für das Transition Team

Wenn ich einmal groß bin …

Was macht ein Teamleiter in Scrum? Was wird aus einem Projektleiter? Wie verhalten sich diese Rollen zu den Rollen in Scrum? Früher oder später tauchen in jeder größer angelegten Scrum-Implementierung diese Fragen auf. In den meisten Fällen wird die Rollenduplizität eine ganze Weile erhalten: Der Teamleiter ist dann beispielsweise Product Owner. Und der Projektleiter macht (mehr oder weniger nebenbei) den ScrumMaster. Und umgekehrt. Oder es gibt eine Rollenparallelität: ScrumMaster und Product Owner führen und entwickeln nach Scrum, während Projektleiter und Teamleiter klassisches Projektmanagement machen (oftmals sogar für das gleiche Projekt). Dass das auf Dauer nicht optimal ist, sollte keine Überraschung sein. Umso dringender stellt sich die Frage nach einer besseren Rollenverteilung.

Scrum ist keine Rollenevolution

Die Antwort dazu muss zwangsläufig ernüchternd ausfallen. Scrum wurde nicht erfunden, um das klassischen Projektmanagement weiter zu entwickeln. Scrum versucht daher erst gar nicht, eine Kontinuität oder eine Evolution herzustellen. Von Anfang an ist Scrum als Alternative angetreten, die nicht ein UND oder ein ZUDEM, sondern ein ODER im Angebot hat. Folglich gibt es in Scrum keine natürlichen Zuordnungsmöglichkeiten: Wer behauptet, dass ein Projektleiter “am ehesten” Product Owner wird, der unterschätzt die Radikalität der Scrum-Rollen.
Manche pendeln dann direkt ins andere Extrem und behaupten, für die klassischen Rollen gäbe es in Scrum gar keine Verwendung mehr. Wer so denkt, der ist noch nicht in der Wirklichkeit angekommen: In jedem Projekt geht es doch darum, Scrum unter den jeweils aktuellen Bedingungen zu implementieren. Und diese Bedingungen sind nur im Lehrbuch die einer grünen Wiese.

EIn Beispiel

Ich habe vor kurzem mit einem Projektleiter zusammengearbeitet, der Scrum für sein Projekt einführte. Nach einigen Sprints übernahm er die Rolle des ScrumMasters. Der Product Owner kam wiederum aus dem Fachbereich. Beide Scrum-Rollen haben nie ganz richtig gesessen: Der Product Owner hatte zu wenig Produktkenntnis und konnte daher mit dem Team nicht auf der Ebene eines zweiwöchigen Sprints planen. Er hat sich mit der Zeit in die Rolle des Kunden zurückgezogen – und fühlt sich nun dort besser aufgehoben. Der ScrumMaster war anfangs sehr ungeduldig und versuchte in seiner Projektleiterrolle zunächst, das Team mit Vorschriften und Arbeitszuweisungen zu führen.
Wir haben solche Momente kritisch reflektiert. Über die Sprints gelang es dem ScrumMaster, in die Rolle des Teamsponsors zu wechseln, der nicht nur das Team beschützt (das tat er schon immer), sondern auch Freiräume ermöglicht und Entscheidungen respektiert. Als klar wurde, dass der Product Owner seine Rolle nicht ausüben konnte, spielte der ScrumMaster mit dem Gedanken, dorthin zu wechseln. Wir empfahlen ihm, ScrumMaster zu bleiben. Er hatte genügend Produktkenntnisse und wäre vermutlich ein guter Product Owner geworden. Aber sein Interesse um das Wohl und Gedeihen des Teams war bei ihm so stark ausgeprägt, dass er letztendlich selber entschied, ScrumMaster zu bleiben.

Wichtig: Perspektiven

Das oben genannte Fallbeispiel soll eines zeigen: Ob jemand für eine Scrum-Rolle geeignet ist, hängt einerseits davon ab, wie klassische Rollen gelebt werden. Ein Fachbereich mit wenig Produktkenntnis wird es schwer haben, in die Rolle des Product Owners zu kommen (was nicht heißen muss, dass man ihn nicht dorthin entwickeln kann). Und ein Projektleiter mit viel besserer Produktkenntnis ist nicht unbedingt der bessere Product Owner – entscheidend sind dann nämlich auch die Persönlichkeit und die sonstigen Fähigkeiten der einzelnen Person.
Zu Beginn spricht auch in der Tat nichts dagegen, Rollenfragen – wie hier beschrieben – pragmatisch zu lösen.  Entscheidet sich das Unternehmen jedoch, Scrum auszurollen, dann brauchen wir bessere Antworten auf die Rollenfrage. Denn die Mitarbeiter werden sich in jedem Fall die Frage stellen, wie es mit ihnen weitergeht und manche werden sich in Scrum nicht wiederfinden. Aber auch ein ScrumMaster braucht eine Perspektive: Was bedeutet meine Rolle im Unternehmen, welche Entwicklungs- und Aufstiegsmöglichkeiten habe ich? Auch formelle Strukturen wie Rollenbeschreibungen, Einstufungen und Karrierepfade sind wichtig für die Mitarbeiter, bevor sie sich langfristig für eine solche Rolle entscheiden.
Sind die Perspektiven erstmal da, kann man mit den Mitarbeitern gemeinsam herausfinden, wo sie sich am ehesten sehen und ihnen auch klar machen, wo die Organisation sie am ehesten sieht. Scrum hat enormes Begeisterungspotenzial, weil es für viele Unternehmen einen frischen, unverkrampften und oftmals subversiven Neuanfang bedeutet. Gerade in größeren Unternehmen kann Karriere jedoch nur über formale Pfade gemacht werden. Damit die Begeisterung für Scrum anhält und auch über die Pioniere hinaus wirken kann, braucht es die Anerkennung und Ausgestaltung der Scrum-Rollen im Unternehmen.
Danke an Kristina Klessmann, die mich beim Verfassen dieses Artikels unterstützt hat!

Mr. Change, könnten Sie meine Gefühle bitte etwas weniger aufwirbeln?!

Liebe alle Scrum Coaches da draußen,
geht es euch auch wie mir?!
Ich sitze im Zug nachhause nach einer gefühlt sehr langen Woche beim Kunden und bin mental sowie physisch komplett erschöpft. Ich habe das Gefühl, dass in diesem Business kein Tag dem anderen gleicht. Wenn ein Tag ohne größere Ereignisse abläuft, kann ich garantieren, dass der Schein trügt. Denn hinter der nächsten Ecke lauert schon irgendetwas, das einen in hochjauchzendes Lachen versetzen bzw. zu Tode betrübt zu Boden werfen möchte.
Anfangs dachte ich mir, das läge an mir. An der Macht meiner Stimmungen. An Unsicherheiten. An Charaktereigenschaften. Mehr und mehr jedoch merke ich, dass diese Belastung nicht nur von mir aus kommt. Selbst Angestellte in der Organisation, die ich berate, haben mir von ihren persönlichen und täglichen Achterbahnen der Gefühle berichtet. Erst da habe ich realisiert, dass dieser Zustand keine Beraterkrankheit ist. Nein. Es ist ganz einfach der Cocktail der Gefühle, der in jedem Unternehmen gemixt werden kann und wird, das eine umfassende Veränderung durchführt. Und auf einen Scrum Consultant wird jede dieser Emotionen direkt abgeladen. Hier. Bitte. Danke. Jetzt schau, wie du damit umgehst. Na servus.
Es hat eine Weile gebraucht, doch mittlerweile weiß ich, wie ich mit dieser oft ungewollten Ladung umgehe. Ganz einfach. Ich mache jeden einzelnen Abend eine persönliche Retrospektive. Was ist heute passiert? Was habe ich heute gut gemacht?! Was könnte ich verbessern?! Wie werde ich das nutzen, um mich zu verbessern?! Sich ein paar Minuten Zeit zu nehmen, um diese tägliche Übung durchzuführen, kann ich jedem nur wärmstens empfehlen. Man muss es ja nicht unbedingt auf Flipcharts und mit Post-Its machen…ein einfaches Revue-Passieren lassen und persönliches Brainstorming im Zug bzw. auf dem Rad nach Hause reicht auch oft aus.
Genau so eine Retrospektive habe ich soeben abgehalten. Jetzt erkenne ich auch, dass egal wie k.o. ich mich jetzt fühle, es eine tolle Woche war. Woran ich erkenne, dass sie toll war?! Daran, dass ich wahnsinnig viel gelernt habe und konstruktives Feedback erhalten habe. Jetzt kann ich mich weiterentwickeln – hin zu einem besseren Consultant, einem besseren Scrum Coach, einem besseren Menschen. Das hätte ich ohne diese emotionalisierenden Momente nicht geschafft.
Ich wünsche noch ein schönes Wochenende,
Eure Stephy

Warum Obama nur graue und blaue Anzüge trägt: Von Stabilität in Veränderungsprozessen

Wenn wir zu unseren Kunden gehen, dann immer mit der Absicht, etwas zu verändern. Wir implementieren Scrum, was einhergeht mit einer Veränderung der Rollen, Prozesse und Werte der Zusammenarbeit. Und wir möchten am liebsten, dass alle Mitarbeiter freudig aufspringen und rufen: „JA! Wir wollen uns verändern!“ Stattdessen jedoch sind viele Mitarbeiter erst einmal verhalten: „Ja, die agile Idee ist klasse und wir haben schon viel von Scrum gehört und gelesen, aber ich bin mal gespannt, wie ihr das hier machen wollt.“
 
Und dann starten wir mit ersten Trainings und damit, die ersten Teams auf Scrum umzustellen. Das bedeutet für die Mitarbeiter viel Veränderung: Die Teams werden neu gemischt, Mitarbeiter bekommen andere Rollen, wir implementieren Regelmeetings, alles wird transparent gemacht und wir sprechen plötzlich offen mit allen über Hindernisse in der Organisation. Uffz! So anstrengend haben sich die Mitarbeiter die Umstellung gar nicht vorgestellt. Plötzlich spürt man in den Teams den Gedanken: „Och, eigentlich war es doch immer ganz gemütlich hier. Können wir nicht wieder zurück?“ Dann bekommen die Consultants eine anstrengende Aufgabe, nämlich die angestoßene Veränderung konsequent weiter aufrecht zu erhalten. Die Veränderungen müssen im Verhalten der Mitarbeiter und den Prozessen im Unternehmen verankert werden.

Nicht zu früh abweichen!

Aber das Zurückrudern meinen die Mitarbeiter nicht böse – für diese Reaktion gibt es eine rein biologische Erklärung. Professor Gerhard Roth, Neurobiologe an der Universität Bremen sagt: „Für unser Gehirn gibt es kaum etwas schwierigeres, als Gewohnheiten abzulegen.“ Wir haben uns bereits an Verhaltensweisen gewöhnt und können sie automatisch anwenden. Das ist gut so, denn wir müssen selektieren, worüber wir uns Gedanken machen, sonst läuft unser Arbeitsspeicher im Gehirn voll.
 
Barack Obama trägt nur blaue und graue Anzüge. Warum? Er sagt: „Ich will mich nicht entscheiden, was ich anziehe oder esse, weil ich zu viele andere Entscheidungen treffen muss.“ Gewohnheiten und Routinen sind wichtig, um uns Luft zu verschaffen und sie geben uns Sicherheit. „Das Gehirn versucht unentwegt, so viele Handlungen wie möglich in Routinen zu verwandeln,“ sagt Professor Roth. Und daran arbeiten wir mit der Einführung unseres Scrum-Flows: eine neue Sicherheit und Routine herzustellen. Ja, ich weiß, das dauert ein paar Sprints, aber es funktioniert! Dazu müssen Mitarbeiter und Consultants großes Durchhaltevermögen beweisen und konsequent zusammenarbeiten.
 
Viele Teilnehmer in Trainings fragen mich: „Was ist der größte Fehler, den man bei der Einführung von Scrum machen kann?“ Und meine Antwort darauf ist: „Das zu frühe Abweichen vom Scrum-Flow und den Scrum-Grundlagen. Oder den vermeintlich nervenden Consultant zu früh nach Hause zu schicken.“ Mindestens die ersten drei Sprints sollten wirklich nach Lehrbuch umgesetzt werden. Da muss man sich durchbeißen, und konsequent sein. Das ist hart, aber danach wird der Scrum-Flow zur Routine und wir können uns stärker auf andere Dinge konzentrieren, wie z.B. Teamentwicklung oder Steigerung des Levels of Done. Jetzt beginnt also die Kür der Veränderung und damit der eigentlich spannende Teil. Daher lautet mein Rat zu Anfang: „Haltet durch! Land ist in Sicht“
 
Angelehnt an den Artikel “So besiegen Sie schlechte Gewohnheiten!” (Elke Hartmann-Wolff) im  Focus 02/13 vom 07.01.2013

Entschuldigen Sie bitte, wie lösen Sie Ihre Probleme?

2012 – Das Jahr geht zu Ende und viele Unternehmen stecken mitten in ihren Transitionen hin zur agilen Organisation. Ob strategisch beschlossen oder durch die eigenen Teams in die Unternehmen gebracht: AGILE setzt sich immer mehr durch und stößt auf Herausforderungen. Die größte Herausforderung in den Organisationen ist die eigene Kultur. Denn ohne einen Wechsel in den Köpfen und Herzen der Menschen wird jeder Wandel zum Spießroutenlauf – mit wenig Hoffnung auf Erfolg. Peter Drucker drückt es so aus: “Culture eats strategy for breakfast” und beide sitzen sich in den Unternehmen täglich beim Brunch gegenüber. Um einen Wandel zu vollziehen, der nicht der hungrigen Kultur zum Opfer fällt, benötigen wir also eine Kultur, die gemeinsam mit der Strategie am großen Kuchen Organisation backt. Ein solcher Wandel gelingt meines Erachtens, wenn man sich nach allgemeingültigen Prinzipien ausrichtet. Prinzipien wie beispielsweise Fairness, Offenheit, Respekt & Freude.
2001 – In diesem Jahr wurde der Grundstein für die Agilität gelegt, das Agile Manifesto. Mit dem Agile Manifesto geben wir Unternehmen eine Orientierung nach Prinzipien, die für den Wandel hin zur agilen Organisation wichtig sind. Eine genaue Ausrichtung – ein true north, um sich stetig zu hinterfragen und neu zu orientieren.
2012 – Wie gehen heute die meisten Organisationen ihre Probleme an? Leider zumeist mit der Denkweise, durch die sie entstanden sind. Hilft das bei der Lösung? Laut Albert Einstein NEIN, denn: “Probleme kann man niemals mit derselben Denkweise lösen, durch die sie entstanden sind.” Wie versuchen Organisationen ihren Wandel durchzuführen. Nehmen wir das Beispiel der klassischen Organisation zur agilen Organisation: Es wird geplant, geplant, geplant. Am Start sucht man bereits das Zielfoto und das in einem komplexen, globalisierten System, dass lediglich auf Anreize reagiert und nicht gesteuert werden kann. Grundbedingung ist natürlich, dass wir Organisationen als komplexe Systeme begreifen, die am besten durch empirische Prozesse ausgesteuert werden können. Also einen faktenbasierten Prozess, der auf Messung der Ergebnisse beruht – bspw. ein Prozess wie Scrum, der dazu noch einen Change Agent in jedes Team steckt und das im Auftrag der Kultur. Konkret einen Prozess, der sich auf das Tun versteht, der es ermöglicht anzuschauen, zu inspizieren oder wie Johann Wolfgang von Goethe es sagte: “Denken ist interessanter als Wissen, aber nicht als Anschauen.”

2012/2013 – und wie geht es weiter?

Am besten hinterfragen Sie sich regelmäßig, inwiefern Sie selbst hinter diesen Werten stehen, wie stark Sie sich an diesen Werten ausrichten. Eine stetige Reflektion des eigenen Tuns hilft uns in der Zukunft, uns besser an den eigenen “Wunschwerten” auszurichten. Haben Sie schon Vorsätze für das neue Jahr? Vielleicht finden Sie konkrete Punkte zum Anknüpfen und bringen anstehende Tätigkeiten mit den Werten überein.
Als ScrumMaster führen Sie bspw. in der Retrospektive eine Einpunktabfrage für die Werte und wie sie im Team gelebt werden durch. Dadurch sehen Sie bspw. wo ihr Team gefühlt steht und können konkrete Vorsätze zu den jeweiligen Prinzipien/Werten ableiten.
Versuchen Sie, sich bei alten Denkmustern zu erwischen. Wenn Sie solche Momente finden, dann reflektieren Sie diese: Was hätte ich anders machen können oder was kann ich jetzt genau anders machen, anders in Bezug auf ihr Ziel?
In diesem Sinne: “Denken und Tun, Tun und Denken, das ist die Summe aller Weisheit, von jeher anerkannt, von jeher geübt, nicht eingesehen von einem jeden.” (Johann Wolfgang von Goethe)

Vom Glauben und sich Einlassen

Neulich standen zwei übertrieben freundliche und korrekt gekleidete Menschen vor meiner Tür. Auf meine Frage, ob sie jemanden suchten, kam die Antwort: „Wir suchen Sie!“
Ich mag es nicht, wenn Menschen mit dem einen Ziel das Gespräch suchen, den anderen restlos für seine eigenen Überzeugungen zu gewinnen. Zugleich finde ich es bemerkenswert, dass diese zwei Missionare einen herrlichen Samstag Nachmittag für das Putzen von Türklinken opferten und darin ganz offenbar einen Sinn sahen. Die Straßen und Parks waren an jenem Nachmittag voll mit fröhlich-unbefangenen Menschen, die mit einem Spaziergang oder einer Radtour ihrem Leben nachgingen.

Missionarische Berater, ungläubige Kunden

Als Berater sind wir immer wieder versucht, unseren Erfolg an der Nachmacherquote zu messen. Macht der Kunde es genau so, wie wir ihm das gesagt haben? Abweichungen werden dann oftmals von uns als Rückfall in alte Verhaltensmuster interpretiert. Der Kunde sieht das meist ganz anders: Er versucht, Scrum an seine Realität anzupassen und dabei seinen eigenen Weg zu gehen. Er glaubt nicht, dass die Erfolgsstories von anderen bei ihm funktionieren können und geht dann im Zweifelsfall lieber einen Kompromiss zuviel ein.
Beide Positionen sind problematisch. Der missionarische Berater überhebt sich in seiner Rolle. Indem er das Verhalten seines Kunden bis in letzte Detail festnageln will, nimmt er ihm das letzte Stück Freiheit. Der skeptische Kunde hat indes ein anderes Problem: Er will nicht so recht an das glauben, was sein Berater ihm erzählt. Er lässt sich auf Veränderungen nur so weit ein, wie diese seinen gewohnten Standpunkt nicht zu sehr in Frage stellen. Damit versperrt er sich den Weg zu der Veränderung, die er mit Scrum erreichen kann.
Es gibt keinen dümmeren Satz als jenen, der besagt, alles sei relativ. Natürlich sind wir in unseren Überzeugungen und Verhaltensweisen von unserer Subjektivität geprägt. Das, was ich glaube, ist meinen Erfahrungen und meinem Charakter geschuldet.
Das muss aber noch längst nicht bedeuten, dass unsere Glaubenssätze und Überzeugungen nur für uns Gültigkeit haben. Jeder von uns hat Erfahrungen gemacht, in denen er über seinen eigenen Schatten gesprungen ist. Situationen, in denen Menschen Schlechtes tun und wir aufrichtig darüber empört sind. Eigene Handlungen, die wir zutiefst bereuen. Menschen, die wir lieben. In solchen Situationen glauben wir nicht zaghaft, sondern zeigen Haltung. Wir tun das, was wir tun, in der Überzeugung ihrer intersubjektiven Richtigkeit.
Einen starken Glauben: Das wünsche ich  allen, die sich und ihre Welt verändern wollen. Sich auf etwas Neues einlassen kostet Kraft und ist alles andere als selbstverständlich. Wer da erstmal alle Zweifel und Einwände ausräumen will, der wird kaum über seine eigenen Grenzen hinauskommen. Deshalb ist es manchmal gut, einfach glauben zu können, ohne alles wissen zu müssen.
Wie  geht es dir heute und jetzt? Machst du einen Veränderungsprozess durch, der viele Fragen aufwirft? Hast du den Prozess vielleicht sogar selber angestoßen? Wie gehst du mit Zweifel um? Mit der Skepsis, die jedem einmal entgegen schlägt? Unser Coach, Dieter Rösner, hat mir einen wunderbaren Trick beigebracht: Wenn jemand etwas in Frage stellt, ohne sich darauf eingelassen zu haben, dann bitte ihn oder sie, es einfach mal auszuprobieren, und dir danach zu sagen, ob es Sinn gemacht hat oder nicht. Allein schon die Erfahrung – es ausprobiert zu haben – führt dazu, dass die Kritik konstruktiv wird.
Und ja: Es gibt einen Unterschied zwischen festem Glauben und blindem Glauben. Der blinde Gläubige folgt anderen und will sich dabei selber aufgeben. Der standhaft Gläubige folgt anderen, um mehr über sich und seine Welt zu lernen. Während der eine in immer größere Abhängigkeit gerät, kann der andere eines Tages den Hut packen und eigenständig weitermachen.
[quote author = “Ludwig Wittgenstein”]Denn um dem Denken eine Grenze zu ziehen, müssten wir beide Seiten dieser Grenze denken können (wir müssten also denken können, was sich nicht denken lässt).[/quote]