Kanban Change und Organisationsbilder

In meinem Blog-Artikel "Die Logik des Misslingens von Veränderungsinitiativen" habe ich ausgeführt, dass zwischen 60 und 80 Prozent der Veränderungsinitiativen in Unternehmen scheitern. An dieser Stelle sollten wir uns fragen, was ist es überhaupt das scheitert? Was ist das Objekt der Veränderung? Was ist eine Organisation? Mit den Namen Apple, BMW, Johnson & Johnson, Shell, usw. können wir sehr schnell eine Organisation identifizieren. Doch sind wir in einer Organisation, wenn wir durch die Firmentür gehen oder einen Anstellungsvertrag unterschreiben? Was ist, wenn am Abend alle Mitarbeiter und Mitarbeiterinnen nach Hause gegangen sind? Haben sie die Organisation dann in ihren Köpfen mitgenommen? Oder verbleibt die Organisation in den Räumen, im Mobiliar oder in den Dokumenten und wartet, bis sie am nächsten Tag wieder zum Leben erweckt wird?

Organisationsbilder

Fakt ist, dass sich Organisationen nicht auf Gebäude oder getriebeartige Räderwerke reduzieren lassen, für deren Veränderung man bloß einen neuen Gang einlegen muss oder wie eine Maschine per Knopfdruck steuern kann. Systemtheoretisch gesehen sind Organisationen lebendige soziale Systeme, die einen hohen Grad an Komplexität aufweisen. Nimmt man das Risiko übertriebener Polarisierung in Kauf, lassen sich zwei völlig unterschiedliche Unternehmensmodelle umreißen:

1. Ein mechanistisches, das kurz gesagt auf der Annahme linearer Kausalketten, rationaler Pläne und zentraler Steuerungsmöglichkeiten beruht. 
2. Ein systemisches, das auf der Annahme vielfältiger Feedbackschleifen, nicht gänzlich durchschaubarer Widersprüchlichkeiten und einer latenten Unsteuerbarkeit aufsetzt. 

In unserem Buch Kanban in der IT stellen Sigi Kaltenecker und ich Merkmale beider Organisationsbilder gegenüber:

Mechanistisches Organisationsbild	Systemisches Organisationsbild
Überschaubar und klar strukturiert	Komplex und in sich widersprüchlich
Lineare Kausalketten	Vielfältige Wechselwirkungen
Zentrale Steuerung, nach rationalem Plan zu leiten	Selbststeuerung, ihren eigenen Gesetzen folgend
Formale Logik	Integration von Widersprüchen
Primär zweckgetrieben	Primär sinngetrieben
Harte Fakten und rationale Beziehungen	Harte und weiche Faktoren, Emotionen
Struktur- und prozessorientiert	An Handlungsmustern und Routinen orientiert
Hohe Bedeutung von individuellen Vorgaben und Kontrollen	Hohe Bedeutung gemeinsamer Reflexion, Zusammenarbeit und Ergebnissicherung
Veränderung durch Instruktion und Befehl	Veränderung durch Dialog und Überzeugung
Zentralistische Führung	Polyzentrische Führung

Bezogen auf eine Kanban Change Initiative kann man festhalten, dass die Verordnung von Kanban "von oben" dem mechanistischen Bild entspricht. Ähnlich verhält es sich, wenn bei Kanban nur auf die Praktiken fokussiert wird, ohne die Prinzipien zu verfolgen. (Mehr zu den Prinzipien im Blog-Post "Wegweiser für eine Kultur der kontinuierlichen Verbesserung".)

Wenn man Organisationen als lebendiges soziales System begreift, kommt man sehr schnell zur Einsicht, dass es für eine erfolgreiche und nachhaltige Veränderung mehr braucht als die Verordnung von ein paar Praktiken oder Spielregeln. Veränderung benötigt aufmerksame Wahrnehmung von dem was im Unternehmen passiert und die Einbeziehung von den Menschen. Veränderung kann nicht von einem Mechaniker eingebaut werden.

Die Logik des Misslingens von Veränderungsinitiativen

