Day 12 - LKNA13 Chicago

Der Tag beginnt mit dem letzten Frühstück in einem Ballsaal des Hotels. Um 8:45 Uhr lauschen Arne, Fridel und ich geschlossen der Keynote des Tages.

STOP Arguing START Experimenting. Foto: Fridtjof Detzner
STOP Arguing START Experimenting. Foto: Fridtjof Detzner

How to Measure Anything: An Introduction from the Author

Der Autor Douglas Hubbard gibt ein seinem Talk {Link zur Summary des Talks und dem Speaker Profileine Einführung zu seiner aktuellen Veröffentlichung "How to measure anything". Er spricht über die Gründe aus denen Menschen denken, manche Dinge wären nicht messbar und warum Messungen trotzdem Sinn machen.

"In short, we should assume increased confidence
from analysis is a 'placebo'. Real benefits have to be measured." 

Von alledem weiß ich so gut wie nix. Ich verstehe jedoch, dass quantitative Messungen häufig nicht gemacht werden, weil gedacht wird, dass sie unmöglich sind. Klassische Begründungen sind fehlende Daten, zu hoher Aufwand, um die nötigen Daten zu bekommen, der zu messende Fall ist zu einzigartig oder es gibt augenscheinlich zu viele Einflussfaktoren. Hubbard hat beobachtet, dass in der Regel mehr Daten zur Verfügung stehen als angenommen, allerdings häufig auf die falschen zurückgegriffen wird. "Science was never about having data - it was about getting data." Er spricht an, dass Methoden zur Messung oft nicht richtig verstanden werden oder das zu messende Objekt nicht gut genug definiert ist.

  • Concept of measurement → widely misundertood
  • Object → not well definded
  • Method → not well understood how they work

"It is amazing what you can see when you look."

[Yogin Berra]

Hubbard betont, dass es sich lohnt bezüglich Messungen und ihren Ergebnissen skeptisch zu sein und Methoden bzw. Definition des Messgegenstandes zu hinterfragen.

Seine Betrachtung zu "Objects of measurement", "Dinge" die schwerer messbar scheinen, wie beispielsweise "Glück", finde ich hilfreich: "Denke an die praktischen, beobachtbaren Auswirkungen, lachen Menschen die glücklich sind eher häufiger oder eher selten?" Hubbards Aussage nach eine messbare Erscheinung.

 

Auf die Frage aus dem Publikum, was mit Produktivitätsmessung von Teams und Individuen sei, fragt er skeptisch zurück: "Why do you care? Which decision will you take on the result?". Er rät sich diese Fragen bei jeder Art von Messung zu stellen: Warum ist das wichtig? Was sehe ich, wenn mehr/weniger davon da ist? Welche Art von Entscheidung möchte ich auf der Basis der Ergebnisse treffen? Diese Fragen helfen, das zu messende Objekt genauer zu definieren und die geeigneten Methode zur Messung zu identifizieren. Ebenfalls rät er, bei Messungen einfach zu beginnen und von dort aus granularer zu werden.

Insgesamt resümiere ich, dass ich mir jemanden wie Hubbard als Lehrer oder Professor an der Fachholschule gewünscht hätte. Er hätte meine Einstellung zu Zahlen, Messungen und Wahrscheinlichkeitsrechnungen grundlegend verändert. Da mir jedoch an zu vielen Stellen der Bezug zu meinem Arbeitsalltag fehlt, steige ich gedanklich im letzten Drittel der Keynote aus.

 

Management and Change - Avoiding the Rocks

Meine Notizen zum Talk. Foto: Nadja Macht
Meine Notizen zum Talk. Foto: Nadja Macht

Rodrigo Yoshima spricht über "die Steine" und meint damit die Widerstände gegen maßgäbliche Veränderungen {Link zur Summary des Talk und zum Speaker Profil} und warum Kanban dabei helfen kann, diesen Widerständen erfolgreich zu begegnen.

 

Yoshima bemüht dabei ein Zitat von Bruce Lee, das gern im Zusammenhang mit "Change", "Flow" und "Widerstand" genannt wird: "Be like water." Bruce Lee hat sich neben Kampfkunst und Schauspielerei auch mit Philosophie beschäftigt. Aus dem Zitat unterhalb lässt sich besser lesen, was in dem oben genannten Zusammenhang gemeint ist. Es geht darum "Veränderung" nicht mit Gewalt herbeizuführen sondern um die "Widerstände" herumzufließen und sich einen anderen Weg zu suchen.

"Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way around or through it. If nothing within you stays rigid, outward things will disclose themselves. ..."

[Bruce Lee]

In seinem Talk benennt Yoshima drei größere "Steine":

  • Peoples identity and self-esteem: Menschen haben ein Interesse daran, ihre Identität und Selbstauchtung zu schützen. Veränderungen sind nicht möglich wenn dieser Aspekt nicht berücksichtigt wird.
  • Decentralization level: Wie stark ist Selbstorganisation im Unternehmen etabliert oder werden ggf. alle Entscheidungen noch top-down getroffen.
  • Tribal behaviour: Das Beziehungsgeflecht, Regelwerk und Wertvorstellung können je nach Ausprägung Veränderung tragen und beschleunigen oder verhindern.

Kanban unterstützt den "Change Prozess", weil nicht radikale, große Änderungen eingeführt werden sondern kleine, iterative Schritte Evolution ermöglichen. Zweiteres strapaziert die Anpassungsfähigkeit von komplexen Systemen weniger und der zu erwartende Widerstand ist entsprechend geringer, die Veränderung damit nachhaltiger.

"People don't resist change; they resist being changed."

[Peter Senge]


Good practices to start a culture of continous improvement

In seinem anschließenden, praxisbezogenen Talk teilt Klaus Leopold sein Wissen zur erfolgreichen Einführung von Continous Improvement mit Hilfe von Kanban {Link zur Summary des Talks und zum Speaker Profil}.

 

Aus Erfahrung weiß er, dass die Einführung neuer Techniken und die Entwicklung eines neuen Mindsets nicht funktionieren, wenn sie einfach durch einen externen "Change Manager" in ein Team bzw. Unternehmen "gepusht" werden. 

 

Leopold fomuliert fünf greifbare Schritte zur Einführung, mit denen sich die gängigsten Fehler vermeiden lassen.

  1. Ein x-funktionales Kanban-Change-Team bilden
    • Veränderungen werden nicht durch eine einzelne Person eingeführt sondern durch ein Team
    • Es fühlen sich mehrere Personen verantworlich für die angestrebte Veränderung
    • Es gibt keinen "Single-Point-Of-Failure" oder Truck Number > 1
    • Gruppen treffen die besseren Entscheidungen
    • Größere Gruppen lassen sich in Task-Forces unterteilen
  2. Eine Retrospektive zu vergangenen Veränderungen bzw. die Vorgehensweise machen
    • Vergangene Fehler vermeiden
    • Die Vorgehensweise verbessern
  3. Die verschiedenen Stakeholder involvieren, d.h. all die Personen, die direkt und indirekt von der Veränderung betroffen sind
    • Stakeholder über eine "Stakeholder-Map" identifizieren, die den Einfluss der Stakeholder und ihr Beziehungsnetz visualisiert
    • Social-Leader bzw. Opinion-Leader an Board holen und für die Veränderung gewinnen, um weniger Widerstand zu erfahren
    • Bestehende Unzufriedenheiten aufdecken, um herauszufinden, was der Benefit für die Stakeholder sein wird
  4. Ein maßgeschneidertes System entwickeln
    • Mit einem "System-Design-Team", um möglichst verschiedene Sichtweisen miteinzubeziehen
    • Themen/Unzufriedenheiten aufgreifen, die im Schritt 3. identifiziert wurden
    • Aktivitäten auf die in Schritt 3. identifizierten Probleme/Unzufriedenheiten ausrichten
    • Das System den Stakeholder vorstellen und Feedback einholen
  5. "In Betrieb nehmen" und verbessern
    • System starten
    • Regelmäßige "Improvement Meetings" etablieren
    • Spontane Verbesserungen ermöglichen und fördern
    • Rein lokale Verbesserungen vermeiden
    • Stakeholder immer wieder involvieren
Improvement Cycle. Foto: Nadja Macht
Improvement Cycle. Foto: Nadja Macht

"A Kanban system is never finished by definition."

[Klaus Leopold]

 

Brickell Key Award Ceremony

Brickel Key Award. Foto: Nadja Macht
Brickel Key Award. Foto: Nadja Macht

Nach dem Lunch und den Ignite Talks geht es nahtlos über zur Verleihung des Brickell Key Awards. Sechs Mitglieder der LeanKanban Community, die sich durch ihr Engagement und ihre Beiträge im Laufe der letzten Jahre verdient gemacht haben, sind kandidiert. Letztes Jahr gewann unser lieber Arne einen der Awards für seinen Einfluß und Engagement in der Community Deutschland und Zentral Europa. Aus diesem Grund darf er dieses Jahr einen der Awards an Tom Magennis vergeben. {Mehr Infos zum Brickel Key Award}

 

Orwellian Project Management 101

Wieder sitzen Arne, Fridel und ich zusammen als wir den Talk von Jim Benson mit dem grandiosen Untertitel "We are on a predictable rocket ship to hell" genießen.

 

Der erste Teil dient der Begriffsklärung. Nicht jeder hat sich mit dem britischen Schriftsteller George Orwell beschäftigt und nicht jedem ist Neologismus ein Begriff. Dem Sprecher geht es um den manipulativen Einsatz bestimmter Wortschöpfungen, deren gut gemeinte Überdosierung zu einer Abstumpfung ihrer Bedeutung führt. Das ist die Brücke, die Benson von "Orwell" über "Neologismus" hin zu den Worten "Agile" und "Lean" baut. 

"Agile as fuck"

"Words become overused, overhyped and loose their meaning." Es geht ihm darum, dass wir agil sein wollen und immer neue Regelsets wie "Scrum" schaffen, um agil sein zu können. Dabei vergessen wir aber, dass es darum geht, Regeln in Frage zu stellen, die uns behindern. Das ist der Haken. Immer wieder im Talk zeigt Benson das das "Agile Manifest" {The Agile Manifesto} und Methoden wie "Scrum" kollidieren, wenn bei der Nutzung des Toolsets dogmatisch und nicht agil vorgegangen wird. Im Folgenden Absatz stehen die vier wichtigsten Kernwerte des "Agilen Manisfests" und die Phänomene, die sich im Alltag beobachten lassen:

 

  • Individuals and interactions over processes and tools → Scrum ist ein Toolset mit festen Regeln, entgegen der eigentlich angestrebten Agilität sind feste Kommunikations- und Entscheidungsstrukturen, die über die Rollen "Procuct Owner", "Scrum Master", "Stakeholder" und "Team" abgebildet werden, einzuhalten. Beteiligte verstecken sich u.U. hinter dem Regelset ihrer Rolle oder missbrauchen diese sogar.
  • Working software over comprehensive documentation → Nicht nur bei Scrum wird immer wieder zu viel Wert auf ausführliche Dokumentation zu lasten von qualitativ hochwertigem Code gelegt. Dokumentation kostet den Entwickler ggf. viel Zeit, die sie bei der Programmierung einsparen, weil die Dokumentation z.B. Bestandteil der Definition Of Done ist und ihr Aufwand in der Folge nicht mehr hinterfragt wird.
  • Customer collaboration over contract negotiation → Agil auf veränderte oder neue Kundenwünsche zu reagieren ist zeitgemäß und hat einen größeren Wert für den Kunden und das Produkt als auf eine feste Vertragsabsprache zu beharren. Trotzdem bleibt die wünschenswerte Flexibilität hier häufig auf der Strecke.
  • Responding to change over following a plan → Ein häufig beobachtetes Phänomen in Scrum ist, dass nach der Planung einer Iteration nichts mehr an dem Plan geändert werden darf. Auch nicht, wenn sich herausstellt, dass die Einhaltung des Plans überhaupt keinen Sinn macht. Auch hier ist die scheinbar naheligendste Ausrede häufig das feste Regelwerk von Scrum.

 

Der Apell des Talks ist bei dem Einsatz agiler Methoden agil zu bleiben und nicht dogmatisch zu werden, sodass "Agile" nicht weiter zu einer leeren Phrase verkommt.

 

Der Talk von Jim Benson war für mich die eigentliche Keynote des Tages.

 

Party mit den Speakern und Organisatoren der LKNA13

Zwischen den Talks und der letzten Veranstaltung des Abend - dem Ausklang der Konferenz in der Suite von D.J. Anderson mit den Speakern und Organisatoren der LKNA13 - laufe ich eine letzte  Runde am Lake Michigan in Chicago.

 

Aus meiner Sicht hörte die Konferenz stärker auf als sie begann und ich freue mich über die inspirierenden Beiträge und die Gesrpäche dazu, die ich nicht nur mit Arne und Fridel führen durfte.

 



Kommentar schreiben

Kommentare: 0