Erfahrungsbericht Kanbaneinführung, Vortrag Kanban ohne Mandat und fünf Jahre Limited WIP Society Cologne – Die Themen auf dem 59. Treffen der #LWIPCGN

Auf dem 59. Treffen der Limited WIP Society Cologne konnten wir auch auch gleichzeitig auf das fünfjährige Bestehen der Limited WIP Cologne zurückblicken. Vor den Feierlichkeiten wollten wir uns aber zunächst noch zwei interessanten Themen/Vorträgen widmen.

Zunächst hat Wim uns von seinen Erfahrungen mit der Einführung von Kanban in einem IT-Operations Team berichtet. Seine Schilderung führte zu einer angeregten Diskussion. Das folgenden Flipchart kann dazu vielleicht als Gedankenstütze dienen:

flipchart-wim

Im Anschluss an diesen Bericht und die rege Diskussion hat uns Thomas im ebenfalls auf eigenen Erfahrungen basierenden Kurzvortrag „Kanban ohne Mandat“ ein paar neue Denkanstöße geben können.

kanban_ohne_mandat (1)

Thomas betrachtet in diesem Vortrag, wie die Anwendung der Kanban Prinzipien dabei helfen kann, trotz fehlendem Mandat zur Einführung von Kanban nachhaltige Veränderungen zu erzielen.

Nach diesen beiden Vorträgen war es dann so weit. Die Sektflaschen wurden geöffnet, um auf das fünfjährige Bestehen der Limited WIP Society Cologne anzustoßen. Immerhin drei Gründungsmitglieder waren auch heute anwesend. In fünf Jahren mussten nur zwei Treffen ausfallen. Über 126 Mitglieder umfasst unsere Xing-Interessengruppe. Zwischen 4 und 13 Teilnehmer besuchen unsere monatlichen Treffen und ermöglichen, auch gerade aufgrund dieser in der Regel überschaubaren Größe, einen spannenden Austausch über Kanban in Theorie und in Praxis.

fünf-jahre-limited-wip-cologne

Veröffentlicht unter Erfahrungsberichte, Treffen | Kommentar hinterlassen

Betrachte das Ganze – das Lean Software Development Prinzip #7 auf dem 58. #LWIPCG Treffen

Am 08. Juni 2016 haben wir uns mit dem siebten und letzten Prinzip des Lean Software Development: „Betrachte das Ganze“ (See the Whole im Original) beschäftigt.

Die Poppendieks beschreiben in Ihrem Buch nur zwei Werkzeuge – Messungen (Tool 21) und Verträge (Tool 22) – und das sind gerade Tools, die im agilen Umfeld eher umstritten sind.

Gleichzeitig ist das Thema ein großer Unterschied zwischen Lean und Agile – was für Möglichkeiten bieten sich also durch die Anwendung dieses Prinzips für unser tägliches Projektgeschäft?

Als Gedankenanker hier die Flipcharts, die unsere Diskussionen begleitet haben:

SeeTheWhole-1.png

SeeTheWhole-2-Messungen.png

SeeTheWhole-3-Beobachtungen.png

SeeTheWhole-4-OptionalScope.png

 

Veröffentlicht unter ohne Kategorie | Kommentar hinterlassen

Build integrity in – Thema auf dem 57. Treffen der #LWIPCGN

Das Thema am 11.Mai war das sechste Prinzip des Lean Software Developments: Baue Integrität ein (Build Integrity in).

Wir haben über das sechste Prinzip des Lean Software Developments diskutiert und unsere eigenen Beobachtungen zu den von den Poppendiecks beschriebenen Werkzeugen verglichen. Die Poppendiecks beschreiben in ihrem Buch vier Werkzeuge – Perceived Integrity (Tool 17), Conceptual Integrity (Tool 18), Refactoring (Tool 19) und Testing (Tool 20)

Als kleine Gedankenstütze hier die Flipcharts, die unsere Diskussionen begleitet haben.

 

BuildIntegrityIn-1-Overview.png

 

BuildIntegrityIn-2-TypesOfIntegrity.png

BuildIntegrityIn-3-OtherIntegrityTools.png

Veröffentlicht unter ohne Kategorie | Kommentar hinterlassen

Empower the Team auf dem 56. Treffen Der Limited WIP Society Cologne

Befähige das Team (Empower the team)  – Das fünfte Prinzip des Lean Software Development