Veränderungsmanagement, Change, Change Management, Change Leadership, usw. sind in aller Munde. Doch was steckt hinter diesen Begriffen der Veränderung? Was soll eigentlich verändert werden? Organisationen? Personen? Kulturen? Was passiert bei einer Veränderung? Was muss beachtet werden? Kann man Veränderung herbeiführen und vorantreiben? Was hat das alles mit Kanban zu tun?

Das und mehr wird Inhalt der Blog-Reihe KanbanInIT rund um das Thema Kanban Change Leadership, was auch zentraler Bestandteil des Buches Kanban in der IT von Sigi Kaltenecker und mir ist.

Gründe für die Veränderung in einem Unternehmens gibt es viele:

• Neue Technologien
• Globalisierung von Arbeits- und Konsummärkten
• Internationalisierung der Zusammenarbeit
• Individualisierung von Kundenwünschen
• Demographischer Wandel
• Aggressiver Wettbewerb
• Verunsicherung der Finanzmärkte
• usw…

Will ein Unternehmen erfolgreich sein, muss es sich an die ändernden Bedingungen permanent anpassen. Eigentlich können es sich Unternehmen gar nicht mehr aussuchen, ob sie sich verändern wollen oder nicht - Veränderung kann heutzutage nicht die Ausnahme sondern muss die Regel sein. "Business Agility" wird zum Mantra für Unternehmen des 21. Jahrhunderts.

Steigender Umsetzungsdruck veranlasst viele Unternehmen dazu, Veränderungsvorhaben so rasch wie möglich abzuschließen, sonst drohen sie noch während der Umsetzung obsolet zu werden. Unternehmen werden auch häufig von mehreren Veränderungswellen gleichzeitig überrollt: Outsourcing, kontinuierliche Verbesserung mit Kanban und Softwareentwicklung mit Scrum neben Initiativen zu Customer Value Management und Corporate Social Responsibility.

60 bis 80 Prozent der Veränderungsvorhaben scheitern

Die Veränderungsprojekte, die in Angriff genommen werden, erreichen jedoch selten die gesetzten Ziele. Allgemein gültige Zahlen gibt es zwar keine, doch unterschiedliche Stichproben weisen darauf hin, dass zwischen 60 und 80 Prozent aller Veränderungsvorhaben in den Sand gesetzt werden. Demnach steigt natürlich der Frust unter den MitarbeiterInnen. "Kanban kommt, Kanban geht" habe ich nicht nur einmal in anfänglichen Gesprächen gehört. Anstatt Einstellungen zu ändern, werden die Veränderungs-Wellen routiniert abgesurft. Diese Haltung wird auch durch den Umstand gefördert, dass viele Organisationen mit ungeeigneten Mitteln auf die Krisen in ihrem Umfeld reagieren:

• Es wird über Lösungen diskutiert, bevor Einigkeit über das Problem besteht. 
• Die aktuellen Herausforderungen werden nicht gemeinsam diagnostiziert, sondern vorgegeben. 
• Der Nutzen der bestehenden Situation wird nicht ausreichend in Betracht gezogen. 

Veränderungsvorhaben scheitern an falschen Grundannahmen
Wirft man einen genauen Blick auf diese kleine Hitparade des Misserfolgs, lässt sich leicht entdecken, dass viele Veränderungsprojekte nicht an schlechten Prozessen, Methoden, Frameworks oder Werkzeugen scheitern. Vielmehr werden diese Projekte Opfer falscher Grundannahmen. In dieses Horn bläst auch der Organisationsforscher Dietrich Dörner in seiner "Logik des Misslingens":

• Handeln ohne vorherige Situationsanalyse
• Handeln ohne Berücksichtigung von Fern- und Nebenwirkungen
• Handeln ohne Berücksichtigung von Prozessen
• Handeln ohne genaue Fehlersuche
• Handeln ohne Bedenken
• Handeln ohne Organisationsbewußtsein
• Handeln ohne kritische Selbstreflexion

Die Essenz: Einfach mal ein paar Praktiken, Spielregeln, Prozesse oder Tools in den Arbeitsalltag zu integrieren und dann hoffen, dass alles besser wird, ist eine Illusion. Der ersehnte Quick-Fix wird so sehr schnell zum Rohrkrepierer. Das gilt meiner Erfahrung nach auch für Kanban: Wer glaubt, einfach mal Visualisierung, WIP-Limits, Serviceklassen & Co Abteilungen oder Teams verordnen zu können und dann wird schon alles gut werden, ist leider am Holzweg. Was bei Veränderungsvorhaben zu beachten ist, werde ich in den folgenden Blog-Artikeln ausführen.

