Beiträge

Gedanken zu einem lernOS Framework

Gestern hatte ich den Sprint-Abschluss meines lernOS Circles mit Leonid und Till. Wir haben das Weekly Woche 12 gemacht, schön zu Mittag gegessen, einen Lessons Learned Podcast aufgenommen und in einer Retrospektive die Erfahrungen aus dem Sprint reflektiert. Wir haben dabei auch über die nächsten Entwicklungsschritte bei lernOS gesprochen und Till hat die interessante Idee eines lernOS Frameworks eingebracht.

Die Grundidee, das eigene lebenslange Lernen wie bei Scrum in Sprints zu organisieren und darüber ein “Timeboxing” und eine Taktung zu ermöglichen scheint sich zu bewähren. Für die Gestaltung des Sprints braucht es aber Flexibilität z.B. in Bezug auf die Personenanzahl, die physischen und virtuellen Treffen, das Verfolgen von Zielen und die zu absolvierenden Lernübungen. Daher war die Idee mit einem lernOS Framework einen verbindlichen Rahmen vorzugeben (ähnlich wie bei einem Barcamp), das dann für konkrete Anwendungen angepasst werden kann. Das ist insbesondere dann wichtig, wenn andere Akteure eigene Lernprogramme auf lernOS aufsetzen wollen, wie das z.B. mit Sketchnoting Out Loud (Sketchnoting in einem Sprint lernen) schon jetzt der Fall ist.

Der Begriff Framework kommt eigenlich aus der Softwareentwicklung und bezeichnet dort einen Ordnungsrahmen, der eine wiederverwendbare und gemeinsame Struktur für Anwendungen zur Verfügung stellt. Ein erster Schritt bei der Entwicklung eines Frameworks ist die Definition der Objekte oder Elemente des Frameworks und deren Attribute (Eigenschaften).

In unserer Retrospektive haben wir angefangen, erste Gedanken zu einem lernOS Framework zu skizzieren (Bild oben). Da lernOS auf den drei Ebenen Einzelperson, Team und Organisation eingesetzt werden kann, müssen die Begriffe des Frameworks auf allen Ebenen anwendbar sein. Die folgenden Objekte haben wir im Lauf des Gesprächs notiert:

  1. Sprint: wie bei Scrum ein definierter Zeitraum, in dem ein (Lern-)Ziel erreicht werden soll. Um die Anwendung der Methode Objectives & Key Results (OKR) zu ermöglichen ist die Standard-Dauer eines lernOS Sprints 13 Wochen (damit ergibt sich ein Quartals-Takt).
  2. Ziele: innerhalb eines Sprints versucht ein Akteur ein oder mehrere Ziele zu erreichen. Diese Ziele können vorgegeben oder selbstgewählt sein. lernOS schlägt vor, gemäß OKR pro Sprint maximal 5 Ziele festzulegen und deren Erreichung über Key Results (2-4 je Ziel) zu messen. Über die Boxenstopps im Sprint (i.d.R. zwei in Woche vier und acht) werden die Akteure angehalten, funktionsfähige “Minimum Viable Products” (MVP) ihrer Lernergebnisse zu demonstrieren und damit das Arbeiten in Iterationen zu erlernen.
  3. Akteure: die Anzahl der Akteure kann je nach Ebene variieren (Organisation = Alle Mitarbeiter, Abteilung = 20, Scrum-Team = 7, Circle = 5, Lerntandem = 2, Einzellerner = 1).
  4. Lernpfade: ein Lernpfad ist ein vordefinerter und erprobter Ablauf von Instrukturionen, Inhalten, Interaktionen und Übungen (wir wollten den Begriff “Curriculum” vermeiden), mit dem Akteure Lernziele effizient erreichen können (z.B. Sketchnote Lernpfad zum Erlernen von Sketchnoting). Die Begrifflichkeit Pfad ist an Coder Dojos und Katas angelehnt (siehe z.B. Learning Paths auf coderdojo.com).

Die Herausforderung für die zukünftigen lernOS Versionen wird sein, ein solches Framework auszugestalten und allen Beitragenden in der Community zu erklären. Gleichzeitig dürfen die Anwender aber durch die Begrifflichkeiten und vermeintliche Komplexität nicht abgeschreckt werden. Habt Ihr dazu weitere Gedanken und Ideen?

Scholarch der Cogneon Akademie. Von der Ausbildung Dipl.-Ing. Elektrotechnik mit Schwerpunkt Digitale Nachrichtentechnik. Ich brenne für Lernende Organisationen, Wissensmanagement, New Work und Lebenslanges Lernen. Mitglied in Corporate Learning Community, Gesellschaft für Wissensmanagement, Chaos Computer Club uvm. Weiterer Podcast unter http://knowledge-on-air.de.

Praxisnah, konkret & individuell anpassbar – Aufgabenmodell für interne Community Manager

In den letzten Jahren habe ich in unterschiedlichen Bereichen Kunden im Bereich Enterprise 2.0 und internes Community Management unterstützt. Dabei habe ich natürlich auch zahlreiche Quellen im Bezug auf Community Management recherchiert. Aus meiner Sicht waren die diversen Quellen für mich allerdings nicht sehr praxistauglich, da zu abstrakt über das Thema geschrieben wurde. Aus diesem Grund habe ich auf Basis meiner Recherchen und meinen eigenen Erfahrungen in drei Jahren als interner Community Manager ein Lifecycle- und Aufgabenframework entwickelt. Dieses gibt einem als interne Community Manager konkrete Handlungsoptionen inkl. der Umsetzungsmöglichkeiten mit internen sozialen Medien.

Zunächst einmal umfasst das Modell die drei Phasen 1) eine Community starten, 2) eine Community betreiben und 3) eine Community entwickeln. Innerhalb dieser Phasen gibt es insgesamt 24 Aufgaben, die in insgesamt sechs Aufgabenpaketen geclustert sind (Zahlangabe in Klammern). Diese Clusterung ermöglicht es dem Community Manager zum einen strukturiert und bewusst Aufgaben wahrzunehmen, zum anderen auch Aufgabenpakete zu delegieren.

Auf dieser Basis haben wir  ein 24-teiliges Aufgaben-Kartenset entwickelt. Wie das Beispiel zeigt, ist eine Karte in drei Bestandteile gegliedert. Zunächst einmal gibt es die Angabe zu welcher Phase eine Aufgabe zuzuordnen ist. Darauf folgt unter “Was” die eigentliche fachliche Aufgabe”. Die fettgedruckte Schrift im Beispiel signalisiert hierbei, dass es sich um ein Aufgabenpaket mit insgesamt fünf Einzelaufgaben handelt und dies die zweite Aufgabe ist. Unter “Wie” findet man schließlich einen konkreten Umsetzungshinweis.

Die Aufgaben sollten generell als konkrete Orientierungshilfe dienen – nicht jede Community braucht zwingend eine Umsetzung aller 24 Aufgaben. Abschließend möchte ich noch auf die flexible Anpassungsfähigkeit des  “Wie” an unternehmensspezifische Tools wie Microsoft Sharepoint, IBM Connections und Jive hinweisen.