Wie findet bei Euch Lernen statt?

Vor einiger Zeit wurde ich gefragt, wie in unserem Unternehmen MAYFLOWER Lernen stattfindet.

Neben unserer 2-wöchentlichen Slacktime (Innovationszeit, organisiert wie ein Open Space) am Freitag gibt es unterschiedliche Lernformen in den Teams. Ich berichte hier von den Lern-Elementen in meinem Beratungs-Team, in dem ich meine operative Arbeit einbringe. Und außerdem, wie ich selbst lerne.

Wie lerne ich?

Wenn ich etwas lerne, versuche ich es oftmals zu verarbeiten: Notizen verfassen, tweets schreiben, einen Blogartikel verfassen, einen Vortrag auf einer Veranstaltung einreichen, bei einem Podcast über das Thema sprechen, …

Zum einen denke ich “Schreiben ist Lernen”, das heisst das Gelernte verfestigt und verinnerlicht sich dadurch. Zum anderen habe ich dadurch die Möglichkeit, über das Feedback, das ich von den “Nutzern” (Lesern, Zuhörern, …) bekomme, erneut zu Lernen.

Es ist wie bei der Produktentwicklung: Das Feedback der Nutzer, ganz gleich ob positiv oder kritisch, gibt mir wiederum die Gelegenheit zu Lernen.

Und aus diesem Lern-Effekt, entstehen weitere Ideen, die ich dann wieder in tweets, Blog-Beiträge usw. verarbeite.

Das gleiche trifft auch zu, wenn ich in einem Beratungsprojekt bin oder unsere Kunden, für die wir digitale Software-Produkte entwickeln, betreue: Auch dort, durch die Beratung und die Arbeit mit dem Kunden, lerne ich - und speise dies in meine “closed loop” ein, denn hier bekomme ich ebenfalls viele Ideen, die ich wiederum in Artikel, Konferenz-Vorträge etc. verarbeiten kann.

Welche Lern-Elemente haben wir im Team?

Im Team versuchen wir, Reflexionsschleifen an allen Ecken zu fördern und zu leben. Da es viele sind, hier nur eine stichpunktartige Auflistung. Unser Workstream teilt sich auf in die Bereiche

  • operative Kundentätigkeit
  • Content-Produktion inklusive Meetup-Organisation
  • Networking & Akquise

Wir organisieren uns Kanban-artig mit Elementen aus dem Scrum wie Refinement und Retrospektive.

Unsere Lern-Elemente sind:

  • Weekly Planning: In einer für uns passenden Agenda gibt es zum Abschluss die Suche nach 1 Verbesserung, die wir in unserer Arbeit direkt ändern / ausprobieren wollen. Dies wird durch eine entsprechende Frage gestellt
  • Retrospektive: Findet 2-wöchentlich statt. Über einen Agenda-Punkt im Weekly prüfen wir, ob wir für die kommende Retro ein Schwerpunkt-Thema setzen wollen
  • Post Mortem bzw. After Action nach einem Projekt: Um unsere Arbeit kontinuierlich zu verbessern, halten wir nach jedem Projekt eine Art Post Mortem / After Action Review ab, in dem wir gezielt nach Verbesserungen für die Zukunft suchen. Dies betrifft sowohl Kundenprojekte als auch größere interne Team-Projekte (zB MVP-Release von theagilehub, nach Erstellung eines Whitepapers etc.)
  • Review-Spalte in unserem Board: Insbesondere in der Content-Produktion ist es uns wichtig, Feedback von Team-Kollegen zu bekommen. Dazu dient die Review-Spalte in unserem Board. Über die Rückmeldung, die wir eigenständig einfordern, lernt jeder von uns natürlich auch
  • Persönliche Peer-Feedback-Runden: In regelmäßigen Abständen treffen wir uns im Team und gestalten persönliche Peer-Feedback-Runden. Hier probieren wir verschiedene Formate aus. In diesen Runden üben wir gegenseitige konstruktive Kritik verbunden mit self-selected Action Items zur persönlichen Verbesserung und versuchen uns zusammen als Team nach vorne zu bringen, indem wir die Gelegenheit für das persönlich-fachliche Wachstum der Einzelnen schaffen. Sicherlich ist es nicht immer ganz einfach und benötigt ein gewisses Level an Vertrauen - doch wenn man es regelmäßig macht, dann ist wird es immer einfacher :wink: Falls Ihr bei Euch im Team Schwierigkeiten habt, so etwas durchzuführen, hilft eventuell der bekannte Spruch: “If it hurts, do it more often” Wer es als Team schafft, durch diesen Prozess durchzugehen, wird am Ende viel stärker und robuster sein.
  • Weiterentwicklung in Form einer Roadmap: Wir haben es ein paar mal gemacht, es ist aber bei uns wieder eingeschlafen (und bringt mich zur Idee, das im Team noch einmal anzubringen). Hier hatten wir uns in 4-monatigen Abständen getroffen und jeder von uns hat seinen eigenen Weiterentwicklungs-Plan mitgebracht, wie er oder sie denkt, sich im Sinne des Unternehmens und im Kontext unserer Team-Vision weiterzuentwickeln. Mit entsprechendem Peer-Feedback und einem Grading war das dann Gegenstand der eigenen Objectives / Ziele / Entwicklungs-Epics, die dann auch transparent auf unserem Team-Board in der Swimlane “Team-Internas” auftauchte. Ich habe hier für mich die Product Vision und Product Roadmap genutzt, da ich mir dachte dass wenn ich und meine Weiterentwicklung das Produkt sind, dann kann ich auch die Instrumente des Product Owners dazu nutzen :slight_smile: Ich habe dazu auch mal einen Artikel auf Linkedin geschrieben
  • Regelmäßige Feedback-Schleifen mit dem Kunden: Unsere Kunden sind häufig überrascht, dass wir in regelmäßigen Abständen nach Feedback fragen. In größeren (Software-)Projekten bedienen wir uns des “Mayflower Cooperation Feedback Questionaire”, bei Beratungs-Projekten sind es regelmäßige Feedback-Syncs mit den Stakeholdern unserer Kunden

