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.

Agile Transformation

(c) Sabina Lammert

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