friendica.prankgo.de


Keine Entschuldigungen im Review

Bild: Pixabay / Geralt - CC0 1.0Egal ob im Sprint Review, in einem Stakeholder-Meeting oder bei einer wie auch immer gearteten Ergebnispräsentation - jedes agil arbeitende Team sollte in regelmässigen Abständen seinen Kunden, Sponsoren und Auftraggebern Ergebnisse zeigen. Bestenfalls sollten in diesem oder in einem anderen Rahmen auch Zieldaten und Forecasts kommuniziert werden, um Umsatzplanungen, Kommunikationsstrategien und ähnliches möglich zu machen. Und da der Mensch als solcher nun mal fehlbar und die Realität nicht vorhersehbar ist werden nicht immer alle Ergebnisse zum angedachten Zeitpunkt fertig sein. Was jetzt?

Ein häufiges Verhalten vieler Teams ist es, in solchen Situationen umfangreiche Erklärungen und Begründungen abzugeben. Mitunter in erstaunlichem Detaillierungsgrad wird dargelegt warum man sich in den Aufwandsschätzungen vertan hat, wie es dazu kommen konnte, dass die Planungen zu optimistisch waren oder welche Faktoren dazu geführt haben, dass das ursprünglich realistische Ziel wider Erwarten doch nicht erreicht werden konnte.

Verbunden damit ist in der Regel guter Willen. Transparenz ist bekanntlich einer der Grundprinzipien agilen Arbeitens, es ist also scheinbar nur folgerichtig sie auch in diesem Fall anzuwenden und für jeden nachvollziehbar zu machen warum alles so gekommen ist wie es ist. Zielführend ist dieses Vorgehen allerdings nur selten. Häufiger führt es zu Befremdung und Skepsis bei den Zuhörern, also zum Gegenteil des eigentlich erhofften Ergebnisses.

Zunächst wirken Erklärungen und Begründungen schnell wie Ausreden und Fingerpointing, und zwar auch dann wenn sie explizit nicht so gemeint sind. "Wir wollten ja, aber ..." hinterlässt selten einen guten Eindruck, erst recht nicht wenn es mehrfach geschieht. Und dass es immer wieder geschehen wird ist unvermeidbar, siehe menschliche Fehlbarkeit und Unvorhersehbarkeit der Realität. Besser sind Aussagen wie "Wir sind nicht ganz fertig geworden, arbeiten aber weiter daran." oder "Dieser Lösungs-Ansatz war leider der falsche, basierend auf dem was wir daraus gelernt haben arbeiten wir jetzt an einem besseren."

Des Weiteren sind derartige Themen für die meisten Kunden, Sponsoren und Auftraggeber schlicht uninteressant. Negative (und übrigens auch positive) Implementierungsdetails sind nicht der Grund dafür, dass man sich mit einem Umsetzungsteam trifft. Normalerweise kommen die Teilnehmer solcher Veranstaltungen weil sie Ergebnisse sehen, ausprobieren und Feedback geben wollen und nicht um zu hören wo es Probleme gab die sie weder beurteilen noch beheben können.

Zuletzt fressen Erklärungen und Begründungen Zeit weg die deutlich besser und gewinnbringender genutzt werden könnte. Jede Nacherzählung unerwarteter Hindernisse könnte ersetzt werden durch Hands on-Demonstrationen, Zufriedenheitsmessungen, Verbesserungsvorschläge oder die Vorstellung und Abstimmung von nächsten Schritten. Gerade vor dem Hintergrund, dass in agilen Teams Meetings meistens timeboxed sind ein nicht zu unterschätzender Faktor.

Das Alles heisst übrigens nicht, dass Fragen nach den nicht gelieferten Ergebnissen nicht beantwortet werden sollen. Das sollten sie auf jeden Fall. Aber nur dann wenn sie gestellt werden und ohne zu viele Details. Die will niemand hören.
http://www.lean-agility.de/2019/01/keine-entschuldigungen-im-review.html


#agile #kommunikation #meeting

CSS Grid Garden - A game for learning CSS grid layout

#css
#css


Process, Tribe and Comfort Zone
Ich bin nicht sicher ob Emily Phillips hier wirklich über Agile Leadership spricht oder nicht doch eher darüber wie sie mit den Unwägbarkeiten des eigenen Lebens umgeht. Interessant ist es aber so oder so.


http://www.lean-agility.de/2019/01/process-tribe-and-comfort-zone.html