So, das war schon eine ganze Menge. Für uns ist das ein lebendes System. Im Rahmen unserer Retrospektive und unseres wöchentlichen Taktik-Treffens passen wir diese Rituale an die Gegebenheiten an.

Natürlich haben wir bei jedem Treffen eine Plus/Delta oder ROTI-Abfrage. :slight_smile: Und wer unsere #meetups-events:agileufra-meetups kennt, der weiß, dass wir das Feedback unserer Teilnehmer sehr ernst nehmen und ebenfalls in unseren Nachbereitungs-Treffen neben unserem eigenen Feedback dazu nutzen, um die Meetups für die Teilnehmer stets zu verbessern :slight_smile:

Und wie lernt Ihr im Team?

Jetzt bin ich natürlich neugierig, welche Lern-Elemente in Euren Teams stattfinden. Freue mich auf Kommentare! :partying_face:

2 Likes

@bjoern.schotte : klasse Beitrag.

Das werde ich gleich mal mit übernehmen :slight_smile:

Was mich dabei auch beeindruckt: wie ihr euren Weg findet. Das entspricht auch meinem Motto: “Die Methode muss zum Kunden passen - nicht der Kunde zur Methode” :slight_smile:

Lernen im Team (unterschiedlich - je nach Projekt):

  1. Pair Programming
  2. Brownbag Sessions: kleine, leicht verdauliche Lerneinheiten mit freiwilliger Teilnahme:
    Jemand erzählt von einer Problemstellung und wie diese angegangen wurde, ob das erfolgreich war; idealerweise kombiniert mit einem Impuls zum Meinungsaustausch oder einer weiteren Lerneinheit
  3. Meetups wie eure - als Impuls für die Teammitglieder, den Horizont ausserhalb der eigenen Blase zu erweitern; oder sei es auch “nur” um festzustellen, dass es auch andere Unternehmen gibt, die sich mit Problemen der unterschiedlichsten Art auseinandersetzen müssen.
  4. “Echte” Sprint Reviews im Sinne des Erfinders: also keine Abhak-Meetings, sondern als Plattform für den Austausch mit dem Kunden / Endanwender. Schnellster Weg für Inspect, adapt, inspire → Empirie und Erkenntnisgewinn, Kurskorrektur, etc.

Wenn ich weiter darüber nachdenke, fallen mir sicher noch mehr ein.

1 Like

Zufällig

Das war mein erster Gedanke und Reflex.

Nach etwas überlegen muss ich gestehen, dass stimmt dann doch nicht so ganz.

Wie lerne ich?
In der Regel notiere ich mir neue Erkenntnisse - und immer mal wieder lese ich da sogar nach :slight_smile:

Auch nehme ich regelmäßig an einem Lean Coffee teil, in dem Scrum Master und Agile Coaches (und ich:) uns austauschen.

Auch sonst nutze ich - seit Corona überwiegend Online - die Möglichkeit außerhalb meines Ökosystems mich austauschen zu können.

Lernen im Team
Innerhalb meines Teams (oder besser Gruppe) haben wir einen kurzen Slot im wöchentlichen Meeting mit Rückblick auf die letzte Woche. Ansonsten haben wir kein strukturiertes Lernen. Auch kann jeder etwas gelerntes Teilen, in dem er es vorab in die Agenda einbringt. Das kommt noch nicht so oft vor. (Das wird noch)

Das Team ist noch frisch, daher haben wir zum Start ein Team-Canvas durchgeführt und haben uns vorgenommen, dass nach einem Jahr noch einmal zu wiederholen.