Ab heute erhältlich: Kanban in der IT

Es ist geschafft! Das Buch "Kanban in der IT - Eine Kultur der kontinuierlichen Verbesserung schaffen" von Sigi Kaltenecker und mir ist heute erschienen. Und man kann auch digital reinschauen:

• Leseprobe
• Vorwort von David J. Anderson und Barbara Heitger
• Inhaltsverzeichnis
• Stichwortverzeichnis

Retrospektiv betrachtet, waren 80 Prozent des Buches in Windeseile fertig gestellt :-) Die übrigen 20 Prozent waren jene Knochenarbeit, die wir ohne die Unterstützung von verschiedenen Seiten nicht geschafft hätten und für die wir uns an dieser Stelle bedanken möchten.

Ein spezielles Dankeschön gebührt Katrin Dietze, die unermüdlich auf der Idee beharrte, unsere gesammelten Erfahrungen schriftlich zu kanalisieren. Sie darf sich somit für die Initialzündung dieses Buches verantwortlich fühlen. Katrin schaffte es auch, unsere wilden Kritzeleien in schöne Illustrationen zu übersetzen.

Zwischendurch haben wir immer wieder Feedback dazu benötigt, ob wir am richtigen Weg sind. Dieses Feedback haben wir von unseren Revieweren Arne Roock, Elisabeth Blum, Jens Meydam, Katrin Dietze, Markus Andrezak und Sabine Eybl bekommen, die uns darüber hinaus für spannende Diskussionen zur Verfügung standen.

Wir möchten uns auch bei David J. Anderson bedanken, der für uns eine unerschöpfliche Quelle an Inspirationen ist und dieses Buchprojekt von Anfang an unterstützt hat. Und schließlich ein Dankeschön an Barbara Heitger, deren Know-how im Change Management eine produktive Steilvorlage bot.

Natürlich ist ein Text ohne einen Verlag nur ein Teil des Buch-Weges. Herzlichen Dank an den Hanser Verlag, allen voran Margarete Metzger und Stefanie Gerhards für die Organisation und Lektorat, Irene Weilhart für die Hilfestellung in technischen Notfällen und Jürgen Dubau für die raschen Korrekturgänge.

Damit man neben der Leseprobe weitere kleine Einblicke in das Buch erhält, starte ich nächste Woche eine Blog-Reihe mit Kerninhalten aus dem Buch. Getagged wird mit KanbanInIT.

Buchpräsentation: Kanban in der IT

Nun ist es endlich soweit: Unser Buch "Kanban in der IT - Eine Kultur der kontinuierlichen Verbesserung schaffen" ist ab 3. Mai im Handel erhältlich. Gemeinsam mit Sigi Kaltenecker wollen wir euch am Montag den 7.5. das gute Stück präsentieren. Start ist um 18 Uhr im Café Schottenring in Wien. Wir freuen uns über angeregte Diskussionen zum Thema Kanban Change Leadership und auf euer zahlreiches Erscheinen. Anmeldung zum Event über die Lean & Agile Austria Gruppe.

Wann? Mo, 07.05.2012, 18:00 Uhr
Wo? Café Schottenring, Schottenring 19, 1010 Wien
Anmeldung >

Kanban im Schnelldurchlauf

Am 19.4.2012 wurde ich vom Vienna Agile Requirements Circle eingeladen, einen Einführungsvortrag zum Thema Kanban zu halten. Das Resultat ist nun in Video-Form erhältlich - in Farbe und bunt :-) Viel Spass beim Schauen!

Wegweiser für eine Kultur der kontinuierlichen Verbesserung

Kanban kann mit sehr wenig Aufwand sehr viel bewegen. Das sehe ich häufig, wenn ich Wochen oder Monate nach einer Kanban-Einführung ein Unternehmen wieder besuche. Ich sehe jedoch auch, dass ich von Unternehmen kontaktiert werde, die ihren Kanban-Piloten in den Veränderungs-Sand gesetzt haben. "Wir haben ein Board, WIP-Limits und Serviceklassen. Die Mitarbeiter versuchen jedoch permanent das System zu umgehen", ist ein häufige Klage. Mit ein paar gezielten Fragen stellt sich bald heraus, dass Kanban nicht als evolutionäre Veränderungsinitiative gesehen wurde, sondern als ein Sammelsurium von Mechaniken, das man über das Team stülpt.

