Folien zu meinem Pecha Kucha auf das JAX 2014 - den ich aus familiären Gründen letztlich leider nicht präsentieren konnte.
Ich präsentiere den Inhalt als Pecha Kucha oder als regulären Vortrag gerne auf anderen Konferenzen oder im Unternehmen. Bei Interesse einfach fragen: stefan.roock@it-agile.de
21. Referenzen
• Nonaka, Takeuchi: „The Knowledge-Creating Company“
• Dave Snowden: „The Basics of Organic Knowledge
Management“ (article series)
Hinweis der Redaktion
Wir entdeckten agile Entwicklung 1999. Seitdem lernen wir jeden Tag mehr darüber. Aber ein Aspekt steht heute so sehr im Fokus wie damals: das Lernen. Agile Teams lernen kontinuierlich über das Produkt und den Prozess.
Ein agiles Unternehmen muss also ein lernendes Unternehmen sein. Dazu braucht es eine Lernkultur bei den Mitarbeitern. Und es braucht eine passende Struktur im Unternehmen, die sicherstellt, dass das Gelernte im Unternehmen verbreitet und verankert wird.
Dazu sehen wir uns zuerst an, was es mit dem Wissen auf sich hat. In unserem Bildungssystem sind wir vor allem mit explizitem, stark formalisiertem Wissen konfrontiert, das mit Hilfe von Büchern und Frontalvorträgen transportiert werden kann. Daten, Modellen, Algorithmen, Konzepte, Produkte, Unternehmensstrukturen und Prozesse sind Beispiele.
Wenn in einem Kochrezept steht, man solle etwas goldbraun braten oder Eischnee unterheben, reicht das bei Weitem nicht aus, damit ein Kochanfänger ein leckeres Gericht hinkriegt. Für jemanden mit etwas Kocherfahrung ist beides aber klar. Offensichtlich gibt es mehr als explizites Wissen.
Dieses Erfahrungswissen nennt man implizites Wissen. Implizites Wissen ist im Gegensatz zu explizitem Wissen immer an Personen gebunden und findet seinen Ausdruck in sozialen Praktiken und in Intuition.
Wissen lässt sich nicht vollständig als rein explizit oder implizit klassifizieren. Zwischen den beiden Extrema liegt ein Kontinuum.
Viele Initiativen zum Unternehmenslernen betrachten vor allem explizites Wissen und lassen implizites Wissen außer Acht. Das gipfelt dann häufig in der Forderung, alles zu dokumentieren.
Nach Nonaka und Takeuchi findet Lernen statt, wenn Wissen transformiert wird. Daher reicht es auch bei weitem nicht aus, ein Wiki zu haben, um ein lernendes Unternehmen zu sein.
Wenn explizites Wissen in implizites Wissen umgewandelt wird, spricht man von Internalisierung. Internalisierung findet statt, wenn Konzepte in der Praxis angewendet werden. Es findet auch statt, wenn wir ein Produkt einsetzen. Und es findet statt, wenn wir eine strategische Vorgabe des Top-Managements in unsere Arbeitspraxis umsetzen.
Implizites Wissen kann auch in implizites Wissen umgewandelt werden. Diese Umwandlung findet immer zwischen Menschen statt, z.B. wenn diese gemeinsam arbeiten. Man nennt das Sozialisation.
Wenn Entwickler mit oder beim Kunden arbeiten, findet Sozialisation mit dem Kunden statt und die Entwickler entwickeln ein Gespür für die Kundenbedürfnisse.
Wenn wir implizites Erfahrungswissen in Geschichten, Konzepte oder Produkte umwandeln, sprechen wir wir Externalisierung. Externalisierung ist eine anspruchsvolle Aufgabe. Ein Beispiel ist die Artikulation eines Kundenbedürfnisses. So soll Ford Anfang des vorigen Jahrhunderts gesagt haben: „Wenn ich die Kunden gefragt hätte, was sie wollen, hätten sie gesagt ‚schnellere Pferde‘.“
Und nicht zuletzt kann explizites Wissen in explizites Wissen umgewandelt werden. Das findet z.B. statt, wenn verschiedene Konzepte miteinander kombiniert werden. Wenn ein Kundenbedürfnis externalisiert wurde und jetzt unter Berücksichtigung technologischer Möglichkeiten in eine Feature-Spezifikation umgesetzt wird, nennt man das Kombination.
Das Scrum-Framework setzt die vier Arten der Wissensumwandlung bezogen auf das Produkt um. In der Sprint-Planung findet Internalisierung statt, wenn die hochpriorisierten Features eingeplant werden. Wenn das Team mit dem Kunden arbeitet, um die Kundenbedürfnisse zu verstehen, findet Sozialisation statt.
Wenn das Team das Produkt entwickelt, ist das Externalisierung. Und im Sprint-Review wird das Feedback zum Produkt mit der Produktvision und Unternehmensstrategie kombiniert und das Product Backlog entsprechend angepasst.
Scrum setzt die vier Arten der Wissensumwandlung auch bezogen auf den Prozess um. In der Sprint-Planung werden die Verbesserungsmaßnahmen für den Sprint eingeplant. Es findet Internalisierung statt. Im Sprint werden diese Maßnahmen in der gemeinsamen Arbeit sozialisiert.
In der Sprint-Retrospektive wird das im Sprint erworbene Wissen über die Zusammenarbeit externalisiert, vor allem in den Phasen „Gather Data“ und „Generate Insights“. Dieses Wissen wird kombiniert mit Möglichkeiten zur Verbesserung in den Phasen „Generate Insights“ und „Decide what to do“.
Das Scrum-Framework unterstützt und verknüpft Lernzyklen auf Ebene von Individuen und Gruppen (dem Team). Es sind im Scrum-Framework allerdings keine Mechanismen integriert, die die für Unternehmenslernen notwendige Verknüpfung mit dem Rest des Unternehmens sicherstellen. Wir müssen die Frage beantworten, wie das Gelernte verschiedener Teams miteinander und mit der Unternehmensstrategie kombiniert wird.
Es reicht nicht aus, dass es Zyklen gibt, in denen Wissen transformiert wird. Wir müssen eine Wissensspirale schaffen, in der nicht nur die vier Arten der Wissensumwandlung stattfinden, sondern in die auch alle Unternehmensbereiche und -ebenen einbezogen werden.
Zentralistische Strukturen sind gut geeignet für Kombination und Internalisierung: Der CEO kombiniert die Expertise des Unternehmens mit einem Markttrend wie mobile Computing und formuliert daraus eine neue Unternehmensstrategie. Anschließend sorgt er mit Anweisungen dafür, dass diese neue Strategie in konkrete Aktionen umgesetzt werden, die Internalisierung findet statt.
Partizipative, dezentrale Strukturen sind gut in Sozialisierung und Externalisierung, haben aber meist Schwierigkeiten mit Kombination und Internalisierung. Bei der Team-Arbeit findet Sozialisierung ganz automatisch statt. Und während der gemeinsamen Produktentwicklung findet Externalisierung in Form von Konzepten und Produkten statt.
Nonaka und Takeuchi schlagen sogenanntes Middle Up Down Management vor, um die Vorteile dezentraler und zentraler Strukturen für die Wissensschaffung zu kombinieren. Dabei wechselt sich die Innovationsarbeit in autonomen Teams mit der geschäftsprozess-orientierten Arbeit in einem stabilen Geschäftssystem ab. Mitarbeiter rotieren zwischen den beiden Systemen.