Im Rahmen unserer Veranstaltungsreihe zum Lean Software Development haben wir uns diesmal das das fünfte Prinzip aus dem Buch der Poppendiecks „Befähige das Team (Empower the team)“ vorgenommen.

Die Poppendiecks beschreiben zu diesem Prinzip vier Werkzeuge – Self-Determination, Motivation, Leadership, Expertise  –, die verwendet werden können, um dieses Prinzip in der Praxis umzusetzen.

„Purpose“ (Zweck / Bestimmung) wird von den Poppendiecks als wichtige Basis für die Motivation der Teammitglieder in einem befähigtem Team genannt. Als eine Möglichkeit einem Team diese Bestimmung mitzugeben haben wir uns das Werkzeug „True North“ näher angesehen. Das folgende Foto fasst unsere Diskussion zusammen.

true north

Ein befähigtes Team benötigt aus Sicht der Poppendiecks „Leadership“ (Führung). Im Buch wird der „Master Developer“ als besonders befähigtes und erfahrenes Teammitglied beschrieben.  Wir haben diese „Person“ kontrovers diskutiert und unsere Ergebnisse auf dem folgenden Foto festgehalten.

the master developer

Unter dem Titel „The Light Side“ haben wir interessant Anekdoten aus dem Arbeitsalltag der Teilnehmer gesammelt und ausgetauscht. Das folgende Foto fasst diese postiven Erfahrungen kurz zusammen.

the light side

Zum Abschluss des Termin haben wir in der Runde noch eine Reihe von Literaturempfehlungen gesammelt:

  • Reinventing Organizations, Frederic Laloux
  • Turn the ship around, L. David Marquet
  • #Workout (Management 3.0), Jurgen Appelo
  • Scrum, The art of doing twice the work in half the time, Jeff Sutherland
  • Gung Ho, Kenneth Blanchard und Sheldon M. Bowles

Am 11.05 geht es dann weiter mit dem sechsten Prinzip des Lean Software Development „Build integrity in“.

 

Veröffentlicht unter Treffen | Kommentar hinterlassen

Liefere so {schnell|früh} wie möglich – was heißt das eigentlich im Lean Software Development (55. Treffen der LWS)

Auf dem 55. Treffen der Limited WIP Society Köln ging es um das Prinzip „Deliver as fast as possible“

Die eigentlich sehr spannende Frage, ob es eher um das schnell oder um das früh liefern geht wurde kurz behandelt, aber da die Auswirkungen für die konkreten Tools überschaubar schienen habe wir uns dann verstärkt mit den eigentlichen Werkzeugen beschäftigt.

Im folgenden kurz die Flipcharts vom Treffen, die zwar die überaus spannenden Diskussionen nicht vollumfänglich wiedergeben können, aber hoffentlich einen groben Einblick in die diskutierten Themen geben.

Pull Prinzip

photo

Notizen zum Tool „Pull-Prinzip“

Queueing Theory

photo1

Notizen zum Tool „Queueing-Theory“

Cost of Delay

photo2

Cost of delay – z.B: mit konkreten Produkten (gedruckte Handbücher) als Berechnungsgrundlage

 

photo3

Cost of delay und CD3 (Cost of delay divided by duration)

 

photo4

Verzögerungskosten bei der Codeverbesserung und eine „kleine“ Rechenübung zum Einfluss der Dauer der Erstellung auf den Gesamtertrag

 

photo5

Verschiedene Betrachtungsweisen zu „Cost of delay“

 

 

Weitere Tools – dieses Mal zum Thema „Empower the team“ – auf dem nächsten Treffen am 13.04.

 

Veröffentlicht unter Treffen | Kommentar hinterlassen

Seeing Waste – Hauptpunkt aus dem 52 Treffen (Eliminate Waste – Verschwendung Vermeiden)

Wir haben uns insbesondere mit dem Werkzeug „seeing waste“ beschäftigt und zu den einzelnen von den Poppendieks benannten Verschwendungen Beispiele aus der Praxis identifiziert.

Lagerhaltung und zusätzliche Verarbeitung

„Lagerhaltung“ und „Zusätzliche Bearbeitung“

Verschwendung eins und zwei: Lagerhaltung und zusätzliche Verarbeitung