Kanban ist eine Veränderungsinitiative

David Anderson hat in den drei Grundprinzipien von Kanban erläutert, was er mit evolutionärer Veränderung meint:

1. Kanban beginnt dort, wo sich ein System gerade befindet. Es braucht keine großen Umstellungen, aufwendige Trainings oder Prozessrevolutionen.
2. Kanban respektiert die bestehende Ordnung. Weder werden die bestehenden Prozesse per se in Frage gestellt noch die existierenden Funktionen. Respekt heißt in diesem Zusammenhang, dem Bestehenden einen Sinn zuzugestehen.
3. Kanban strebt inkrementelle, evolutionäre Veränderungen an. Es geht um ein Schritt für Schritt und nicht um den großen Wurf. Und es geht um eine Übereinkunft mit all jenen, die von dieser Veränderungsbewegung essentiell berührt werden.

Ich sehe es als absolute Bedingung, dass man bei einer Kanban-Einführung diese Prinzipien verfolgt. Wenn es darum geht, einen Kulturwandel - hin zu einer Kultur der kontinuierlichen Verbesserung - zu schaffen, braucht es jedoch noch mehr.

Wegweiser für einen Kulturwandel

In unserem Buch "Kanban in der IT - Eine Kultur der kontinuierlichen Verbesserung schaffen", erläutern Sigi Kaltenecker und ich, dass es über diese Prinzipien hinaus ein profundes Grundverständnis braucht, wie eine Kultur kontinuierlicher Verbesserung geschaffen werden kann. Hierfür sind unserer Ansicht nach folgende Wegweiser maßgeblich:

1. Kanban ist eine Veränderungsinitiative. Es geht um systemische Verbesserungen, für die nicht Einzelleistungen, sondern die Zusammenarbeit wesentlich sind. Wertschöpfung und Arbeitsqualität steigen durch bessere Strukturen und klarere Spielregeln mit allen relevanten Kooperationspartnern.
2. Kanban dreht sich um die gesamte Arbeitskultur. Die Verbesserung dieser Kultur erfordert eine kritische Reflexion der eigenen Grundhaltungen, die sich in einem bestimmten Leistungs- und Kooperationsverhalten ausdrücken. Das erfordert wiederum die Bereitschaft zu einer kontinuierlichen Arbeit an der eigenen Entwicklung.
3. Kanban dreht sich um Menschen und nicht um Mechaniken. Es sind die Menschen, die eine nachhaltige Verbesserungsarbeit vorantreiben – und sie tun dies ganz wesentlich durch Emotionen: Freude, Mut, Begeisterung, aber ebenso Ärger, Enttäuschung oder Trauer. Wir empfehlen dringend, diese Emotionen zu respektieren und zu nützen – schließlich dürfen sie als Motor von Veränderung betrachtet werden.
4. Kanban ist Teamsport. Um eine Kultur kontinuierlicher Verbesserung zu schaffen, braucht es Verbündete. Man braucht Partnerinnen und Partner, mit denen die neuen Werte gemeinsam ins Leben gerufen und am Leben erhalten werden. Man braucht die Unterstützung des Managements, da systemische Probleme sichtbar gemacht und auch gelöst werden wollen. Und man muss die Stakeholder im Boot haben, da man ohne deren aktive Kooperation nicht den gewünschten Mehrwert schaffen kann.

Diese Wegweiser unterstreichen die Komplexität des Veränderungsfeldes, das mit Kanban gestaltet wird. Das erfordert ein Vorgehen, das dieser Komplexität gewachsen ist, und erklärt, warum es sich in der Regel nicht empfiehlt, einfach mal mit Kanban loszulegen. Damit riskiert man nämlich, dass es bei kurzfristigen Veränderungsschritten bleibt und das langfristige Verbesserungspotenzial nicht genutzt werden. 

White Noise – Ein Igel bändigt die Stimmen aus dem Hintergrund