#agile #leadership


Schöner Größenvergleich verschiedener Himmelskörper

https://youtu.be/GoW8Tf7hTGA
0x0me Mastodon
@erik we are not alone!

HN.Academy - Online Courses Recommended By Hacker News Users
HN.Academy collects, ranks, and showcases the online courses
recommended by Hacker News users.

https://hn.academy/


#mooc #course #learning


Eloquent JavaScript
This is a book about JavaScript, programming, and the wonders of the digital. You can read it online here
https://eloquentjavascript.net/


#javascript #book

Jeff Trull (@JaafarTrull) hat getwittert:
Fantastic presentation on Magit (#git mode in #Emacs) by John Wiegley at the MV meetup last month: https://t.co/aShBmLKF0S https://twitter.com/JaafarTrull/status/1080319045943971840?s=17


@0x0me kannst du meine posts auf mastodon sehen?

Guesstimate
A spreadsheet for things
that aren’t certain

Permalink
https://www.getguesstimate.com/

Kommentierte Links (XXXXIV)
Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" Texte aus dem letzten Jahr.
  • Garry Ridge: The Four Pillars of the Fearless Tribe

    Wenn man diesem Text glauben darf ist WD-40 eine mehr als bemerkenswerte Firma. Alleine die in diesem Text zitierten Ergebnisse einer internen Mitarbeiterbefragung sind beeindruckend:
    • 97 % der Mitarbeiter kennen die Firmenziele
    • 93 % sehen der Zukunft der Firma mit Vorfreude entgegen
    • 92 % fühlen sich ermutigt an der eigenen Weiterentwicklung zu arbeiten
    • 97 % verstehen wie ihre Tätigkeit auf die Firmenziele einzahlt
    • 97 % wissen welche Ergebnisse die Firma von ihnen erwartet
    • 98 % glauben, dass ihre Überzeugungen und Werte zu Firmenkultur passen
    • 99% erzählen Freunden gerne von ihrer Arbeit
    Der CEO Garry Ridge gibt in diesem Text einen detaillierten Überblick über die Firmenkultur die diese Ergebnisse hervorgebracht hat und über die Grundlagen und Prinzipien auf denen sie beruht. Unbedingt lesens- und nachahmenswert.
  • Corporate Rebels: The Fundamental Things People Get Wrong About Self-Management

    Eher ein Erklär-Artikel, allerdings ein wichtiger und nötiger. Denn während nahezu jeder der in einem agilen Kontext arbeitet von Selbstorganisation spricht, kann kaum jemand definieren was genau das ist und auch nicht was es nicht ist (Spoiler: es ist nicht "jeder macht was er will"). Infolgedessen ist der Begriff häufig mit unrealistischen Erwartungen und Befürchtungen verbunden, die schnell in Enttäuschung und Widerstand umschlagen. Die hier beschriebenen negativen Definitionen (dessen was Selbstorganisation nicht ist) können dabei helfen die Erwartungen auf ein realistisches Mass herunterzuschrauben - oder empozuheben
  • Willem-Jan Ageling: #NoEstimates – The 6 Alternatives for Estimating

    Noch ein Erklär-Artikel. Während Selbstorganisation für viele Menschen etwas ist was sie zwar nicht im Detail, aber zumindest auf einer sehr abstrakten Ebene beschreiben können, sind die meisten beim Thema "No Estimates" völlig verloren. Nach dem über-vereinfachenden Erklärungsversuch, dass Aufwände einfach nicht geschätzt werden, kommt nichts Brauchbares mehr. Dass es dann nicht nur einen sondern gleich mehrere No Estimates-Ansätze gibt hat für Viele einen fast schon esoterischen Touch. Und doch - es gibt sie, aufgelistet und erklärt in diesem Blog-Eintrag. [Nachklapp: das Ganze mag auch mit dem leicht missverständlichen Begriff zu tun haben, aber der hat sich nun mal so etabliert.]
  • Gary Hamel: Busting Bureaucracy

    Ein sehr guter und lesenswerter Text, aber auch einer den man sehr zwiespältig sehen kann. Dass Bürokratie Abläufe verlangsamt, die Beteiligten frustriert, Kreativität behindert, unnötige (und häufig versteckte) Kosten verursacht und wegen dieser und weiterer Gründe schnellstmöglich beseitigt werden sollte wird kaum auf Widerspruch stossen, damit hat Gary Hamel absolut recht. Auch dass es eine Gruppe von "Bürokraten" gibt, die von der Bürokratie profitiert (in Form von Macht, Anerkennung, Arbeitsverträgen, etc.) dürfte ein unstrittig anerkannter Teil des Problems sein. Schwierig wird es aber wenn "die da oben" dämonisiert werden. Das ermöglicht zwar eine mitreissende Revolutions-Rhetorik, baut aber auch Fronten auf und reisst Gräben auf. Veränderung wird dadurch schwerer.
  • Greg Satell: The Demise of Blockbuster, and Other Failure Fairy Tales

    Der Untertitel sagt eigentlich bereits alles aus: "When big companies collapse, the story is never simple". Tatsächlich ist in den letzten Jahren der Mythos entstanden, dass im Fall von Firmen wie Blockbuster, Kodak und Xerox der Niedergang, bzw. das Verpassen neuer Märkte vermeidbar gewesen wäre, wenn deren Management nur ein "agileres Mindset" gehabt hätte. In Wirklichkeit ist es natürlich komplexer. Die Herausforderungen wurden zwar erkannt und es wurden Pläne zu ihrer Bewältigung entwickelt, letztendlich wurde sich aber gegen große (und riskante) Inverstitionen entschieden, deren Erfolg damals nicht absehbar war. Was der Autor nicht sagt: mit agilem Vorgehen (MVPs, incrementelle Lieferung, etc.) hätte man die Investitionsrisiken stark reduzieren können.
  • Edward Niedermeyer: Elon Musk Is the Henry Ford of His Age. That's Bad.

    Ein gutes Beispiel für den Unterschied zwischen Agil und Lean und dafür wo welcher Ansatz Sinn macht. Das hier beschriebene Vorgehen von Tesla kommt klar aus dem Lean Startup (trotz seines Namens ein agiles Framework). Das Wichtigste ist es dort, schnell mit validierbaren Ergebnissen am Markt, bzw. beim Kunden zu sein und Geld zu verdienen. Das Ausliefern von leicht fehlerhaften Produkten wird bewusst in Kauf genommen und später durch Updates gefixt. Das Problem: Updates einer Automobil-Hardware müssen von Reparaturteams durchgeführt werden und erfordern unverhältnismässig viel Zeit und Aufwand. An der Stelle wäre vermutlich ein Lean-Ansatz besser gewesen, bei dem die Fertigungsstrasse so optimiert wird, dass es gar nicht zu fehlerhaften Auslieferungen kommt.
  • Bob Tarne: Agile Road Trip, Lessons From a Coach at Toyota

    Passend zum letzten Thema. Bei vielen Agile Coaches hat Toyota bis heute einen nahezu mythischen Ruf, da diese Firma federführend an der Entwicklung des Lean Management beteiligt war. Dass die Softwareentwicklung dort bis vor wenigen Jahren noch nach Wasserfall strukturiert war (siehe hier) wird dabei häufig ignoriert. Um so interessanter ist es zu erfahren, in wiefern der "Toyota Way" in die mittlerweile stattfindende agile Transition einfliesst. In der nordamerikanischen Tochtergesellschaft scheint das nur in geringem Ausmass so zu sein, zumindest legt dieser Artikel von Bob Tarne das nah. Bei der international tätigen Tochtergesellschaft Toyota Connected scheint das besser zu funktionieren (siehe hier). Wie das bei der Muttergesellschaft stattfindet ist zur Zeit aus den öffentlichen Dokumenten nicht zu erkennen. Man kann auf die ersten nicht-japanischenVeröffentlichungen gespannt sein.
  • Falk Kühnel: Agile scaling is plain wrong!

    Eine unterhaltsam geschriebene Abrechnung mit dem Buzzword "Scaled Agile" oder "agile Scaling". Tatsächlich ist es so, dass je nach Kontext völlig unterschiedliche Bedeutungen mit diesem Begriff verbunden werden. Eine extrem verbreitete fehlt aber bei Falk: Agile Scaling als Synonym für ein mit agilen Teams durchgeführtes Chinesenprinzip, also dafür, dass mehr Teams mit der selben Aufgabe beauftragt werden, in der Hoffnung schneller fertigzuwerden. Das wäre nochmal ein Thema für sich.

http://www.lean-agility.de/2018/12/kommentierte-links-xxxxiv.html

Hallo Friendica/Federiverse-Welt, Versuch 2
neuer älter