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

by SpaceX via


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.


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.


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.


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.


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.


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.



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.


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.


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.


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.


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.
Puh, das ist ja schon wieder voll!
Meine Frau Kathrin
(mit einem wissenden Lächeln)
Du kannst den Plastikmüll ruhig runterbringen.
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.


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.