Lern-Element im Unternehmen
Innerhalb unseres Unternehmens (Stadtwerk), haben wir eine “Impulsgeber Community”. Dort können alle die wollen, alle zwei Wochen zusammen kommen. Und wir tauschen uns über Themen rund um neue Arbeitsformen (Technik und Methoden) aus.

Einmal im Monat gibt es ein internes “Trainingscamp”. 45 Minuten Online-Meeting auf freiwilliger Basis in der kleine Tipps & Tricks rund um Office und co. vorgestellt werden. Das wird wirklich gut angenommen.

Insgesamt, also doch etwas mehr, als im ersten Reflex gedacht.

Coole Idee @frank.sattler !

Was könnt Ihr den anderen in der Community dazu mitgeben? Wie einfach / leicht fällt es Euch, Endanwender für die regelmäßige Teilnahme an den Reviews zu begeistern?

Wenn du schreibst “keine Abhak-Meetings”: Wie sorgt Ihr für die passende Atmosphäre? Und gerade in remote-Zeiten? Kuchen & Sweets essen ist da ja nicht mehr so leicht möglich :slight_smile:

Zum Thema “Lernen im Team” hab ich kaum noch was meinen Vorrednern hinzuzufügen. Bei meinem Ex-Arbeitgeber und damit in den bisherigen Ex-Teams waren das regelmäßige Retrospektiven, Postmortems, gelegentliches Pair Programming, situatives “Mob-Feuerlösching”, Brown Bag Sessions und längere Sessions zu Themen aus unserem Team-Lernplan. Außenrum dann noch Communities of Practice, die Vertrauenslernzeit und das feste Lernbudget.

Vielen Dank für diese umfassende Antwort auf die Frage, wie bei MAYFLOWER Lernen stattfindet!
Im letzten Job war ich Einzelkämpferin, es gab kein “Team”.
Ich hoffe aber, in Kürze hier von neuen Team-Lern-Erfahrungen berichten zu können. :four_leaf_clover:

1 Like

Das ist von Projekt zu Projekt höchst unterschiedlich.

Aus meiner Erfahrung gibt es zahlreiche Faktoren, die die Qualität und den Wert von Sprint Reviews massiv beeinflussen:

  • Teamreife: wie gut ist das Zusammenspiel im Scrum Team?

  • Scrum Master: versteht diese/r, dass es kein JIRA User Stories Abhak-Meeting ist, sondern dass dieser Termin idealerweise zum Lernen, Feedback einholen, Alternativen diskutieren, Sprint- & Lösungsziele validieren etc. genutzt werden kann?

  • Versteht das DevTeam, dass es nirgends besser Fragen stellen kann, um Informations- Transfer-Fehler zu vermeiden?

  • Ist der PO ein echter (also kein Proxy) PO? Versteht er / sie, dass seine Baustelle das “Was” ist und das Team sich um das “Wie” kümmert?

  • uvam.

  • Vorbereitung und Kommunikation rund die Sprint Review:
    Wer soll daran teilnehmen seitens der Stakeholder? Sind diese rechtzeitig informiert worden? Ist die Technik geprüft? Kann jeder mit dem Tool der Wahl (Teams, Zoom, GoTo, Slack…) umgehen und darf dieses Nutzen? Gibt es ggf. jemand, der / die Notizen macht oder evtl. mit Zustimmung des Kunden aufzeichnet?

  • Verständnis auf Seiten der in- und / oder der externen Kunden für die Bedeutung von deren Feedback: der Kunde sollte die SR als Format verstehen, in dem
    … gelernt werden kann
    … frühzeitig Kurskorrekturen vorgenommen werden können
    … Ideen eingebracht werden können - uvam

  • Agiler Reifegrad des Projekts, des Projektteams und des Kunden insgesamt

  • ist die Organisations willens, das Prinzip des “kontinuierlichen Lernens” auch in der SR anzuwenden? M.E.wird nur so wird ein offener Austausch mit den Stakeholdern bzw. Kunden ermöglicht.

Der Weg zu guten Sprint Reviews ist jedes mal eine Reise: mit jeder SR folgt eine kleine Post Mortem Betrachtung mit dem Team, was gut lief und was nicht, ob es auf Basis der gewonnenen Erkenntnisse entsprechende Maßnahmen gibt, und und und.
Übrigens bitte ich die Stakeholder am Ende jeder SR um kurzes Feedback: entweder durch Smileys, Dot-Voting oder auch per Chat.

Im Laufe der Zeit verbessern sich die Vorbereitung, das Vertrauen steigt, die Offenheit,… Letztlich die Qualität und der Wert, der daraus gezogen werden kann.

Ich sehe es in meiner Funktion / Rolle als SM, hierzu durch entsprechende Facilitation beizutragen :slight_smile:

…es ist jetzt doch schon wieder mehr geworden…