Als interessante Erkenntnis zum Thema „Lagerhaltung“ haben wir mitnehmen können, dass Arbeit an der Realisierung von Anforderungen so lange „partially done work“ darstellt und somit ggf. Verschwendung sein kann, bis das Ergebnis sich auch im produktiven Einsatz befindet.

 

Überproduktion und Transport

Überproduktion und Transport

Verschwendung drei und vier Überproduktion und Transport

Spannend war hier die Gleichsetzung von Transport mit Taskwechseln, die die Teilnehmer so zunächst nicht vermutet hatten, die sich aber im Gegensatz zu „Bewegung“ sehr gut herleiten lässt, wenn man den Ursprung im Produktionsbetrieb berücksichtigt.

 

 

Warten, Bewegung und Defekte

Warten, Bewegung und Defekte

Verschwendung fünf bis sieben: Warten, Bewegung und Defekte

Unter diesen drei Verschwendungen war insbesondere das aus der Produktion übertragene „Motion“ eine Herausforderung, da es schwer von Transport anzugrenzen ist. Da in der Produktion hier insbesondere das Bewegen des Werkstücks innerhalb eines Bearbeitungsschrittes gesehen wir erschließen sich dann aber doch auch hier beängstigend viele Möglichkeiten innerhalb von Wissensarbeit „Bewegung“ als Verschwendung zu beobachten.

Veröffentlicht unter Treffen, Werkzeuge | Kommentar hinterlassen

Lean Software Development kennen lernen – das 51. Treffen der Limited WIP Society CGN

Um dem Karnevalstreiben in der Kölner Südstadt am 11.11 aus dem Weg zugehen, trafen wir uns diesmal Ausnahmsweise an einem Donnerstag in der Bottmühle zur Auftaktveranstaltung unserer neuen Veranstaltungsreihe „Lean Software Development“.

Anhand eines Foliensatz führte Michael uns durch die sieben Prinzipien des „Lean Software Developments“, die Mary und Tom Poppendieck in ihrem 2003 erschienenen Buch „Lean Software Development – An Agile Toolkit“ vorstellen.

Slide #2013 Michael Mahlberg PRINZIPIEN DES LEAN SOFTWARE DEVELOPMENT EliminiereVergeudung Verstärke das Lernen Entschei...

Insgesamt werden im Buch neben den Prinzipien 22 Werkzeuge dargestellt, die zur Umsetzung der Prinzipien Anwendung finden können. Ein kurze Diskussion zu allen Werkzeugen diente dazu sich initial mit dem Thema „Lean Software Development“ vertraut zu machen. In folgenden Monaten wollen wir nach einander jedem der Prinzipien einen kompletten Abend widmen und an diesen Abenden dann Praxiserfahrungen der Teilnehmer zu den Prinzipien und Werkzeugen diskutieren. Zusätzlich wollen wir auch immer einen Blick darauf werfen, ob in den vergangenen 12 Jahren sich neue Sichtweisen auf die Prinzipien ergeben haben.

Veröffentlicht unter Treffen, Werkzeuge | Verschlagwortet mit | Kommentar hinterlassen

Kanban erforschen mit ‘Featureban’ – das 50. Treffen der Limited WIP Society CGN

Beim fünfzigsten Treffen der Limited WIP Society am 14.10 im Startplatz führte uns Thomas Epping durch die Simulation ‘Featureban’.

Featureban wurde von Mike Burrows entwickelt und der Kanban-Community mit der ausdrücklichen Erlaubnis zur Verwendung, Anpassung und Weiterentwicklung unter einer „Creative Commons Attribution-ShareAlike 4.0 International License“ zur Verfügung gestellt. Detailinformation zu Featureban finden sich hier https://www.agendashift.com/featureban.

Featureban basiert auf wenigen, einfachen Regeln und lässt sich mit einfachen Mitteln (Flipchartpapier, Post-It-Notes, Stiften und ein paar Münzen) spielen.

Rules

Nach einer kurzen Einleitung und der Erläuterung der Regeln durch Thomas spielten wir die Simulation in drei Gruppen über drei Runden. Nach jeder Runde erfolgte ein Austausch über die Erkenntnisse sowie ein Abgleich des Erlebten mit den Kanbanpraktiken und eigenen Erfahrungen aus dem Berufsalltag.

Group_A_-_Round_2

Cumulative_Flow_Diagrams_-_Round_3