Wenn ich mit Teams einen Workshop zum Kanban Systemdesign mache, tritt spätestens bei der Definition der Arbeitstypen die Frage auf „Was landet eigentlich auf unserem Kanban-Board?“ Wenn ich mit „alles woran ihr arbeitet“ antworte, dauert es ziemlich genau zwei Nanosekunden, bis der oder die Erste ca. so darauf reagiert: „Ständig kommt irgendwer und will, dass wir uns kurz mal etwas anschauen. Wenn wir dafür jedes Mal ein Ticket ans Board hängen, mag das vielleicht sport-technisch gesehen sehr gesund sein, da wir uns viel bewegen aber das kann doch wohl nicht die Lösung sein...“
Natürlich wäre es ein Weg, allen Stakeholdern klipp und klar zu sagen, dass das Team ab morgen nur noch Arbeiten annimmt, die den regulären Weg über das Queue Replenishment Meeting gegangen sind. Außer Entsetzen, kräftigem Widerstand und unhöflichen Fingergesten würde eine solche Ansage aber wahrscheinlich wenig bringen.

Ich sehe es sehr häufig, dass Teams im Laufe eines Arbeitstages mit Zwischendurch-Aufträgen „gefüttert“ werden, die es im regulären Kanban-Betrieb nie aufs Board schaffen würden, weil sie vielleicht „nur“ wenige Minuten oder Stunden verbrauchen, aber trotzdem nicht weniger wichtig sind. Ich nenne diese Art von Aufträgen „White Noise“ – Hintergrundrauschen.

Das eigentliche Problem beim White Noise ist exakt das Gleiche wie bei allen anderen Aufgaben in der Wissensarbeit: Es ist für die Auftraggeber und für das Team nicht sichtbar, wie sehr dieses Hintergrundrauschen das System belastet und wann der kritische Punkt erreicht ist, von dem an alles andere schwerwiegend blockiert wird. Der beste Weg ist daher, mit White Noise genau das Gleiche wie mit allen anderen Aufgaben zu machen: Wir machen es sichtbar und damit messbar und begreifbar.

Viele Teams verwenden dafür selbstklebende, wieder entfernbare Indexmarkierungen, die man normalerweise für das schnelle Wiederfinden bestimmter Stellen in Büchern oder Dokumenten verwendet. Diese Markierung entspricht z.B. einer Zeitspanne von 15 Minuten. Bevor das Team damit beginnt, kommuniziert es allen Stakeholdern, die direkt mit dem Team arbeiten, was die Markierungen bedeuten. Danach passiert Folgendes: Jedes Mal, wenn ein Teammitglied einen White-Noise-Auftrag bekommt, klebt es so viele Markierungen auf seinen Monitor, wie es der Dauer des Auftrags entspricht. Und zwar nicht nur für sich selbst, sondern für alle gut sichtbar. Im Laufe des Tages sitzen die Teammitglieder nicht mehr vor Monitoren, sondern vor bunten Igeln. Schon dieses visuelle Signal der bunten Indexstreifen bewegt viele dazu, das tatsächliche Ausmaß kurzfristiger Aufträge genauer zu überdenken.

Auch wenn das Hintergrundrauschen nicht am offiziellen Kanban-Board, sondern auf den Monitoren der Teammitglieder visualisiert wird, kann man Limits einführen. Das Team kann sich selbst zum Ziel setzen, dass pro Mitglied nur eine bestimmte Menge an White Noise bearbeitet werden darf – zum Beispiel sollen maximal zwei Stunden pro Tag dafür verbraucht werden. Wenn wir dabei bleiben, dass ein Indexstreifen 15 Minuten entspricht, ist nach acht Streifen Schluss. Auch hier unterstützt die Visualisierung die Argumentation gegenüber den Geräuschemachern.

Damit hier keine Missverständnisse auftreten: Es geht nicht darum, White Noise vollkommen zu eliminieren. Wie gesagt handelt es sich dabei um durchaus wichtige Aufgaben, die erledigt werden müssen. Das primäre Ziel ist es, für alle Beteiligten transparent zu machen, was ein System auf welche Art und Weise und in welchem Ausmaß beeinflusst.

Der Umgang mit White Noise ist übrigens ein Punkt, der unbedingt in den Regeln des Teams festgehalten werden muss!