Die Feedbackrunde ergab – neben einigen interessanten Anregungen zur weiteren Verbesserung der Simulation – ein sehr positives Fazit. Mit deutlich einfacheren Mittel als zum Beispiel getKanban führt Featureban sehr anschaulich in die grundlegenden Kanbanpraktiken ein und ermuntert zu Diskussionen über die Praktiken.

 

Sehr aufschlussreich waren unter anderem auch die sehr unterschiedlichen Ergebnisse je nach Regelset – leicht verfälscht allerdings dadurch, dass die Systeme nicht nach jedem Regelwechsel zurück gesetzt wurden.

 

Regelsatz  1:

 

Regelsatz  2:

Regelsatz  3:

Veröffentlicht unter Treffen, Werkzeuge | Kommentar hinterlassen

Six Sigma und Kanban – das 49. Treffen der Limited WIP Society CGN

(Lean) Six Sigma und Kanban – das 49. Treffen der Limited WIP Society CGN

In diesem Treffen hat Daniel Schaus eine Einführung in Six Sigma und Lean Six Sigma gegeben zu der sich eine lebhafte Diskussion anschloss.

Hier einige der bemerkenswerten Punkte in Form grober Stichworte als kleine Gedankenstütze.

Unterschiede von (Lean) Six Sigma und Kanban

  • Kanban ist vor allem ein Prozesssteuerungs und -verbesserungswerkzeug, das über den gesamten Entwicklungszyklus genutzt wird
  • (Lean) Six Sigma ist ein Werkzeug zur gezielten Prozessverbessrung
    • Six Sigma Projekte haben eine konkrete Prozessverbessung zum Ziel
    • Der Werkzeugkasten des Six Sigma enthält viele Werkzeuge, die auch im Kanban oder sonstigen Prozessverbessungskontext relevant sind

Six Sigma

Fakten

  • Kommt aus der Produktion
  • Vor allem im Bereich Prozessverbesserung
  • Der Name kommt von der Standardabweichung
  • 2,3 Defekte pro Million Fehlermöglichkeiten = Six Sigma
    • Voraussetzung: Der Prozess muss sich wiederholen
    • Nur durch hohe Frequenzen (Wiederholungsraten) lassen überhaupt die Gewinne durch eine bessere Fehlerrate ausschöpfen
  • Sehr stark Dokumentengetrieben
  • Guckt aus User- / Kundensicht
  • Stark Datengetrieben

Was ist mit den Gürteln?

In Six-Sigma werden die Praktizierenden in sogenannten Gürteln zertifiziert.
Im folgenden weder kurz die unterschiedlichen Bedeutungen skizziert.

Weiß (White Belt)

  • Projektmitarbeiter, hat mal von Lean Six Sigma gehört, im allgemeinen einen zwei Kurs mitgemacht

Grün (Green Belt)

  • Leitet kleinere Projekte selbständig, oder arbeitet in Black-Belt Projekt mit
  • 5 bis 7 Tage Ausbildung
  • Klein in diesem Kontext ist den Unternehmen überlassen. Meistens an der projektierten Einsparung bemessen.
  • Zertifikate sind Unternehmensbezogen (Green-Belt bei something.org)

Schwarz (Black Belt)

  • Längerer Kurs
  • Selber Schulungen (Green Belt) gegeben
  • Großes Projekt geleitet

Master Black Belt

  • Betreut andere Six-Sigma Gürtel-Träger

Hintergrund

  • Woher kommt der Six-Sigma Hype
    • Erfolgsstories: z.B. GE und Jack Welch

Lean Six Sigma

In Six Sigma wurde insbesondere versucht, den Lean Werte Stack zu integrieren.

  • TIMWOOD
  • Adressiert vor allem des Aspekt „Reduce Waste“ aus dem lean Werte Stack

Eingeschlossene Modelle

Werkzeuge

Siehe z.B. The Lean Sigma Pocket Toolbook

Prinzipielles Modell

  • Entscheidungsbaum: Wann setze ich überhaupt Lean Six Sigma ein?
  • Ist nur Sinnvoll, wenn es einen existierenden Prozess gibt
  • Macht sich der Kunde (des Projektes, Projektsponsor) überhaupt Gedanken um Waste

5 Phasen Modell

Lean Six Sigma basiert auf einem 5 Phasen Modell

Define

Was ist eigentlich das Problem (Project Charta)

Measure

Wie groß ist das Problem?
Ist es überhaupt ein Problem

Analyze

Entscheidung über weiteres Vorgehen

Implement / Improve

Umsetzung des neuen Prozesses

Control

Übergibt den Prozess in die Produktion

Ergänzungen

  • Auch ohne Six Sigma kommen in immer mehr Bereichen intensive Messungen zum Einsatz
  • Zitat: Critical Chain Management ist der Feuerleitstant für Lean Six Sigma
Veröffentlicht unter Treffen | Kommentar hinterlassen

Offener Abend zu Kanban – 48. Limited WIP Society CGN

Beim 48. Treffen der Limited WIP Society Cologne haben wir in einer sehr gelungenen Kombination aus Lean Coffee und Fish-Bowl die folgenden sechs Themen jeweils zwischen 10 und 20 Minuten intensiv diskutiert:

  • Kommunikation im Kanban Umfeld
  • Kanban auf CxO Ebene etablieren
  • Kanban und Ticket-Systeme
  • Woran scheitern Kanban-Initiativen
  • Agiles Releasemanagement
  • Portfolio-Management mit Kanban

Im Folgenden geben wir exemplarisch zu drei der sechs Themen die Erkenntnisse aus unserer Diskussion in der Fish-Bowl wieder.

Kommunikation im Kanban Umfeld

Neben der Kanbanmethode mit ihren Praktiken und Prinzipien sind für eine erfolgreiche Einführung und Verwendung von Kanban auch das richtige Mindset und eine gute Kommunikation wichtig.

In größeren Teams erfordert dies Werkzeuge für die Moderation von größeren Gruppen. Insbesondere müssen dabei auch Meinungen ausgehandelt und Entscheidungen getroffen werden. Es gibt adäquate Werkzeuge und Methoden. Sie sind aber häufig unbekannt und werden direkt durch die Kanbanmethode auch nicht vorgegeben.

Die Kommunikation im Team erfolgt häufig über viele Kanäle (Chat, Mail, Telefon, …). Regeln und Nutzungshinweise erleichtern und strukturieren die Kommunikation.

Neben diesen eher technisch oder methodischen Unterstützung für gute Kommunikation sollte auch nicht vernachlässigt werden eine Basis im Sinne eines gemeinsamen Verständnisses zu schaffen. Hierzu können z. B. spezielle Events neben dem Tagesgeschäft dienen, die ein Kennenlernen der Beteiligten und einen Austausch ermöglichen.

Kanban auf CxO Ebene etablieren

Für die Einführung von Kanban sollte auch das Topmanagement in einer Firma einbezogen werden damit es die Initiative unterstützt. Wie kann Kanban den CxOs einer Firma nahe gebracht werden, wenn sie nicht direkt in den Kanbanteams mitwirken.

Eine Chance kann das Einführen von kleinen Kanbanexperimenten, wie z. B. Personalkanban oder anderer Protokanbanvarianten, bieten, um die Arbeit einen CxOs oder der CxOs untereinander zu visualisieren und zu strukturieren. Vorliegende Organisationsdefizite können so behoben werden und den CxOs ein direkter Nutzen vermittelt werden.

Interessant dürften für die CxO Ebene auch die auf Teamebene erhobenen Kanbanmetriken sein. Gelingt es diese Metriken zu erheben und den CxOs regelmäßig darzustellen ist dies ein großer Schritt in Richtung der Einbindung der CxOs.

Ein weiterer Ansatz kann die Verdeutlichung der Wirksamkeit des Pull-Prinzips zum Beispiel über Gedankenexperimente sein. Aber Achtung: Pull setzt dann bereits ein gewisses Mindset voraus, dass sich vielleicht von der bisherigen Kultur einer Aufgabenzuweisung von Oben nach Unten unterscheidet.

Woran scheitern Kanban-Initiativen

Es wird häufig nur von erfolgreichen Kanbaninitiativen berichtet. Es wird bestimmt aber auch viele Misserfolge geben. Woran scheitern Kanbaninitiativen?

Kanban erfordert ein hohes Maß an Disziplin. Prozesse müssen eingehalten werden. Regeln müssen befolgt werden. WIP Limits müssen beachtet werden. Eine Fish-Bowl, wie wir sie heute durchgeführt haben, funktioniert, weil sich alle an die Regeln halten. Halten sich zu viele, z. B. weil sie sich dies aufgrund ihrer Position im Unternehmen erlauben können, nicht an die Regeln, funktioniert das System nicht mehr. Vorgesetzte und Manager kommen ggf. mit dem Pull-Prinzip nicht klar, da sie gewohnt sind Aufgaben zu verteilen. Insbesondere der Schritt WIP zu limitieren erfordert eine sehr hohe Disziplin, da schnell eine Ausnahme gemacht wird, um doch noch etwas für einen wichtigen Stakeholder zu tun.

Ein weitere Ursache für das Scheitern kann in kulturellen Problemen liegen. Fehlendes Vertrauen oder nicht vorhandene oder wenig ausgeprägte Fehlerkultur führen zur Angst vor Transparenz. Man möchte der Realität, die das Kanbanboard abbildet,  nicht ins Auge sehen. Sichtbarmachen des Status Quos kann ggf. einer Revolution gleichkommen. Somit sind Kanbanboards häufig sehr disruptiv. Im Projektkontext wird häufig sehr politisch berichtet. Dies beißt sich aber mit dem Ansatz des „Start with what you do now“ und der Visualisierung.

Ein sehr grundsätzliches Problem kann entstehen, wenn die Einführung des Kanbansystems für einen nicht wirklich wichtigen Prozess/Service erfolgt. In dem Fall fehlt die Dringlichkeit für die notwendigen Änderungen und bei kleineren Problemen verfällt man wieder in alte Verhaltensmuster.

Die fehlende Einbindung in „echtes Changemangement“ und mangelndes Methodenwissen stellen zwei weitere mögliche Ursachen für das Scheitern einer Kanbaninitiative dar.

Alles letzter Punkt wurde noch festgestellt, dass Kanban keine Allzweckwaffe ist. Wird Kanban im falschen Kontext angewendet, kann man nur scheitern. Kanban wird in dem Zusammenhang auch fälschlicher Weise manchmal als Prozess und nicht als Methode zur Prozessverbesserung verstanden.

Zu den drei weiteren Themen hier nur kurz in Stichpunkten – und insbesondere als Gedankenstütze für diejenigen, die vor Ort waren – die diskutierten Aspekte des Abends.

Kanban und Ticket-Systeme

  • Funktioniert manchmal: Ticketsystem wird überführt in physische Karten
  • Multi-Tier Kanban
  • Kanban als Loadbalancer an den Übergängen
  • Vorteil von Trello: Vereinbarungen müssen im Team getroffen werden
  • Ähnliches Verfahren:
    • Skalierung „von oben nach unten“
    • Medienbrüche an natürlichen Grenzen helfen sogar dabei die anstehenden Prozessentscheidungen explizit zu machen.

Agiles Releasemanagement

  • Gibt es das Überhaupt?
  • Kanban vs. Drum-Buffer-Rope
  • Im Prinzip ja …
    • Was ist ein Release?
    • Agile Prinzipien – z.B. grober Einführungstermin
    • Continuous Delivery => dann wird Release zu Anschalten von Features
  • Geht das im Kontrollierten Umfeld?
  • Stacey-Matrix
    • Man beachte, dass agile Methoden insbesondere im komplexen Umfeld zuhause sind.
    • Für komplizierte Probleme sind andere Methoden eventuell sinnvoller
    • Im Scrum Umfeld: Möglichst viele Feedback-Mechanismen einbauen
  • Agil heißt nicht nur Wochen – man beachte, woher man kommt, und welche Zeiten üblich sind. z.B. Autositze in einem halben Jahr zu bauen kann revolutionär schnell sein.

Portfolio-Management mit Kanban

  • Ja, sollte man machen
    • Visualisierung fehlt
    • Projektboard macht z.B. Vorbereitung sichtbar
  • Interconnected Kanban Systems
  • z.B. Epic-Board
    • 30 Leute Runde
    • wöchentliche Fortentwicklung des boards
    • Straff durchmoderiert
  • Komplexität begrenzen
  • Sogar Unbedingt über Kapazitäten reden, wenn „PO“s das Board definieren.
  • Engpässe ausmodellieren und transparent machen
  • Nach dem Management des Flows kommt „Start with why“
Veröffentlicht unter Treffen | Kommentar hinterlassen